Re-Flash AGX Orin without flashing APP partition

Hi Nvidia:
We are using AGX Orin 64GB on a custom board.
We encounter a strange issue. After a lots of reboot, the system will not able to boot, and the system will hang at:

 ASSERT [FvbNorFlashStandaloneMm] /out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(937): ((BOOLEAN)(0==1))

Full serial log is attached:
uefiNotPassed.txt (61.2 KB)

We were running an auto-reboot testing. To do so, we use a service in Linux to poweroff after the Linux is boot up for 2 min. Another device, will then cut down the power supply and resupply the power. As a result, the AGX Orin will Boot up → Power off → Cut down power → Re-supply power → Boot up.

However, after around 500 times cycles, the system will not able to boot again. The serial log is attached above.


We captured some logs, but they are stored in eMMC. Is there a way to recover this situation without killing the data in eMMC?
We tried ./flash.sh -r -k A_cpu-bootloader jetson-agx-orin-devkit internal and ./flash.sh -r -k B_cpu-bootloader jetson-agx-orin-devkit internal , since the log looks like an UEFI issue. But it doesn’t work.

Please help.

Many thanks.

Hi jameskuo,

What’s your Jetpack version in use?

Do you update the UEFI binary and do any modification in UEFI source?

Have you enabled disk-encryption/UEFI secureboot/Secureboot on your custom board?

1 Like

Hi Kevin:
Thanks for the reply.

We are using Jetpack 6.0.

No, we use the one in Linux_for_Tegra. Never touch them.

No, we didn’t touch it.

Do you get that binary in the custom BSP package from your vendor?

  Jetson UEFI firmware (version 202406.0-a9a61c80-dirty built on 2024-07-17T01:45:16+00:00)

It seems that you are using the custom UEFI debug binary so that there’s the debug messages in UEFI.

Do you have the AGX Orin devkit to reproduce the same issue?

Hi Kevin:
Sorry for the misleading.
When the issue happened, we were using UEFI binary from Jetpack 6.0 BSP. That’s what I mean “Never touch them”.

And, as the post said, we tried to re-flash the A_cpu_bootloader and B_cpu-bootloader, trying to recover the situation and get the log in APP partition. That leads to the logs you saw. The only change in our built UEFI binary is to change the logo.

But we still can’t get the data in APP partition.

Could you try running the following command to flash QSPI only to check if it may help for your case?

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

Hi Kevin:
Thanks for the reply. This one works.

The log we got is attached. It was created by journalctl -f | tee logs every time before we poweroff the orin.
We expect some unaware apt upgrades or package installed, just like the issue happend in here.

journalctlLogs.txt (400.3 KB)

We will re-flash the system, and give it another try, see if we can reproduce the issue in a more stable way.

Many Thanks.

1 Like

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