wolfBoot now runs as bare-metal firmware on the NVIDIA Jetson Orin (Tegra234), replacing the vendor UEFI stage entirely and extending the SoC’s hardware root of trust to the operating system through a small, auditable verifier.
The Jetson Orin boot chain
The Orin boots a fused, signed chain: BootROM to MB1 to MB2 to ARM Trusted Firmware (BL31), which then hands control to a normal-world bootloader stage called BL33. On Jetson that slot holds a full edk2 UEFI environment.
The straightforward way to add wolfBoot is to run it as a UEFI application on top of that firmware. It works, it is board-agnostic, and wolfBoot supports it. But it leaves an entire UEFI stack, with its drivers, filesystem and network parsers and shell, sitting between the hardware root of trust and the code that verifies your kernel.
wolfBoot in the BL33 slot
The tegra234 target replaces that stage. ARM Trusted Firmware hands off directly to wolfBoot at EL2 non-secure with the MMU off, and wolfBoot brings up what it needs itself:
- Tegra Combined UART (TCU) console over the AON HSP shared mailbox, the same console the rest of the boot chain uses
- ARMv8 generic timer, and a BPMP IPC driver for clocks and resets over the CPU-NS IVC channel
- ARMv8 Crypto Extension acceleration for the verification itself
It then verifies the next stage with wolfCrypt using ECC P-384 and SHA-384, drops from EL2 to EL1, and enters the payload with a device tree pointer in x0, which is the standard arm64 Linux boot contract. No vendor UEFI is involved at any point.
This is validated on Jetson Orin Nano developer-kit hardware over a non-persistent RCM boot: wolfBoot runs as BL33, verifies the payload, drops to EL1 and hands off, straight out of DRAM with no storage driver in the path.
Why replace UEFI rather than run on it
- Minimal trusted computing base. wolfBoot is tens of kilobytes. Replacing BL33 removes a multi-megabyte firmware environment from the trust path: no network boot, no filesystem parsers, no option ROMs, no shell.
- Closest reachable point to the root of trust. Verification happens immediately after ARM Trusted Firmware, the earliest stage reachable on an unfused developer board, rather than after a full firmware environment has already executed.
- One auditable crypto path. Verification is performed solely by wolfCrypt with NIST-approved ECC P-384 and SHA-384, not split across a separate UEFI crypto stack.
- Deterministic and fully owned. A small, fixed, reviewable codebase controls the handoff end to end, with no dependence on vendor UEFI configuration.
The trade-off is scope. The bare-metal target is Tegra234-specific and brings up its own drivers, where the aarch64_efi UEFI-application build runs unchanged on any AArch64 UEFI platform. Both ship in wolfBoot: choose minimum trusted surface per platform, or portability.
What ships
Four example configurations: a plain EL2 boot, the EL2 to EL1 device-tree boot, a microSD/SDHCI variant, and a bare-metal wolfCrypt benchmark payload that runs the full test and benchmark suite with no OS underneath. All are covered by CI, along with an EL2 exception vector table that turns a fault into a printable ESR/ELR/FAR report rather than a silent core shutdown.
Booting a full Linux kernel from on-board storage is in progress, bounded by two documented limits: MB2 caps the BL33 image at 4 MB, so a kernel must come from storage rather than be bundled, and the microSD (SDHCI) path is blocked on the closed source SDMMC1 controller bring-up. The SDHCI driver compiles and probes today; it does not yet boot from card.
For platforms where a vendor UEFI is acceptable or required, wolfBoot’s aarch64_efi target is already validated end to end on this same board: UEFI Secure Boot to an sbsigned wolfBoot to a wolfCrypt-verified Linux kernel, with the kernel command line carried in the signed manifest so boot arguments cannot be altered without breaking the signature.
Check out PR#839
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now