Synchronous Exception: UEFI Built From Source

I built UEFI from source for my Jetson Orin NX following the instructions in the 35.4.1 Developer Guide. I’m using all the firmware from release 35.4.1. I built UEFI using the stable202305 tag. (I actually tried all the tags associated with 35.4.1, but none of them worked.)

Here’s the output from UEFI during RCM boot:

Jetson UEFI firmware (version 202305.2-a8d027b1 built on 2023-12-18T22:59:41+00:00)

[     7.117641] Camera-FW on t234-rce-safe started
TCU early console enabled.

[     7.174898] Camera-FW on t234-rce-safe ready SHA1=8676d22a (crt 0.969 ms, total boot 58.277 ms)

Synchronous Exception at 0x0000000436C007B4

Synchronous Exception at 0x0000000436C007B4
ASSERT [ArmCpuDxe] /build/nvidia-uefi-stable202305/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))

Resetting the system in 5 seconds.

How can I build a working version of UEFI for 35.4.1? I followed the Build with Docker instructions exactly.

Hi robert70,

Are you using the devkit or custom board for Orin NX?

Please use the following command to clone the UEFI source for r35.4.1.

$ edk2_docker edkrepo clone nvidia-uefi-r35.4.1 NVIDIA-Platforms r35.4.1

Hi KevinFFF,

I’m using a custom carrier board for the Orin NX.

I did use that command to clone the source. I tried not only with r35.4.1, but with all tags compatible with release 35.4.1. None of them worked.

Update: When I use the same UEFI image on an Orin NX devkit carrier board it works fine. Is there any UEFI porting work that needs to be done to run on a different carrier board?

Do you mean the boot issue with new UEFI binary only happen on the custom carrier board?

Could your custom board work with the original UEFI binary released from official BSP package?

Could you also share the steps how you update UEFI binary?

Yes, the UEFI boot issue only happens on the custom carrier board.

Yes, my custom carrier board works with the UEFI binary from the official 35.4.1 release.

To update the UEFI binary, I copy the new version of uefi_jetson.bin into Linux_for_Tegra/bootloader and then run the flash command. I ensured that this is the only change I make.

By the way, different versions of UEFI present different errors. This is the error for the r35.4.1 version on my custom carrier board.

ASSERT [HiiDatabase] /build/nvidia-uefi-r35.4.1/edk2/MdeModulePkg/Universal/HiiDatabaseDxe/Font.c(303): GlyphBuffer != ((void *) 0) && Origin != ((void *) 0) && *Origin != ((void *) 0)

I’m curious how NVIDIA builds the UEFI image, because it appears to be different from what they publish in the wiki, since the official binary works with my carrier board.

Edit: I just retested all of the above so I can verify that the information is accurate.

Could you help to check if r35.4.1-updates works for your case?

edk2_docker edkrepo clone nvidia-uefi-r35.4.1-updates NVIDIA-Platforms r35.4.1-updates

Do you just replace <Linux_for_Tegra>/bootloader/uefi_jetson.bin with uefi_Jetson_RELEASE.bin built from UEFI source?

I built r35.4.1-updates and tested it. Here’s the error I get:

Synchronous Exception at 0x000000041AA687B4

Synchronous Exception at 0x000000041AA687B4
ASSERT [ArmCpuDxe] /build/nvidia-uefi-r35.4.1-updates/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))

Yes, that’s exactly what I do.

It seems the issue only happen on the custom carrier board because I could not reproduce the same issue on the devkit.

Do you have EEPROM on your custom carrier board?

Could you share the flash command you used to flash your board?
and also the full flash log for further check.

That’s correct. The issue only occurs on my custom carrier board. The devkit works without issue.

No, there is no EEPROM on the custom carrier board.

This is the flash command I use (from flashcmd.txt):

