Jetson campaign log: from emulator to silicon

OC2-Edge currently runs in x86-64 and ARM64 emulation: ~930 automated tests passing, 9 continuous integration pipelines, a demonstration anyone can replay by cloning the repository (replay the demo on the emulator). The Jetson campaign opens the next stage: bringing the node to real silicon.

This article is the first episode of a recurring campaign log. It sets the doctrine, describes the bench, and publishes the protocol with its pass criteria. It publishes no results: at publication date, no stage has been validated on hardware. The “Results as they come” section at the end of this article is empty and will remain so until the first measurements.

Zero hardware commitment

On Jetson modules, permanently enabling secure boot relies on fuses: one-time programmable bits in the SoC (System on Chip). NVIDIA documents the operation as irreversible: a bit set to 1 can never return to 0 [2]. A fuse burned with the wrong key, or in the wrong order, can render the module permanently unusable [2].

The campaign doctrine follows from this: zero hardware commitment until the full chain is validated. Three rules apply.

1. No fuse is burned during the campaign. Validation of the signing chain is performed without writing to the silicon. NVIDIA’s fusing tooling provides a test mode that sends the fuse blob to the module without burning anything [2]; only this mode is used.
2. The guardrails are hard-coded in the tooling. The repository’s flashing scripts reject any fusing command; the burn target does not exist in the campaign’s published tooling. An operator cannot burn a fuse by mistake with the repository’s tools: they would have to leave the tooling and do it deliberately.
3. Everything remains reversible. The module can be fully reflashed over USB in recovery mode; any previous state can be restored at any time. As long as no fuse is committed, no campaign operation degrades the hardware permanently.

The hardware anchoring of verification, that is, writing the public key hash into the fuses, is the last milestone of the campaign, not the first. That operation will only be considered after all previous stages are validated, on a module dedicated to that purpose, and will be the subject of a documented decision in this log.

The bench: NVIDIA Jetson Orin

The campaign bench is an NVIDIA Jetson Orin module, an ARM64 embedded computer [1]. This target combines four properties useful for a first silicon campaign:

• an ARM64 architecture, already covered by the repository’s emulator: the existing tests apply without an architecture port;
• a boot chain publicly documented by the manufacturer, with an open-source UEFI (Unified Extensible Firmware Interface) port [1][5];
• a maintained community Yocto layer, meta-tegra, which avoids depending solely on proprietary tooling [3];
• an integrated compute accelerator, relevant for future embedded inference modules.

The Jetson Orin does not represent every tactical computer. It serves as the first target because its chain is documented and its tooling accessible. The repository’s board registry is designed to accommodate other targets under the same protocol; the lessons of this campaign will be recorded there for the next ones.

What transposes as is

Three elements move from the emulator to the Jetson without substantive change.

The board registry. The repository describes each hardware target in a registry: architecture, flashing method, expected peripherals, checkpoints. The ARM64 emulator appears there as one target among others. The Jetson Orin is added as one more entry, not as a special case: the tools that read the registry do not change.

The meta-tegra build. The OC2-Edge immutable image is produced with the Yocto Project [4]. meta-tegra, the Yocto layer for Jetson maintained by the OE4T community, provides the BSP (Board Support Package: kernel, drivers, flashing tools) as Yocto recipes [3]. The same build tree produces the emulator image and the Jetson image; only the target layer changes. The bit-for-bit reproducible build requirements (reproducible bit for bit) apply to the Jetson image as to the others; whether they are actually met on this target is a point to verify during the campaign.

USB flashing in recovery mode. The Jetson module exposes a recovery mode over USB, driven by the BSP tools [1]. The repository’s tooling wraps this flashing in the same commands as deployment to the emulator: the operator procedure is identical, only the target declared in the registry differs.

What changes: the boot chain

On the emulator, the OVMF firmware (the UEFI port for virtual machines) directly starts the signed UKI (Unified Kernel Image), which mounts the immutable base. On Jetson, the NVIDIA BSP boot chain comes before UEFI [1]:

1. the BootROM, fixed in the silicon, executes out of reset and loads MB1;
2. MB1, a binary supplied and signed by NVIDIA, initializes the hardware according to its configuration table;
3. MB2 loads the platform firmware and hands control to UEFI;
4. UEFI, here the open-source edk2-nvidia port [5], loads the UKI just as OVMF does on the emulator.

The OC2-Edge entry point stays the same: a signed UKI, verified by UEFI. Everything before UEFI changes entirely.

The anchoring of verification differs too. On the emulator, the root of trust is a UEFI variable provisioned by the repository’s tooling. On Jetson, two levels coexist: UEFI’s verification of the UKI, identical in principle to the emulator’s, and the BootROM’s verification of the earlier links (MB1, MB2, firmware), anchored in the fuses [2]. The campaign validates the first level first, without touching the second: per the doctrine, fuse anchoring stays out of scope until the last milestone.

The campaign protocol

The campaign proceeds through ordered stages. Each stage has a verifiable pass criterion; a stage only opens once the previous one is validated and documented in this log.

Stage	Content	Pass criterion
1	Boot of the meta-tegra reference BSP, without OC2-Edge	The module boots the reference image; serial console active
2	Boot of the unsigned OC2-Edge image	The immutable base boots; the node’s services respond
3	UEFI Secure Boot with development keys	The signed UKI boots; a tampered UKI is rejected at boot
4	A/B partitions and rollback	An update interrupted by a power cut falls back to the healthy partition
5	Offline TUF update chain	The node applies a signed update from local media, without network
6	Hardware anchoring (fuses), dedicated module	Separate, documented decision, after full validation of stages 1 to 5

Two rules complete the protocol. A validated stage is replayable: the corresponding procedure and scripts are versioned in the repository, and a third party with the same module can reproduce it. A failure is a data point: it is published with its identified cause, or marked as an open point if the cause is not established.

Results as they come

At the publication date of this article, this section is empty.

No stage has been validated on silicon. No boot time, no power measurement, no hardware behavior is known. The campaign is tooled; it has not yet produced results.

Publishing this section empty is a methodological choice: the protocol precedes the measurements, and readers will be able to compare what was announced with what is observed. This is a production rule of this blog: progress articles publish failures as well as successes. The next episodes of this log will fill this section, stage by stage, in protocol order. A failure will appear there on the same footing as a success, dated and documented.

Sources

1. NVIDIA, “Jetson AGX Orin, Orin NX, and Orin Nano Boot Flow”, Jetson Linux Developer Guide, 2025, https://docs.nvidia.com/jetson/archives/r36.5/DeveloperGuide/AR/BootArchitecture/JetsonOrinSeriesBootFlow.html
2. NVIDIA, “Secure Boot”, Jetson Linux Developer Guide, 2025, https://docs.nvidia.com/jetson/archives/r36.4.3/DeveloperGuide/SD/Security/SecureBoot.html
3. OE4T, “meta-tegra: BSP layer for NVIDIA Jetson platforms”, 2026, https://github.com/OE4T/meta-tegra
4. Yocto Project, “The Yocto Project”, 2026, https://www.yoctoproject.org
5. NVIDIA, “edk2-nvidia: NVIDIA EDK2 platform support”, 2026, https://github.com/NVIDIA/edk2-nvidia