Orin boot process hangs after UEFI

[tdl2]

The setup

• Orin NX nano based custom board and modified kernel (slightly modified pinmux, no EEPROM)
• Flashing using Jetson_Linux_R36.4.3
• Custom UEFI (cloned with edk2_docker edkrepo clone nvidia-uefi NVIDIA-Platforms r36.4.3 and modified. Disabled shell and some minor stuff)
• Flashing with command ./tools/kernel_flash/l4t_initrd_flash.sh
–external-device nvme0n1p1
-c tools/kernel_flash/flash_l4t_t234_nvme.xml
-p “-c bootloader/generic/cfg/flash_t234_qspi.xml”
–showlogs
–network usb0
jetson-orin-custom internal

I already have a working setup workspace with a slightly older L4T version. However, there are no instructions/documentation on all the modifications that were done to this to get it to work. And I am very new to this process.

The working setup works fine. It has an already built UEFI image and already built kernel.

Problem

My build succeeds and I can flash. However it hangs after a point, looks like in between UEFI and EFI. Here’s where the logs differ (green is the good boot log)

 Enter to continue boot.
-......L4TLauncher: Attempting Direct Boot
+L4TLauncher: Attempting Direct Boot
 EFI stub: Booting Linux Kernel...
 EFI stub: Using DTB from configuration table
 EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
@@ -9,9 +9,10 @@
 I/TC: Dynamic shared memory is enabled
 I/TC: Normal World virtualization support is disabled
 I/TC: Asynchronous notifications are disabled
-��TCU debug prints will be routed to traces.
-��Starting RmBootstrap
-Registered event_type:[0] for dce_core_ipc_type:[1]
-Registered event_type:[1] for dce_core_ipc_type:[3]
-dce_ipc State Initialized
-RmBootstrap completed successfully <<<========== bootup hangs here
+��[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd421]
+Linux version 5.15.148-tegra (user@laptop) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.08) 11.3.0, GNU ld (GNU Binutils) 2.38) #2 SMP PREEMPT Tue Jun 17 13:51:07 CEST 2025 ()
+Machine model: NVIDIA Jetson Orin NX Engineering Reference Developer Kit
+efi: EFI v2.70 by EDK II
+efi: RTPROP=0x26de4e698 TPMFinalLog=0x25ea10000 SMBIOS=0xffff0000 SMBIOS 3.0=0x26da70000 MEMATTR=0x267a90018 ESRT=0x267a8ff98 TPMEventLog=0x25ea29018 RNG=0x25ea28018 MEMRESERVE=0x25ea2bc18
+random: crng init done
+secureboot: Secure boot disabled 
...<<<============= bootup continues

Here’s some stuff I tried, but still getting stuck at the same place in the debug log on bootup.

1. good uefi + my kernel build does not work (simply copied bootloader/uefi_jetson.bin and reflashed)
2. good kernel/Image + my build does not work (copied the file, did not rebuild)

Here are the differences/similarities I see in the two L4T directories

1. Same kernel/dtb/L4TConfiguration.dts
2. My rootfs/ is 6.6G while the good one’s is 7.6G
3. jetson-orin-custom.conf file with only minor changes in PINMUX_CONFIG file

