AGX ORIN boot error

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

L4T Version: 35.6.0
After our equipment has been deployed, and under normal usage conditions. Unable to start the system entry.
boot_error.txt (32.5 KB)

After re-flashing, the module was able to enter the system normally. However, fearing that the same situation might occur again in the future, I would like to know what could be the cause of this?

2

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

The issue you’re experiencing with the Jetson AGX Orin, where the system fails to boot and displays an error message, is concerning, especially since it occurred after the equipment had been deployed and was under normal usage conditions. The fact that reflashing the module allowed the system to boot normally again suggests a potential issue with the software or firmware. Let’s break down the possible causes and compare them to similar issues mentioned in the context:

  1. Software or Firmware Issues: The context mentions several software and firmware-related issues, such as “Call trace observed in during boot in preempt-rt kernel” and “Boot failed Jetson Xavier NX boot.” These issues could be related to the kernel, device tree, or other software components. Given that reflashing the module resolved the issue, it’s possible that a software or firmware glitch caused the problem.

  2. Hardware Issues: Although less likely, given that reflashing resolved the issue, hardware problems cannot be entirely ruled out. The context mentions “Rin Nano 8GB Developer Kit - Realtek PHY MAC Address Change Causes Boot Issue,” which indicates that hardware changes can affect booting. However, in your case, since reflashing helped, a hardware issue seems less probable.

  3. Power or Environmental Factors: The context does not directly mention power or environmental factors causing boot issues. However, these can be common causes of intermittent problems. If the system is exposed to power fluctuations, extreme temperatures, or other environmental stresses, it could potentially cause boot failures.

  4. Corruption of Boot Partition or Files: The error message “booterrortxt 325 KB” suggests there might have been an issue with the boot partition or critical boot files. Corruption in these areas can prevent the system from booting. Reflashing the module would replace these files, explaining why the system was able to boot afterward.

  5. Incompatibility or Configuration Issues: The context mentions several topics related to compatibility and configuration, such as “Multiple carrier boards with Orin NX and JetPack 6.2” and “Support for Jetson AGX Orin Developer Kit 32GB: not boot OS and can’t connect to NVIDIA SDK Manager.” These issues highlight the importance of compatibility and correct configuration. Although your issue seems resolved by reflashing, ensuring that all hardware and software components are compatible and correctly configured is crucial.

To prevent such situations in the future, consider the following steps:

  • Regular Updates and Maintenance: Keep the system updated with the latest software and firmware releases. NVIDIA often releases updates that fix known issues, which could prevent future boot problems.
  • Monitoring System Health: Regularly monitor the system’s health, looking for signs of hardware or software issues before they become critical.
  • Backup and Recovery Plans: Have a robust backup and recovery plan in place. This includes not just data but also system images, so you can quickly restore the system to a known good state if issues arise.
  • Environmental and Power Considerations: Ensure the system is operated within recommended environmental and power specifications to minimize the risk of damage or malfunction.

In conclusion, while the exact cause of your issue might be difficult to pinpoint without more specific details, it’s clear that software or firmware issues are the most likely culprits, given the resolution through reflashing. Maintaining the system, ensuring compatibility, and having robust backup and recovery plans are key to preventing and mitigating such issues in the future.

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

4

Hi chen.xi,

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

ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(978): ((BOOLEAN)(0==1))

It seems you hit the known assertion 3 issue in Assertion issue in UEFI during boot - Jetson & Embedded Systems / Jetson AGX Orin - NVIDIA Developer Forums.

For r35.6.0, you have to apply the change and update the tos image manually.

5

It was using a custom carrier board. The system of this board did not undergo any modifications to UEFI. Only the interface BSP was adapted. Since this was a regular shipment product and we encountered this problem for the first time, if we could only reconfigure UEFI, we would consider upgrading the L4T version.

6

Please note that the fix is included in tos image (A/B_secure-os partition) rather than UEFI binary(A/B_cpu-bootader partition).
You can update them either using capsule update for bootloader or image-based OTA to the latest r36.4.3/r36.4.4 release.

7

OK, I’ll take a close look at it. If there are any issues, I’ll continue to post.

8

thanks

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.