Do you hit this error before applying the patch?
Could you refer to Jetpack 6 - UEFI stuck on HspDoorbellEnableChannel: Waiting for HSP Doorbell Channel Enabled - #10 by WayneWWW and check if it could help in your RAS error?
No, the initial problem I was ran into was the a failed assertion in (3):
ASSERT [FvbNorFlashStandaloneMm] /out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(937): ((BOOLEAN)(0==1))
That brought me to this thread. I then followed the steps provided above to rebuild images, update the BSP workspace, and then flash the devkit.
After that, on device boot, I now run into this RAS error instead of the assertion failure.
You are the only one hitting RAS error after applying the patch.
I would suggest you creating another topic and share the steps and each commands you used to apply the change.
Hi:
I wrote a script, to gen an optee image after patched.
assertIssueFix.tar.gz (7.4 KB)
In this script, it will get Jetpack 6.0 source and UEFI source, Apply the Patch, gen patched-tos.img and uefi_StandaloneMmOptee_RELEASE.bin after patched.
To use this script, you need to:
- Set CROSS_COMPILE_AARCH64 and CROSS_COMPILE_AARCH64_PATH, like:
export CROSS_COMPILE_AARCH64_JP6_PATH=/opt/toolchainJp6/aarch64--glibc--stable-2022.08-1/
export CROSS_COMPILE_AARCH64_JP6=/opt/toolchainJp6/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-
- Docker can be execute without sudo
- Ethernet alive
- Run script:
tar xpf assertIssueFix.tar.gz
cd assertIssueFix
bash buildOptee.sh
- After a successful run, copy
patched-tos.imganduefi_StandaloneMmOptee_RELEASE.binto Linux_for_Tegra folder:
cp patched-tos.img $JETPACK/bootloader/tos-optee_t234.img
cp uefi_StandaloneMmOptee_RELEASE.bin $JETPACK/bootloader/standalonemm_optee_t234.bin
- Flash QSPI.
(Well, after finishing this script, I found that NV actually did the almost same thing in nv_public_src_build_tos.sh. At least the things get done looks similar comparing these two scripts.)
However, when I am trying to verify the image, I found something wrong.
After I reset the UEFI setting, another assert happened. Looks like the patch is applied according to the path modified:
/home/wulun/jetpack/jp6/assertIssueFix/uefi/uefiWorkspace/edk2/StandaloneMmPkg/Core/Mmi.c(211): ((BOOLEAN)(0==1))
Full Serial Log:
assertWhenReset.txt (37.4 KB)
After resetting the system, the system didn’t went into Assert.3. I’m not sure is this an OK?
Please Help.
Many Thanks.
We don’t hit this assertion issue when we were verifying the patch.
Do you mean it can boot after 2nd reboot?
Hi KevinFFF:
Thanks for the reply.
We were trying to verify if the issue is solved by:
Reset UEFI Settings --> Auto Reboot --> Reset UEFI Settings .....
However, now we are facing:
Reset UEFI Settings --> ASSERT --> Reset via button --> Reset UEFI Settings ...
The system can still boot after we manually reset the system. But I’m afraid that the fixing of the Assert issue isn’t verified since the UEFI settings might not being reset.
I tried to verify this patch on r36.3.0 and r36.3.0-updates, both of the version will lead to this issue.
Should I raise another topic? or anything wrong with the steps?
Please Help.
Many Thanks.
Could you check if you can reproduce the similar issue with JP6.2(r36.4.3)? since we don’t hit any assertion issue in this release.
Hi KevinFFF:
Thanks for the reply. I think it’s a bug in r36.3.0 and it’s being fixed in some commit.
I tried on Devkit + just downloaded BSP to flash UEFI, and the assert still happened even if I did nothing.
But the issue is solved. Here are the steps:
Get the updated script:
assertIssueFix.tar.gz (7.3 KB)
Compared to the original one, this one:
- UEFI Binary still need to be built
- Change branch tag to
uefi-202409.1(Note: I didn’t try every release in the Wiki Combos. I just pick the latest one for r36.3)
This script will build:
- patched-tos.img → replace Linux_for_Tegra/bootloader/tos-optee_t234.img
- uefi_Jetson_RELEASE.bin → replace Linux_for_Tegra/bootloader/uefi_jetson.bin
- uefi_StandaloneMmOptee_RELEASE.bin → replace Linux_for_Tegra/bootloader/standalonemm_optee_t234.bin
Sorry Kevin, I didn’t try on R36.4, hence I can’t give you the result.
1 Like
It seems you’ve managed to get it working after applying the patch.
Thanks for sharing the script and steps for the people hitting similar issue.
Hi NVIDIA team,
We have begun using the OTA process for our Xavier NX based system. However, we have begun to hit issues with the UEFI bootloader that is causing bricked machines in the field. The boot log when this happens contains the string:
[0000.067] I> Boot-device: QSPI (instance: 0)
[0000.071] I> Qspi flash params source = brbct
...
ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t194-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(978): ((BOOLEAN)(0==1))
This leads to this forum post, which then points towards the patch in: Varint readfix r35.5.0 by gmahadevan · Pull Request #110 · NVIDIA/edk2-nvidia · GitHub. This suggests some sort of fault with the FvbNorFlashDxe module of the UEFI bootloader when updating the filesystem on the QSPI flash. Is this correct?I have a few questions about this patch:
- If I add debugging log statements to the
FvbNorFlashDxedriver initialisation and then boot a system, these statements do not make it to the serial console. Can you confirm whether this module is only loaded during OTA or whether it is supposed to be loaded on every boot? - For the attached patch, can you describe how we might test that we have applied the patch correctly? I.e. can you describe a method that we can use to put a Xavier NX into a state that would hit the bug without the patch, so that we can verify that with the patch the system performs correctly?
- Can you detail whether this patch has been tested internally at NVIDIA? The ticket has been open since November 2024, and has not yet been merged into a JetPack release, so I’m worried that we will be introducing new bugs when we apply this patch.
Thanks
Hi bgillatt,
It seems you hit Assertion 3 issue.
Yes, but the fix is included in tos image so that you have to build optee manually.
It should be loaded in each boot, please update tos image instead of UEFI binary to apply the change.
We’ve shared the reproduce steps in https://forums.developer.nvidia.com/t/assertion-issue-in-uefi-during-boot/315628#p-1531853-verification-steps-3 that it is easily to be reproduced within 5 times test.
Yes, we’ve confirmed it on our end, and many users have also verified it.
Hi NVIDIA team,
I have many modules. Some are flashed with patch. But still some modules are flashed before, without these patch.
They all have the same fw_version in /sys/fireware/efi…
How can I tell them apart quickly, by some version files, by some cmd in terminal?
Or how can I modify some source code, to tell them apart in OS.
If you’ve updated the UEFI binary, you should get different result of the following command on the board.
$ cat /sys/class/dmi/id/bios_version
$ cat /sys/class/dmi/id/bios_date
Thanks for the information. Yes, I follow the step.
Build the uefi_standalonemm_release.bin, then tos img, final flash to target board.
The dir /sys/class/dmi seems in r36.x. How about the version files in r35.6.0?
I’ve just gotten a AGX Xaiver devkit with Jetpack 5.1.5(L4T r35.6.1) to check.
$ cat /etc/nv_tegra_release
# R35 (release), REVISION: 6.1, GCID: 39721438, BOARD: t186ref, EABI: aarch64, DATE: Tue Mar 4 10:13:09 UTC 2025
$ cat /sys/class/dmi/id/bios_version
6.1-39721438
$ cat /sys/class/dmi/id/bios_date
03/04/2025
Please run the following command to check if the related kernel configs have been enabled on your board.
$ zcat /proc/config.gz |grep "CONFIG_DMI"
Or you can just simply check the version strings showing in serial console log during boot up.
e.g.
Jetson UEFI firmware (version 5.0-c0c53dad built on 2024-04-13T16:01:54+00:00)
Thanks!
Kernel “config_dmi” on my target board is not set.
I noticed this strings on screen before. Built time doesn’t change, still on 2024-8-28…
I follow the steps. Build uefi_StandaloneMmOptee_RELEASE.bin, build tos img, but only update tos image in <Linux_for_Tegra>/bootloader/tos-optee_t234.img. This may be the reason, why uefi built time string not changed.
Now, are there any way to tell them apart?
Okay, it is expected that the UEFI version/build time are the same since you don’t update UEFI binary.
Could you also check the similar messages in serial console log as following to check for OP-TEE info?
I/TC: OP-TEE version: 4.2 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Wed Apr 9 08:45:47 UTC 2025 aarch64
we have a product, using AGX Orin 32GB, prebuilt system image based on Jetson Pack 6.0.
After running for couple of month, some units wont’ boot up.
I captured debug message,
I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
I/TC: WARNING: Test UEFI variable auth key is being used !
I/TC: WARNING: UEFI variable protection is not fully enabled !
ASSERT [FvbNorFlashStandaloneMm] /out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(937): ((BOOLEAN)(0==1))
Customer wasn’t able to access the UEFI boot menu, it’s impossible caused by reset the L4T Configuration.
But these units have been cut off power couple times every day.
Is it possible this operation caused the same issue?