Automatically enters the UEFI Shell after power on

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

After ORIN power on, it automatically enters the UEFI Shell. It can enter the system normally after connecting a DP. Could you please help me figure out what the reason is?
However, when the same firmware is flashed on the Devkit, this problem won’t occur.
and we have another board ,where it starts normally without the DP plugged in, but when the DP is inserted, it enters the UEFI shell instead.

cgi-binmmwebwx-binwebwxgetmsgimg&MsgID=2309606101491570991&skey=@cryptc0ffbac194b6fba6ef286792ee01289948d95045&mmwebappid=wxwebfilehelper
cgi-binmmwebwx-binwebwxgetmsgimg&MsgID=2309606101491570991&skey=@cryptc0ffbac194b6fba6ef286792ee01289948d95045&mmwebappid=wxwebfilehelper1080×1920 377 KB

failed log as below
boot_failed.txt (46.8 KB)

2

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

The issue you’re experiencing with the Jetson AGX Orin automatically entering the UEFI Shell after power-on, but only when the DP (DisplayPort) is not connected, suggests a potential problem with the boot configuration or the UEFI settings. Here are some possible reasons and steps to help you troubleshoot the issue:

  1. UEFI Boot Order: The UEFI firmware might be configured to boot from the DP connection first, and if it’s not present, it falls back to the UEFI Shell. Check the UEFI settings to ensure that the boot order is set to prioritize the internal storage (eMMC or NVMe) over the DP connection.

  2. Display Output: The UEFI firmware might be waiting for a display output signal before proceeding with the boot process. Since the DP connection is not present, it might be stuck in the UEFI Shell. Try connecting a different display output (e.g., HDMI) to see if the issue persists.

  3. UEFI Configuration: The UEFI configuration might be different between the Devkit and your custom board. Compare the UEFI settings between the two boards to identify any discrepancies. You can use the UEFI Shell to explore the configuration and make changes if necessary.

  4. Firmware Version: Ensure that the firmware version is the same on both boards. If the firmware versions differ, it might cause compatibility issues.

  5. Hardware Configuration: Verify that the hardware configuration is identical between the two boards. Check the schematics and PCB layout to ensure that there are no differences in the circuitry.

  6. Bootloader Configuration: The bootloader configuration might be different between the two boards. Check the bootloader settings to ensure that they are identical.

  7. Kernel Parameters: The kernel parameters might be different between the two boards. Check the kernel command line to ensure that they are identical.

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

  1. Connect a serial console to the board and capture the boot logs to see if there are any error messages.
  2. Use the UEFI Shell to explore the configuration and make changes if necessary.
  3. Try booting the board with a different firmware version to see if the issue persists.
  4. Compare the UEFI settings between the two boards to identify any discrepancies.

The provided log file (bootfailed.txt) might contain clues about the issue. However, without access to the log file, it’s difficult to provide a more specific diagnosis.

In comparison to the Devkit, your custom board might have a different UEFI configuration, firmware version, or hardware configuration that’s causing the issue. By comparing the settings and configurations between the two boards, you should be able to identify the root cause of the problem.

Here are some relevant commands and settings that might help you troubleshoot the issue:

  • sudo ./flash.sh jetson-agx-orin-devkit internal (flash the entire device)
  • sudo ./tools/kernel_flash/l4t_initrd_flash.sh -u <pkc_keyfile> [-v <sbk_keyfile>] --uefi-keys uefi_keys/uefi_keys.conf jetson-agx-orin-devkit internal (flash the device with UEFI keys)
  • sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -u <pkc_keyfile> [-v <sbk_keyfile>] --uefi-keys uefi_keys/uefi_keys.conf -p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-agx-orin-devkit external (flash the device with NVMe storage)

These commands and settings might help you identify the root cause of the issue and resolve the problem.

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