Blog: One USB-C Cable: How We Made the NVIDIA Jetson Thor Flashable from a Mac or Windows PC | Wendy

Cloudsvg]:px-6 max-sm:hidden" data-marketing-event="cta_docs_click" data-marketing-params="{"link_text":"Get Started","link_url":"https://docs.wendy.dev/latest","location":"header_get_started"}" href="https://docs.wendy.dev/latest">Get Started<br>Get StartedMenu

One USB-C Cable: How We Made the NVIDIA Jetson Thor Flashable from a Mac or Windows PC

Wendy Labs - Wendy Labs TeamAugust 06, 2026

TLDR, you can now Flash WendyOS from a USB-C cable with a Macbook or Windows. Get Started

p]:my-0">With wendy os install, we can now flash WendyOS onto an NVIDIA Jetson AGX Thor from macOS, Windows, or Linux. Our<br>CLI downloads a prebuilt flashpack, handles recovery over one USB-C data cable, and configures the board before its<br>first boot. Thor still uses its supplied power connection.

When NVIDIA shipped the Jetson AGX Thor, we set a simple bar for WendyOS: installing it should feel like setting up a phone. Connect one USB-C cable to your laptop, run one command, and let the tooling do the rest. Sadly, flashing WendyOS onto Thor required an x86 Ubuntu machine, and that's a computer most developers don't program on or have access to. At least in our developer base, the overwhelming majority use MacBooks or Windows machines.

Thor still needs its supplied power connection, but that USB-C cable should be the only data connection to your developer machine, and requiring another computer is an unreasonable entry fee for getting into robotics. If you love your Mac or Windows development environment, why create and maintain a second desktop just to install an OS?

We couldn't have picked a less phone-like device for that experience: a complete install has to update two kinds of storage through a recovery protocol designed around a Linux host, while the several-gigabyte vendor bundle depends on a mix of Python and native utilities and was never meant to run on a Mac or Windows PC.

That was our starting point in late June 2026, and about a month later, the same install worked from macOS, Windows, and Linux with one Wendy CLI binary.

Here's how we got there.

Why we couldn't stop at a disk image

We couldn't treat Thor like a Raspberry Pi, where installing an operating system often means writing an image to an SD card. For WendyOS, we chose a full recovery install that writes the QSPI bootloader chain and the internal NVMe partitions together while the board is in USB recovery mode. That keeps both sides of the boot path on a compatible release from the first startup.

Rendering diagram…

A typical Pi install writes one image to removable storage. WendyOS uses the Thor recovery workflow to write QSPI and internal NVMe as one compatible release.<br>What QSPI and the bootloader chain do

Skip this section if you already know what a QSPI bootloader chain is.

QSPI stands for Quad Serial Peripheral Interface. It's a fast serial connection that moves data over four lines instead of the single data line used by ordinary SPI. When we say "QSPI" here, we mean the QSPI-connected NOR flash that provides small, nonvolatile storage for early boot firmware and configuration.

QSPI flash and NVMe have different jobs, and NVIDIA's Thor partition configuration identifies QSPI NOR as the boot partition device and the NVMe SSD as the user partition device. NVMe has the capacity for the Linux kernel, root filesystem, application data, and the other large WendyOS partitions, while QSPI holds the firmware and configuration the board needs before it can read and start any of that software from NVMe.

The closest PC analogy we've found is BIOS or UEFI firmware on the motherboard paired with an operating system on an SSD, although Thor's early boot process has more hardware-specific stages.

A bootloader chain is that sequence of stages. No single program turns on every part of Thor and jumps straight into Linux. Each stage initializes enough hardware for the next stage, loads it, and, where required, authenticates it. NVIDIA's Thor boot flow describes the overall job as initializing storage, memory, and the CPU, setting security parameters, loading and authenticating firmware, maintaining the chain of trust, and finally booting the operating system.

In simplified form, the handoff looks like this:

BootROM is immutable code inside the Thor SoC. It runs first after reset. In normal boot it starts loading the early firmware from QSPI. In Force Recovery Mode it listens for that early firmware over USB instead.

PSCROM and the security stages provide authentication and decryption services. They help establish the chain of trust and audit the firmware that follows.

MB1 performs low-level board initialization. It applies configuration for clocks, power, pins, security, and memory, then initializes DRAM using the Memory Boot Configuration Table.

MB2 continues platform bring-up after MB1 and prepares the system for UEFI.

UEFI provides the standard...