Jetson AGX Orin Industrial On Custom Carrier Boot Failure

Hello all,

I am attempting to boot the Jetson AGX Orin Industrial (p3737-0000+p3701-0008) R36.5.0 on a custom carrier board. After much struggling, which only has UART1/UARTA available, I was able to get at least some of the debug output rerouted there. I can see that the Orin never makes it to booting into Linux but I do not know why. Log is attached below:

badboot.log (19.1 KB)

Here are the changes that I have tried so far:

  • In tegra234-mb2-bct-common.dtsi:
    • Changed spe_uart_instance to 0 (and back to default 2, still unable to boot)
  • In tegra234-mb1-bct-misc-common.dtsi:
    • Changed uart_instance under “debug data” to 0 from default 2
      • This is what was able to give the logs attached to this post
  • Followed instructions regarding setting eeprom size to 0 * here
  • Removed all ethernet device tree nodes that use the nvidia,tegra234-mgbe driver (such as ethernet@6800000 in tegra234.dtsi
  • Set ODMDATA=”gbe-uphy-config-0,hsstp-lane-map-3,hsio-uphy-config-0,nvhs-uphy-config-0” in p3701.conf.common
    • Our device plans to use the MAC-to-MAC ethernet connection over the nvidia,nveqos device at ethernet@2310000 but does NOT plan to use mgbe
    • It is worth mentioning that just about every UPHY device is unused on our custom carrier board. I suspect that we have misconfigured something here but I don’t know what

After flashing, and resetting the device, the device boots until arriving at the last line seen in badboot.log attached above, reboots once, and then freezes until being manually reset.

My question is twofold: First, I’m sure we’re misconfiguring something here, but how can we see what is causing the machine to crash? Second, how can the UPHY configuration be validated?

Relevant schematic excerpt:

Hi scarrion,

I don’t find any significant error in the serial log you shared.
Could you also share the flash log for further check?

Please refer to UPHY Lane Configuration — NVIDIA Jetson Linux Developer Guide for details.

Hi @KevinFFF ,

Firstly, I have done some extensive research trying to get this working, and your other posts on this forum have been extremely helpful, so thank you for your contributions here as it has helped me get to this point.

I have attached the flashlog below as requested:

flashlog.log (207.4 KB)

There are no significant errors that I see in this log either.

Based on the boot log above (badboot.log), it seems as though the MB2 firmware on the device hangs, but there are no logs that indicate what MB2 is trying to do before it hangs, so I don’t have any way to further debug the problem in my device/firmware configuration.

I saw the UPHY lane configuration docs you linked, thank you. I have already set ODMDATA based on the information in this document which I think is correct but I’m not certain. The reason I mentioned UPHY is that I suspect this may be the problem, but without any information from the MB2 firmware, I cannot debug further.

Can you recommend a method to get some more debug info about MB2 so I can diagnose the problem in my configuration?

Thank you!

Yes, It seems a successful flash log.

I checked the logs on a working AGX Orin devkit.
SPE and PSC boot logs should be visible immediately following the hang point you’re seeing.

I> Unhalting SPE..
I> Enabling combined UART 
����spe: early_init
����vic initialized
�丸��tsc initialized
����aon lic initialized
�ุ��spe: tag is 5243985d1b1eb3f06fac6d36bd7e74ac
����spe: SafeRTOS v8.4
�ุ��spe: init
����scheduler initialized
�ุ��aon hsp initialized
����tag initialized
�ุ��tcu initialized
����bpmp ipc initialized
�ุ��spe: late init
����cpu_nic clock initialized
�ุ��apb clock initialized
����pm initialized
�ุ��bpmp hsp initialized
����top1 hsp initialized
�ุ��ccplex ipc initialized
����spe: start scheduler
�ุ��
    I> Task: Trigger mailbox for PSC-BL1 exit
I> Sending opcode 0x4d420802 to psc
I> Received ACK from psc

May I know the reason why you configure about this?

Could you revert all custom changes in both MB1-BCT and MB2-BCT to check if there’s still the boot issue?

@KevinFFF ,

The reason that I configured spe_uart_instance to 0(for UART1/UARTA) instead of the default of 2 (for UART3/UARTC) is that the custom carrier board that this Jetson AGX Orin Industrial is running on only breaks out the UARTA pins from the CVM connector. So, we can’t access UARTC without a carrier board revision.

Is using UARTA instead of UARTC supported as I’m doing it here? I see a note on the documentation here that claims that the option uart_instance is only supported for simulation platforms. However, this option is related to the MB1 firmware, not the MB2 firmware, where the machine seems to hang.

Reverting these changes results in no output being seen over UARTA whatsoever.

@KevinFFF ,

Any update here that may give some more insight into how to debug this further?

@KevinFFF ,

Any suggestions here?

Do you mean there’s no UART3/UARTC on your custom board for serial console log output?

Based on my understanding, UART-C is the debug UART port which outputs logs from several firmwares.
It is not supported to output all serial console log to other UART interface(e.g. UART-A).
Please revert the MB1/MB2 configuration and pinout the UART-C to check there’s other boot issue.

Yes, only UARTA/UART1 is broken out on the custom carrier board. We are making another revision of our carrier board that breaks out UART3/UARTC. I suspect there is some other issue causing booting to fail. Will update or make a new thread once there is more information

Okay, please keep all logs output from UART-C and check if there’s other boot issue.