Flash UEFI

Is it possible to burn UEFI separately, because burning the whole thing takes too much time?


YES, it’s possible.
Please do:

sudo ./flash.sh -r -k A_cpu-bootloader <board> <rootdev>

In case you enable A/B redundancy, then also update B_cpu-bootloader.


I’m facing the a similar situation as @542270618.

BTW, on Xavier NX, the UEFI partition is cpu-bootloader (respectively cpu-bootloader_b for the B slot). A_cpu-bootloader is for AGX Orin, Orin NX, Orin Nano.

Building and updating bootloader/uefi_jetson.bin works for me with a full flashing. However, flashing only the cpu-bootloader partition always breaks the boot.

If the active boot chain is 0, flashing cpu-bootloader leads the bootloader to fail and to switch the active boot chain to 1.
Then when I flash cpu-bootloader_b, the active boot chain is no longer happy with boot chain 1 and switches back to chain 0. The boot ends up being stuck at MB1.

[0000.916] I> Default Heap @ [0xd486400 - 0xd48a400]
[0000.918] E> DEVICE_PROD: Invalid value data = 70020000, size = 0.
[0000.923] W> device prod register failed
[0000.927] I> gpio framework initialized
[0000.930] I> tegrabl_gpio_driver_register: register 'nvidia,tegra194-gpio' driver
[0000.938] I> tegrabl_gpio_driver_register: register 'nvidia,tegra194-gpio-aon' driver
[0000.946] I> No valid sdcard_params in mb1_bct
[0000.950] I> Boot_device: QSPI_FLASH instance: 0
[0000.954] I> qspi flash-0 params source = boot args
[0000.960] I> QSPI-0l initialized successfully
[0000.963] I> sdmmc-3 params source = safe params
[0001.304] I> sdmmc DDR50 mode
[0001.322] I> Found 41 partitions in QSPI_FLASH (instance 0)
[0001.339] W> Cannot find any partition table for 00000003
[0001.340]  > PARTITION_MANAGER: Failed to publish partition.
[0001.356] I> Found 22 partitions in SDMMC_USER (instance 3)
[0001.357] I> Active Boot chain : 1
[0001.382] E> Stage2Signature validation failed with SHA2!!
[0001.383] I> ����������������: execution failed
[0001.383] I> ����������������: execution failed
[0001.384] E> Top caller module: LOADER, error module: LOADER, reason: 0x18, aux_info: 0x00
[0001.384] I> AB warm reset
[0000.025] W> RATCHET: MB1 binary ratchet value 4 is larger than ratchet level 2 from HW fuses.
[0000.033] I> MB1 (prd-version:
[0000.039] I> Boot-mode: Coldboot
[0000.041] I> Platform: Silicon
[0000.044] I> Chip revision : A02P
[0000.047] I> Bootrom patch version : 15 (correctly patched)
[0000.052] I> ATE fuse revision : 0x200
[0000.056] I> Ram repair fuse : 0x0
[0000.059] I> Ram Code : 0x0
[0000.062] I> rst_source: 0xb, rst_level: 0x1
[0000.066] I> Boot-device: QSPI (instance: 0)
[0000.070] I> Qspi flash params source = brbct
[0000.074] I> Qspi clock source : pllp
[0000.078] I> Qspi-0 initialized successfully
[0000.082] I> Boot chain mechanism: A/B
[0000.085] I> Current Boot-Chain Slot: 0
[0000.089] E> Error, current slot 0 fails: sr_bl: 0xd14ef1, sr_br: 0x0
[0000.095] I> Reset to recovery mode

@542270618: I’m curious to know if the provided reply works for you, or if you face a similar issue than I described.

Looking forward to reading the updates.

I don’t know why you are doing this.
You are supposed to flash both partitions.

Hi @DaveYYY,

Sorry if my post was unclear. Could you be a bit more explicit than:

I don’t know why you are doing this.
You are supposed to flash both partitions.

You mean flashing one after the other cpu-bootloader and cpu-bootloader_b?
I’m not aware of any command to flash both at the same time. My goal is not to bring them out of sync, but whatever I re-flash on them always break the boot. Only the full flashing works for me. I’m trying to do the same thing as @542270618 posted.

I worked with the secure-os or spe partitions successfully. On these, I can flash the specific partition and get the changes deployed, as long as the partition flashed is matching the active slot.

Is there any extra care required when dealing with the cpu-bootloader partitions to deploy the UEFI firmware?

Please @DaveYYY, feel free to clarify the procedure. Thanks.

Have you tried switching the order of flashing these two?
Like when you are booting from chain A, you flash chain B; then you switch to boot from chain B, and flash chain A.


Dear @DaveYYY,

Thanks for your proposal. I tried it, but I was not successful. Here is the full procedure I followed:

  • Full flashing > Boots successfully on slot A
  • Reboot to recovery, flash cpu-bootloader_b > Boots successfully on slot A
0015.773] I> Writing cpu-bootloader_b partition.
[0037.077] I> Rebooting : reset-coldboot
[0000.082] I> Boot chain mechanism: A/B
[0000.085] I> Current Boot-Chain Slot: 0
[0000.089] I> BR-BCT Boot-Chain: 0, status: 0. update flag: 0
  • Request to change active slot to B
sudo nvbootctrl set-active-boot-slot 1
  • Reboot the board > UEFI requests the boot chain change.
Jetson UEFI firmware (version 202210.3-ce6d1ddd built on 2023-12-15T13:35:10+00:
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
Rebooting to new boot chain
[0000.085] I> Current Boot-Chain Slot: 1
  • Hard power off during MB2
  • Boot into recovery mode and flash cpu-bootloader
[0016.692] I> Writing cpu-bootloader partition.
[0000.089] E> Error, current slot 0 fails: sr_bl: 0xd14ef1, sr_br: 0x0
[0000.095] I> Reset to recovery mode

None of the boot chain works => board goes to recovery

I attached the full log after the flashing of the cpu-bootloader partition here: boot_log.txt (7.2 KB)

I’m looking forward to hearing more insights about why re-flashing the cpu-bootloaderpartitions is causing these issues.


I’ve done some confirmation with our internal team, and the order of which partition is flashed first should not be impacting here.

Can you please try cold rebooting the device each time the flashing process completes?
Or power off the device, and wait for a while before powering it on again.

Hi @DaveYYY,

Thanks for your fast feedback.
After each flashing, I turned off the power, disconnected all cables and waited a bit. But unfortunately the outcome is the same.


I have verified the workflow locally on my device, and I can freely flash either cpu-bootloader/cpu-bootloader_b and switch between them with nvbootctrl.

In case you are using the SD card module, make sure it’s plugged in to the device all the time because part of bootloader stuff is stored on the SD card, instead of entirely on QSPI. It’s the same for the eMMC module, so make sure eMMC is fully flashed.

Hi @DaveYYY,

Thanks a lot for taking the time to test on your device, much appreciated.

Then it’s quite of a mystery. I’m not using a SD card. I’m using the eMMC with full flashing followed by reflashing either cpu-bootloader/cpu-bootloader_b.

As soon as I touch the partition in the active chain, the boot breaks. If you see any debug traces that I could check to get more insights, feel free to let me know.

Hi @DaveYYY
Is there a way for UEFI to burn into emmc through the dd command? Facilitate user space upgrades

At present, our device is not convenient to enter recovery mode

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Please open a new topic for your own issue. Thanks