Something very weird I noticed is that sudo du -sh rootfs/usr/lib/aarch64-linux-gnu/dri/* in my workspace shows me only armada-drm_dri.so while in the good one it contains 43 .so files in total. This is the biggest cause for the size difference it seems. However ls -l rootfs/usr/lib/aarch64-linux-gnu/dri/* in there do show the correct files with names, and they all are exactly the same to the files in the working L4T.

Is the problem in UEFI? Or how do I find out where it is?

Also is my build order correct (see TL;DR)? extract sources → do changes → build kernel → update UEFI binary (separately built).

---

goodlog.txt (53.7 KB)

badlog.txt (33.2 KB)

---

TL;DR

Here’s how I extract everything

tar xf "${L4T_RELEASE_PACKAGE}"
sudo tar xpf "${SAMPLE_FS_PACKAGE}" -C Linux_for_Tegra/rootfs/

cd Linux_for_Tegra/
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh


cd ..
tar xf "${PUBLIC_SOURCES}"
cd "${L4T_DIR}/source"
tar xf kernel_src.tbz2
tar xf kernel_oot_modules_src.tbz2
tar xf nvidia_kernel_display_driver_source.tbz2

Then I do the changes in the files I need (add custom config and pinmux files, update defconfig, set cvb_eeprom_read_size = 0 and some other minor changes on some dtsi files)

Then I build the kernel.

cd "$L4T_DIR/source"
local kernel_dir="kernel/kernel-jammy-src/"

local build_dir="$L4T_DIR/build"
local kernel_modules_dir="$L4T_DIR/kernel_modules"

make -C kernel LOCALVERSION=-tegra -j$(nproc)

export INSTALL_MOD_PATH="$L4T_DIR/rootfs"
sudo -E make install -C kernel LOCALVERSION=-tegra -j$(nproc)
cp "$kernel_dir/arch/arm64/boot/Image" "$L4T_DIR/kernel/Image"

export KERNEL_HEADERS="$PWD/$kernel_dir"
make modules LOCALVERSION=-tegra -j$(nproc)

sudo -E make modules_install LOCALVERSION=-tegra -j$(nproc)

cd "$L4T_DIR"
sudo ./tools/l4t_update_initrd.sh

cd "$L4T_DIR/source"
make dtbs LOCALVERSION=-tegra -j$(nproc)
cp kernel-devicetree/generic-dts/dtbs/* ../kernel/dtb/

Then I copy the cutom UEFI binary into bootloader/uefi_jetson.bin

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, it appears that you are experiencing issues with booting up your custom Jetson AGX Orin NX-based board after modifying the kernel and pinmux. You have a working setup with an older L4T version, but you are struggling to replicate the same setup with a newer version.

To troubleshoot the issue, let’s break down the differences between the working setup and your modified setup:

1. UEFI image: You mentioned that the working setup has an already built UEFI image, while your modified setup has a newly built UEFI image. This could be a potential cause of the issue. Try using the same UEFI image from the working setup to see if it resolves the problem.
2. Kernel build: You mentioned that your kernel build succeeds, but it hangs during bootup. Try using the same kernel build from the working setup to see if it resolves the issue.
3. Pinmux modifications: You mentioned that you modified the pinmux, which could be causing the issue. Try reverting the pinmux modifications to see if it resolves the problem.
4. L4T directory differences: You noticed that the L4T directories have different sizes (66G vs 76G) and file contents. This could indicate that there are differences in the configuration or build process between the two setups. Try comparing the flash.sh scripts and configuration files between the two setups to identify any differences.
5. /boot directory contents: You noticed that the /boot directory in your modified setup has only 1 file, while the working setup has 43 files. This is a significant difference and could be causing the issue. Try copying the contents of the /boot directory from the working setup to your modified setup to see if it resolves the problem.

To further troubleshoot the issue, you can try the following:

1. Compare the boot logs: Compare the boot logs from the working setup and your modified setup to identify any differences. This can help you pinpoint where the issue is occurring.
2. Use a serial console: Use a serial console to capture the boot log and debug output from your modified setup. This can provide more detailed information about the issue.
3. Try a different boot mode: Try booting your modified setup in a different mode (e.g., recovery mode) to see if it resolves the issue.

In terms of finding out where the problem is, you can try the following:

1. Check the kernel logs: Check the kernel logs to see if there are any error messages or warnings that could indicate where the issue is occurring.
2. Use a debugger: Use a debugger (e.g., gdb) to step through the boot process and identify where the issue is occurring.
3. Compare the device tree: Compare the device tree between the working setup and your modified setup to identify any differences. This can help you pinpoint where the issue is occurring.

I hope this helps you troubleshoot the issue and get your custom Jetson AGX Orin NX-based board up and running!

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[tdl2]

Can a moderator remove this AI slop please? It misunderstood the problem and adds no useful information. It just clutters the thread. Thanks!

[nagesh_accord]

@tdl2

However, there are no instructions/documentation on all the modifications that were done to this to get it to work. And I am very new to this process.

Jetson Module Adaptation and Bring-Up — NVIDIA Jetson Linux Developer Guide

[tdl2]

Thank you. That is super useful. I did not come across that one before. I am going through it now.

Also given the log diff, is it possible for you to point me in the right direction to find the problem (which part of the kernel/uefi is setup wrong)?

[nagesh_accord]

@tdl2

Also given the log diff, is it possible for you to point me in the right direction to find the problem (which part of the kernel/uefi is setup wrong)?

I did not look at the diff. However, I can give some hints:

1. You say:
   Orin NX nano based custom board and modified kernel (slightly modified pinmux, no EEPROM)

but your custom carrier board might not have EEPROM, so you need to set EEPROM size to 0 in the dts/dtsi file before the build and flashing. Refer to this link :

Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi - Jetson AGX Orin...

@tdl2

Custom UEFI (cloned with edk2_docker edkrepo clone nvidia-uefi NVIDIA-Platforms r36.4.3 and modified. Disabled shell and some minor stuff)

This might causing the issue. Try to flash with normal unchanged stuff. Directly download the package from the website and do only EEPROM size modification , bulid, reflash and see, if it boots fine.

[WayneWWW]

There is Debug version of UEFI binary when you built out the UEFI source code.

Flash that one into the board and it will tell you what got stuck in the UEFI.

[tdl2]

I rebuilt a fresh UEFI debug image and looks like the problem is not that. Same image works in both workspaces. The boot only halts in my new L4T build. Here’s the diff of the debug boot log after flashing. (left is good log, right is bad).

Booting Linux on physical CPU 0x0000000000 and stuff after that only happens in the good version. But I cannot see anything else different in the two logs before that, even with the DEBUG uefi build. I assume the addresses difference in Loading driver at 0xXXX lines in the image are insignificant?

P.S: There are these errors (before the lines in the image). I am ignoring them since they are in both logs in the same lines.

TegraControllerEnableDxe:DeviceDiscoveryStart, failed to enable clocks Device Error
...
IpmiOemGetBiosPassword: IPMI_OEM_GET_BIOS_PASSWORD error: Unsupported
...
DeviceTreeGetInterrupts: Error determining interrupt controller (possible incorrect DeviceTree). Using legacy #interrupt-cells of 3
...
ERROR: Failed to find AcpiTable protocol. Status = Not Found
ERROR: ACPI Table processing failure. Status = Not Found
ERROR: Failed to get SMBIOS Table List. Status = Not Found
ERROR: SMBIOS Table processing failure. Status = Not Found

[tdl2]

Thank you for the response. cvb_eeprom_read_size is already set to 0 in tegra234-mb2-bct-misc-p3767-0000.dts. Also the custom UEFI seems to be working fine when I use it with the working L4T. So it looks like a problem in my kernel customization. I will update the question.

[tdl2]

It was working fine. I simply misunderstood how logging here works.

TL;DR

Apparently removing console=ttyTCU0,115200 as explained here stops logging after the kernel starts to bootup.

UEFI still logs into the debug serial. My WiFi driver configuration was wrong so the board couldn’t connect to WiFi. So I simply assumed it hangs after UEFI.