Jetpack 5.0.2 Bootloader

Hello,

I have asked this question in another post that may be more confusing than is necessary, so I will try to be more clear and simpler.

I upgraded an Xavier AGX 32G module from Jetpack 4.x to Jetpack 5.0.2 and am now having boot failures.
The failures appears to come from one of the boot loaders , MB1 or maybe MB2 (TBoot), being interrupted by some raw serial traffic that is on the 2 UARTs my Connect Tech Rogue carrier card has. I do have serial devices, GPS, IMU etc, on the UARTs and they had no issues for over a year under Jetpack 4.x that I believe runs CBoot.

I have read over the NVIDIA documentation and find the Boot loader section well written, but I am not able to find out if there any monitoring of the UARTs that can cause the boot process to halt. For example, in the older TX2 usage of UBoot, if a serial device was powered on during boot then there was a strong chance the UBoot would be halted by the raw traffic assuming that the user requested to halt the boot. CBoot did not appear to have that issue, while it looks like MB1/2/TBoot may.

Can someone possibly advise me on the follow

  • Does MB1 check any UART during boot for console input? If so can I disable this feature/checking through a configuration file?
  • Does MB2/TBoot check any UART during boot for console input? If so can I disable this feature/checking through a configuration file?
  • I have read comments on forums and also in the documentation about a combined UART, but I have not found any explanation on what exactly this combined UART actually means. Is there more detail on this beyond the configuration file to enable/disable it?
  • I have seen some other posts on this subject but they seem older, maybe from the Jetpack 4.x days. Has anyone else observed issues in Jetpack 5.x?
  • Sometimes the raw serial traffic causes the AGX to enter setup menus I have never seen before, for example language setup etc. So it seems clear that somehow this traffic from devices on the UARTs are causing a part of the boot loading to take actions.
  • If I power cycle enough times I can usually get it to boot, maybe one inf 50 times success.
  • If I remove the serial devices from the UARTs, power cycle the AGX, it boots with no issues. I can then reconnect the serial devices and everything operates as it should. Clearly that is not an operation solution, but I mention it as a data point that indeed the system and devices are all functional as expected.

Hi bruce4243,

For Jetpack 5.x, we use UEFI as bootloader.
Jetson AGX Orin Boot Flow — UEFI

Do you use your peripheral serial device on UART3_DEBUG ?

You could refer the following link for detailed information about combined UART.
Tegra Combined UART and the tcu_muxer Utility (nvidia.com)

Hello,

Thank you for your reply.

For the first point

If I understand correctly, the Xavier AGX boots as follows

  • Room Boot →
  • MB1 →
  • MB2 (TBoot) →
    Then finally once the hardware is set up UEFI

My failures are before, at least appear to be, the UEFI load even occurs. I have logs that I attached to my first post. I will link that post here for clarity. Can you please review those logs? I think you will see that the issue occurs before UEFI occurs, it seems to occur at the MB1 to MB2 hand off.

Boot loader interrupted with log attached

The link you supplied is the document I have been working with; however, I am referencing the Xavier AGX not the Orin sections as I use the Xavier AGX.

For the second point

I do not think I am using the UART3_DEBUG; how would I know that? If it is the micro USB connector on the Connect Tech Rogue carrier then no, I only use it for debugging this issue. You can see in the first post I made, I am using the serial ports that map to

/dev/ttyTHS0
/dev/ttyTHS1

I think those are the high speed UARTs and not the debug, but please correct me if I am not correct.

Note that the devices I am using have been connected to the same physical serial ports for over a year with no issues. The only thing that has changed is the I upgraded from Jetpack 4.6 to 5.0.2. If you review the logs I attached in the other post I think you will see exactly where the boot loader is interrupted. Hopefully that will allow you to better understand where things are going wrong and how to correct them.

thank you for your assistance

I’ve checked your log and replied you on another post.

Your boot up process has entered into UEFI.
You could see the following log indicating the start of UEFI.

Jetson UEFI firmware (version 1.0-d7fb19b built on 2022-08-10T20:18:13-07:00)

Hello KevinFFF,

Thank you for the reply. I will be back in the office in a couple days and will try to get into the Boot Manager. I will reply once I am able to get in front of the hardware.

thank you for your assistance

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