./ --bl uefi_jetson_with_dtb_sigheader.bin.encrypt --bct br_bct_BR.bct --securedev  --bldtb tmp-hive-3v0.dtb --applet rcm_2_encrypt.rcm --applet_softfuse rcm_1_encrypt.rcm --cmd "rcmboot"  --cfg secureflash.xml --chip 0x23 --mb1_bct mb1_bct_MB1_sigheader.bct.encrypt --mem_bct mem_rcm_sigheader.bct.encrypt --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader.bct.encrypt --mb1_bin mb1_t234_prod_aligned_sigheader.bin.encrypt --psc_bl1_bin psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt  --bins "psc_fw pscfw_t234_prod_sigheader.bin.encrypt; mts_mce mce_flash_o10_cr_prod_sigheader.bin.encrypt; mb2_applet applet_t234_sigheader.bin.encrypt; mb2_bootloader mb2_t234_with_mb2_cold_boot_bct_MB2_sigheader.bin.encrypt; xusb_fw xusb_t234_prod_sigheader.bin.encrypt; dce_fw display-t234-dce_sigheader.bin.encrypt; nvdec nvdec_t234_prod_sigheader.fw.encrypt; bpmp_fw bpmp_t234-TE980M-A1_prod_sigheader.bin.encrypt; bpmp_fw_dtb hive-3v0-bpmp_with_odm_sigheader.dtb.encrypt; sce_fw camera-rtcpu-sce_sigheader.img.encrypt; rce_fw camera-rtcpu-t234-rce_sigheader.img.encrypt; ape_fw adsp-fw_sigheader.bin.encrypt; spe_fw spe_t234_sigheader.bin.encrypt; tos tos-optee_t234_sigheader.img.encrypt; eks eks_t234_sigheader.img.encrypt; kernel boot.img; kernel_dtb tmp-hive-3v0.dtb"    --secondary_gpt_backup  --bct_backup

And here is the UART output while flashing:
screenlog.txt (24.4 KB)

I use this exact same command to flash the devkit, and it works. Then (without changing any files) I flash my custom carrier board and it fails. I believe we have isolated the issue to the UEFI binary.

