Orin NX FvbNorFlashStandaloneMm.c(868) Boot Failure

[noah.g]

Hello,

We have been using a series of Orin NX dev kits (Orin Nano board with Orin NX 16GB module installed) for a variety of data collection systems and development environments. We have experienced an issue with some of these systems where after a while, the system will fail to boot. When checking the boot log (attached) we find that there is an assertion during the boot process and it fails after the below message:

“ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(868): ((BOOLEAN)(0==1))”

We are using JetPack version 5.1.4 which we install through Nvidia SDK manager. We do not custom build the operating system or the Linux Kernel.

This issue seems to happen randomly and without any cause that we can find. Is there a known bug with this build or version that can cause this to happen? Is there some other root cause that can be pointed to which would cause this problem? From our experiences, this seems to happen out of nowhere with no identifiable root cause, so any guidance that can be provided would be appreciated.

Thank you,
Noah
orin_nx_boot_failure.log (33.5 KB)

[DavidDDD]

Hi,

Could you execute below commands and share results for us to review?

cat /etc/nv_tegra_release 

Thanks

[DavidDDD]

Hi,

Please refer to the Assertion issue discussion in

Assertion issue in UEFI during boot

There are several topics relating to assertion issues in Jetpack 5 and 6. We create this post to share some possible fixes and the verification steps. Possible Errors Assertion 1. ASSERT [VariableStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3264): !(((INTN)(RETURN_STATUS)(Status)) < 0) Fix: diff --git a/core/arch/arm/kernel/stmm_sp.c b/core/arch/arm/kernel/stmm_sp.c index 1d6344d…

Thanks

[noah.g]

I am not able to boot into the operating system to run this command directly, but I have removed the drive from the machine and was able to access the files on a separate Linux system. The command returns the following:

R35 (release), REVISION: 5.0, GCID: 35550185, BOARD: t186ref, EABI: aarch64, DATE: Tue Feb 20 04:46:31 UTC 2024

It seems that I was incorrect before and this system is indeed running 5.1.3 which does not have many of the fixes in the page you shared. We will upgrade to 5.1.4.

A behavior we experienced which I find strange is the system has no problem booting if I just swap the Orin NX processor for a different Orin NX or Orin Nano processor. Is this behavior expected? Why might this failure mode be tied to the specific CPU hardware rather than the software installation?

[DavidDDD]

Hi,

It is a known issue in JP5.1.3.
It’s not related to specific CPU hardware.

Thanks