Jectpack5.1.3 UEFI cannot find the kernel and cannot start normally

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
,
1

Hello everyone, I am using jectpack5.1.3 to burn the system for my customized carrier board. After burning, UEFI cannot start the system. The serial port log shows:

Jetson UEFI firmware (version 5.0-35550185 built on 2024-02-20T04:21:22+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
** WARNING: Test Key is used. **
......L4TLauncher: Unable to locate L4T Support protocol: Not Found
L4TLauncher: Using legacy interface. Support would be deprecated soon!!!
L4TLauncher: Failed to get PlatformResourceInfo

Error: Could not detect network connection.

Error: Could not detect network connection.

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table 
FS2: Alias(s):HD2b:;BLK1: 
VenHw(1E5A432C-0466-4D31-B009-D4D9239271D3)/MemoryMapped(0xB,0x1416000
0,0x1417FFFF)/PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/NVMe(0x1,10-1F-00-10-04-27-
5A-3A)/HD(1,GPT,69ABBF94-2843-4738-8FA7-77F6877F8841,0x28EE28,0xA000000) 
FS3: Alias(s):HD2k:;BLK2:

I initially suspected that the hard disk partition or image was not burned into the SSD at all. Later, I burned a system of jectpack6.2.1 to the same device (it can be started normally). At this time, the module should have UEFI of jectpack6.2.1. Then I plugged the hard disk with jectpack5.1.3 burned in it. The serial port log showed that uefi found the kernel, but the boot failed because the header verification failed (this should be normal because they are two different versions of jectpack). Does this mean that there is a problem with the Uefi firmware of my jectpack5.1.3? Or are there other possible reasons why jectpack5.1.3 cannot be started?

2

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

To address the issue you’re experiencing with JetPack 5.1.3 (JP 5.1.3) and the Jetson Orin Nano, let’s break down the key points and analyze the situation step by step.

  1. Initial Issue with JP 5.1.3: You’re unable to boot the system after burning it onto your customized carrier board using JP 5.1.3. The UEFI cannot start the system, and the serial port log indicates issues that initially suggested problems with the hard disk partition or image not being properly burned into the SSD.

  2. Success with JP 6.2.1: After burning a system with JP 6.2.1 onto the same device, it boots normally. This implies that the hardware (including the SSD and the customized carrier board) is capable of functioning correctly with a different version of JetPack.

  3. UEFI and Bootloader Compatibility: When you then use the hard disk with JP 5.1.3 burned into it, but with the module having UEFI from JP 6.2.1, the serial port log shows that UEFI finds the kernel but boot fails due to header verification failure. This is expected because JP 5.1.3 and JP 6.2.1 are different versions, and there’s likely a mismatch in the bootloader and kernel versions.

  4. Analysis of the Issue:

    • UEFI Firmware: The fact that JP 6.2.1 works but JP 5.1.3 does not, suggests there might be an issue with the UEFI firmware in JP 5.1.3 or how it interacts with your customized carrier board. However, the successful boot with JP 6.2.1 indicates that the UEFI firmware itself is not inherently faulty; rather, there might be a version-specific compatibility issue.
    • Version Compatibility: The failure to boot with JP 5.1.3 after successfully booting with JP 6.2.1 on the same hardware points towards a compatibility issue between the UEFI version in JP 5.1.3 and either the kernel, the SSD, or the customized carrier board.
    • Bootloader and Kernel Mismatch: The error message indicating a header verification failure when trying to boot JP 5.1.3 with JP 6.2.1 UEFI suggests a mismatch between the bootloader (UEFI) and the kernel. This is a common issue when mixing components from different JetPack versions.

  5. Possible Solutions and Next Steps:

    • Update UEFI: If possible, update the UEFI to a version compatible with JP 5.1.3. However, given that JP 6.2.1 works, this might not be straightforward or necessary.
    • Check Custom Carrier Board Compatibility: Ensure that your customized carrier board is fully compatible with JP 5.1.3. This includes checking the device tree, kernel configuration, and any specific hardware requirements.
    • Reflash with Correct Version: Reflash the device with JP 5.1.3, ensuring that all components (UEFI, kernel, device tree) are from the same JetPack version to avoid compatibility issues.
    • Consult NVIDIA Documentation and Forums: Look for specific guidance from NVIDIA on using JP 5.1.3 with customized carrier boards and troubleshooting boot issues.

In conclusion, while there could be an issue with the UEFI firmware of JP 5.1.3, it’s more likely a compatibility problem between different components (UEFI, kernel, device tree) of the JetPack versions. Ensuring all components are from the same version and checking the compatibility of the customized carrier board with JP 5.1.3 are crucial steps in resolving the boot issue.

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

3

So do I need to recompile the UEFI firmware of injectpack5.1.3?

4

After replacing uefi, I can no longer burn successfully. Is there any other operation required?

6

Hi shuisheng.peng,

It seems you hit the boot issue caused from L4TLauncher since it does not be updated correctly.

Please refer to Jetpack6.2 to jetpack5.1.5 - #12 by DavidDDD and try adding --erase-all option in flash command to check if it could help for your case.

7

I added this command when burning the generated mfi package, but it didn’t take effect. Do I need to execute this command in the Linux_for_Tegra source directory?

8

All flash related commands should be run under <Linux_for_Tegra>/ directory.