Have you applied the following change in your case?
Jetson AGX Orin Platform Adaptation and Bring-Up — Jetson Linux Developer Guide documentation (

What I want to check is the original flash command you used to flash the board.
You should run to flash NVMe on your board with Orin NX module.
I would also like to check the full flash log.

Yes, I have applied that change.

I have modified the flash process to fit our manufacturing requirements. We do the build in one step, and the flash in another step. The command and logs I sent in the previous message are for booting into the initrd from recovery mode. The rest of the flash process works properly.

Here’s the command I use to build the binaries required to boot into the initrd:

./ \
    -c "bootloader/t186ref/cfg/flash_t234_qspi.xml" \
    -d "../kernel/kernel_out/arch/arm64/boot/dts/nvidia/hive-3v0.dtb" \
    -I "../initramfs/initramfs-flash" \
    -K "../kernel/kernel_out/arch/arm64/boot/Image" \
    --sign \
    --no-flash \
    --no-systemimg \
    --no-root-check \
    --rcm-boot \
    "p3768-0000+p3767-0000-nvme" "internal"

Here is the log of this build command:
build-log.txt (65.0 KB)

I repeat that the issue does not appear to be with the flashing process, because the process works flawlessly with the UEFI binary distributed by NVIDIA. The problem is that I am unable to build a UEFI binary that works on my custom carrier board. NVIDIA was able to build it. Please share the UEFI build steps that NVIDIA uses, or give me another way to build a working UEFI image.

It is the log of building the image w/o flash.
I want to check the flash log showed on your host during flash process.

Could you replace the <Linux_for_Tegra>/bootloader/uefi_jetson.bin with the following UEFI binary
uefi_Jetson_RELEASE.bin (2.5 MB)
and check if there’s still boot issue in UEFI?

Here’s the flash log shown on my host while I’m flashing. Note that it doesn’t get very far because it can’t even boot into the initrd from recovery mode, because of the UEFI exception:

Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

 Entering RCM boot

[   0.0436 ] mb1_t234_prod_aligned_sigheader.bin.encrypt filename is from --mb1_bin
[   0.0436 ] psc_bl1_t234_prod_aligned_sigheader.bin.encrypt filename is from --psc_bl1_bin
[   0.0436 ] rcm boot with presigned binaries
[   0.0441 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
[   0.0449 ] BR_CID: 0x80012344705E364474000000140002C0
[   0.3778 ] Sending bct_br
[   0.3783 ] Sending mb1
[   0.3799 ] Sending psc_bl1
[   0.3910 ] Sending bct_mb1
[   0.3970 ] Generating blob for T23x
[   0.4035 ] tegrahost_v2 --chip 0x23 0 --generateblob blob.xml blob.bin
[   0.4051 ] The number of images in blob is 18
[   0.4075 ] blobsize is 103745370
[   0.4085 ] Added binary blob_uefi_jetson_with_dtb_sigheader.bin.encrypt of size 2981952
[   0.4473 ] Added binary blob_pscfw_t234_prod_sigheader.bin.encrypt of size 375168
[   0.4484 ] Added binary blob_mce_flash_o10_cr_prod_sigheader.bin.encrypt of size 190592
[   0.4498 ] Added binary blob_applet_t234_sigheader.bin.encrypt of size 277312
[   0.4504 ] Not supported type: mb2_applet
[   0.4507 ] Added binary blob_mb2_t234_with_mb2_cold_boot_bct_MB2_sigheader.bin.encrypt of size 438768
[   0.4519 ] Added binary blob_xusb_t234_prod_sigheader.bin.encrypt of size 164864
[   0.4526 ] Added binary blob_display-t234-dce_sigheader.bin.encrypt of size 9097216
[   0.4556 ] Added binary blob_nvdec_t234_prod_sigheader.fw.encrypt of size 294912
[   0.4574 ] Added binary blob_bpmp_t234-TE980M-A1_prod_sigheader.bin.encrypt of size 1051136
[   0.4586 ] Added binary blob_hive-3v0-bpmp_with_odm_sigheader.dtb.encrypt of size 138880
[   0.4591 ] Added binary blob_camera-rtcpu-sce_sigheader.img.encrypt of size 166304
[   0.4597 ] Added binary blob_camera-rtcpu-t234-rce_sigheader.img.encrypt of size 537952
[   0.4603 ] Added binary blob_adsp-fw_sigheader.bin.encrypt of size 400864
[   0.4608 ] Added binary blob_spe_t234_sigheader.bin.encrypt of size 270336
[   0.4614 ] Added binary blob_tos-optee_t234_sigheader.img.encrypt of size 1127568
[   0.4621 ] Added binary blob_eks_t234_sigheader.img.encrypt of size 9232
[   0.4633 ] Added binary blob_boot.img of size 85880832
[   0.4934 ] Added binary blob_tmp-hive-3v0.dtb of size 340378
[   0.5679 ] tegrarcm_v2 --chip 0x23 0 --pollbl --download bct_mem mem_rcm_sigheader.bct.encrypt --download blob blob.bin
[   0.5683 ] BL: version last_boot_error: 0
[   0.6397 ] Sending bct_mem
[   0.6400 ] Sending blob
[   6.0944 ] RCM-boot started

Yes, I just tested my custom carrier board with the binary you provided. I get the same error. Here’s the log:
screenlog.txt (24.5 KB)

So, the issue is not coming from the build process for UEFI binary.

Do you mean that it could not be flashed successfully due to boot issue?

Could you enable UEFI debug messages by replacing <Linux_for_Tegra>/bootloader/uefi_jetson.bin with the uefi_Jetson_DEBUG.bin?

I think the issue is coming from the build process for the UEFI binary.

Here’s my current understanding of the problem. Please correct me if any of it seems incorrect to you.

The fact that I can use uefi_jetson.bin distributed in the 35.4.1 release, but not uefi_Jetson_RELEASE.bin from my own build means that the UEFI build process for the 35.4.1 release is different than the one on the wiki. If they were the same build process, then they would produce identical binaries and both would work. The build process from the wiki is valid for the Orin devkit carrier board, but not valid for my custom carrier board. The build process for the 35.4.1 release is valid for both boards, because it works on both boards.

That’s correct. I can flash the board with the 35.4.1 UEFI binary, but not with the one I build. If UEFI crashes, it won’t boot so there’s no way to flash the board. (I’m using an external NVME so the only flash option is initrd flash.)

Here’s a log from booting the UEFI debug image:
screenlog.txt (92.9 KB)

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.

It is a synchronous exception.
Could you share the device tree and point out what’s your custom modification in device tree?