jetsonuefibootbspcarrier boarddebugging

Jetson UEFI shell at boot: assertion errors and how to recover

Andres Campos ·

Key Insights

  • Jetson Orin (and Thor) uses UEFI — when boot fails for any reason, it drops to an interactive UEFI shell instead of showing a helpful error
  • Five failure modes cover nearly all cases: corrupted QSPI bootloader, wrong DTB in extlinux.conf, ODMDATA mismatch, failed fuse burn, or corrupted A/B boot partition from a bad OTA
  • First diagnostic: does the module appear as “NVIDIA Corp. APX” in lsusb? Yes → recoverable via reflash; No → hardware or power issue
  • From the UEFI shell, fs0: → ls tells you immediately if the boot filesystem is visible
  • Secure boot fuse burn failures cannot be recovered without NVIDIA involvement — don’t experiment with fuse burning on production hardware

Why Jetson Orin uses UEFI and what the shell means

Jetson Xavier (and earlier) used CBoot, NVIDIA’s proprietary bootloader. Starting with Orin-series modules and JetPack 5.0, NVIDIA moved to UEFI. This aligns with industry standards and enables secure boot, A/B partitioning, and standard EFI boot entries — but it also means a new class of boot failures that look nothing like CBoot failures.

When UEFI can’t complete its boot sequence, it drops to the interactive UEFI shell — the same shell you’d see on a standard x86 UEFI motherboard. This can happen with or without an assertion error message.

An assertion failure looks like this in the serial console:

ASSERT_EFI_ERROR (Status = Not Found)
ASSERT /home/oe-user/oe-workdir/.../TegraBootManager.c(146): !EFI_ERROR (Status)

UEFI Interactive Shell v2.2
UEFI v2.70 (NVIDIA, 0x00010000)
Shell>

A quieter drop looks like:

BdsDxe: failed to load Boot0001 "UEFI Misc Device" from ...
BdsDxe: failed to load default boot option
Shell>

Both land you at the Shell> prompt with no kernel booted.

The five failure modes that cause a UEFI shell drop on Jetson

1. Corrupted or mismatched QSPI bootloader

The UEFI firmware itself lives in QSPI flash. If it was partially written during a failed flash, or if the QSPI contains a bootloader from a different JetPack version than your rootfs, boot will fail. This is the most common cause after a flash attempt that was interrupted.

Confirm it: on the host, check if the Jetson appears as “NVIDIA Corp. APX” in lsusb when you hold the recovery button. If it does, the module is alive and can be reflashed. If it doesn’t appear at all, power sequencing or hardware may be the issue.

2. DTB not found or wrong DTB

The UEFI bootloader loads a device tree blob (DTB) before handing off to the kernel. If extlinux.conf references a DTB filename that doesn’t exist on the boot partition, or if the partition is corrupted, UEFI will fail with Not Found and drop to the shell.

Check: from the UEFI shell, navigate to the boot filesystem and inspect the files:

Shell> fs0:
fs0:\> ls
fs0:\> cd EFI\BOOT
fs0:\EFI\BOOT\> ls

If you can’t see fs0: at all, the boot partition isn’t visible to UEFI — either it’s corrupted, or the partition table got mangled.

3. ODMDATA mismatch

ODMDATA encodes the module variant and carrier board configuration. If the ODMDATA in QSPI doesn’t match the module you’re booting (common when reflashing with the wrong board config), the bootloader may assert before even finding the kernel.

This is especially common on custom carrier boards where the ODMDATA was set for one Orin variant and someone reflashed with a BSP for a different one.

4. Failed fuse burn

If you enabled secure boot (fused mode) and the fuse burn didn’t complete correctly, the bootloader will assert at the signature verification step. The forum thread with 5.5k views is largely this case — “Failed Assert during Boot (Post fuse burn).” There’s no recovery path without NVIDIA support if PKC fuses were partially burned.

5. Corrupted boot partition after OTA

A failed OTA update — especially the JP5 → JP6 migration that OTA doesn’t actually support — can leave the A slot boot partition in an inconsistent state. UEFI tries slot A, finds it invalid, tries slot B, finds it equally bad, and drops to the shell.

How to diagnose which failure mode you have

Work through this in order:

# On the host: check if module is in recovery mode
lsusb | grep -i nvidia
# "NVIDIA Corp. APX" = recovery mode, can reflash
# Nothing = hardware or power issue

If the module is in recovery mode, you can recover. Run the full flash including bootloader:

# From your L4T package root (adjust for your board and JetPack version)
sudo ./flash.sh jetson-orin-nano-devkit internal

If the module boots to the UEFI shell (not recovery mode), try to diagnose from there:

Shell> fs0:                     # Try boot filesystem
Shell> fs1:                     # If fs0 isn't visible, try fs1
fs0:\> cat extlinux\extlinux.conf  # Check what DTB and kernel it references

If extlinux.conf references a DTB that doesn’t exist in the filesystem, that’s your problem. Copy the correct DTB from the L4T package.

If extlinux.conf looks correct and the files exist, try booting manually:

fs0:\> \EFI\BOOT\BOOTAA64.EFI

If that fails with an assertion, you’re into QSPI corruption or a fuse issue — reflash is required.

Recovery: the standard path

For most UEFI shell issues on Jetson (excluding secure boot / fuse problems), the recovery procedure is:

  1. Hold the Force Recovery button and power cycle the board
  2. Confirm lsusb shows “NVIDIA Corp. APX” on the host
  3. Flash with the complete BSP including bootloader (not just the rootfs)
  4. Don’t interrupt the flash — QSPI writes are the most corruption-prone step
# Full flash including bootloader (do not use --no-flash-bootloader)
cd Linux_for_Tegra
sudo ./flash.sh -r <board-config> internal

The -r flag reuses your existing rootfs image if you want to preserve data. Remove -r to do a full clean flash.

For custom carrier boards, make sure you’re using the correct board config for your specific module + carrier combination. Flashing an Orin NX board config onto an Orin Nano module will produce ODMDATA mismatches and put you right back in the UEFI shell.

When you’re in harder territory

The standard recovery path above handles the common cases. It gets more complicated when:

  • Secure boot / fuse errors: If PKC fuses were partially burned, recovery may require NVIDIA intervention. This is not a DIY fix.
  • Custom carrier board with vendor BSP: Your flash script and board config may be in the vendor’s SDK, not the standard L4T package. Flashing with the wrong config can make things worse.
  • A/B slot corruption in production: If devices are deployed in the field and the OTA mechanism corrupted both slots, recovery requires physical access and a recovery-mode flash.
  • Thor (T5000): The UEFI implementation on Thor differs from Orin. Boot failure modes are similar but the firmware internals are different.

We’ve recovered from UEFI shell drops on custom carrier boards a number of times — usually from ODMDATA mismatches after board respins or interrupted flashes. If you’re stuck and reflash isn’t working, book a scoping call and we’ll diagnose from your serial log.

For related boot issues, see Jetson carrier board not booting: 6 root causes nobody documents and our JetPack versions and L4T compatibility table for confirming you’re using the right BSP. If you’re dealing with A/B slot issues on top of the UEFI problem, see Jetson A/B OTA updates: what breaks on custom carrier boards.

The UEFI Interactive Shell is documented in the UEFI specification. NVIDIA’s Jetson-specific bootloader documentation is in the Jetson Linux Developer Guide.

Frequently Asked Questions

Why does Jetson Orin drop to the UEFI shell instead of booting?

Jetson Orin uses UEFI instead of the older CBoot bootloader. When UEFI can’t find a valid boot entry — because the bootloader in QSPI is corrupted, the DTB is missing, extlinux.conf references a wrong file, or there’s an ODMDATA mismatch — it drops to the interactive UEFI shell.

What does ASSERT_EFI_ERROR mean on Jetson boot?

ASSERT_EFI_ERROR is an EFI assertion failure. UEFI tried to do something (read a file, locate a protocol, boot an entry) and got an unexpected error code. Common causes: corrupted QSPI, missing DTB, or a failed fuse-burn operation. The file and line number in the output point to which UEFI module triggered the failure.

Can I recover from a UEFI shell drop without reflashing?

Sometimes. If the issue is a wrong boot entry or corrupted extlinux.conf, you can manually boot from the UEFI shell using fs0: and then \EFI\BOOT\BOOTAA64.EFI. If QSPI is corrupted or the bootloader version mismatches your JetPack, you need to reflash.

How do I get back to normal boot after the UEFI shell appears?

From the UEFI shell: fs0: then ls to see if your boot partition is visible, then \EFI\BOOT\BOOTAA64.EFI to attempt a manual boot. If no filesystem is visible, QSPI or the boot partition is corrupted and you need to reflash via recovery mode.

Does the Jetson UEFI shell issue happen on Xavier or only Orin?

UEFI is used on Orin-series modules (AGX Orin, Orin NX, Orin Nano) and Thor. Jetson Xavier uses CBoot, not UEFI, so it has different boot failure modes. The UEFI shell drop is specific to Orin and later.

ProventusNova helps hardware startups get through Jetson boot failures without burning a week on serial console debugging. If a UEFI assertion is blocking your custom carrier board bring-up, book a scoping call.

← Back to Blog