Orin custom board fails to boot using JetPack 6

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
, ,
1

Hi everyone,

We are working on bringing up an Orin custom board. Currently, we are using JetPack 6. Here are some hardware details that could help us with the debugging process:

Feature Orin Eval Kit Description Custom AGX Description Orin Eval Kit Custom AGX Orin Pins affected
Button MCU PushButton switches, much of this feeds into the DEBUG MCU FPGA handles the PB switch functionality Si Labs 8-bit MCU controlled FPGA POWER_BTN(L61), MODULE_POWER_ON(L54)
DEBUG MCU, USB Type C port controller, USB PD controller DEBUG port USB connector connects to MCU UART2, UART7, MCU_I2C, NVJTAG_SEL, NVDBG_SEL not supported, SYS_RESET_N, FORCE_RECOVERY_N handled by FPGA Microchip 32-bit MCU No DEBUG port, No USB PD support, No USB 3.0, FPGA SYS_RESET_N(L60), FORCE_RECOVERY_N(L10), MCU_I2C[I2C2](J61,K61), UART2(C56,C57), UART7(B48,B49), UART3_DEBUG(H60,H62), NVJTAG_SEL(H59), NVDBG_SEL(G60)
ID EEPROM ID EEPROM @ address 0x56 EEPROM @ address 0x50 – can be changed if necessary ID EEPROM @ 0x56 General purpose EEPROM @ 0x50 I2C1(K5,L8)
PCIe PCIe
10GBE 10GBE 10GB Ethernet 1GB Ethernet with mez board for dev only
CAMERA Connector
M.2 M.2 M.2
M.2 KEY M
CODEC (I2S1) NOT implemented
USB3.1 GEN2
HUB x4 Ports

Based on the above table, we did a couple of modifications to some source files and flash the board. The modifications are:

  1. Changed the cvb_eeprom_read_size value to <0x0> in the Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi MB2 BCT file.
  2. Changed the ODMDATA before flashing. We followed the Jetson AGX Orin Platform Adaptation and Bring-Up — Jetson Linux
    Developer Guide 34.1 documentation     instructions, so we did:
— p3701.conf.common
+++ p3701.conf.common

-ODMDATA=“gbe-uphy-config-22,hsstp-lane-map-3,nvhs-uphy-config-0,hsio-uphy-config-0,gbe0-enable-10g”;
+ODMDATA=“gbe-uphy-config-0,hsstp-lane-map-3,nvhs-uphy-config-0,hsio-uphy-config-0”;

In our testing process, we flash the SOM from the dev kit. We see the NVIDIA logo and get to a desktop every time. And then we transfer the Orin to the custom board.

However, the custom board is not booting up with success so we had to update the debug UEFI binary using the the r36.3.0 combo to get more logs. Here is the log file:

Custom_boot_UEFI_DEBUG_2024-08-05.log (138.4 KB)

We did see the

DeviceDiscoveryStart, failed to reset moduleDevice Error

Nevertheless, we did a comparison when Orin booted from the devkit with success and we did see the same message. Here is the log from the devkit:

OrinDevKit_JP6.0_UEFI_DEBUG2.log (137.4 KB)

Thank you in advance!

3

Hi EduardoSalazar96,

[0000.086] I> rst_source: 0x0, rst_level: 0x0

From the log you shared, it seems the reset is not caused from SW.
Please check where the reset comes on your custom carrier board.

4

Hi @KevinFFF

Thanks for your reply

I have some questions:

  1. What reset are you referring to?
  2. The same message appears in the devkit in a good booting process. What does this error tell you? And why does the same message defer from the devkit?

Thank you!

5

Why are you using this method to flash? Your board cannot get flashed?

What is the log before enabling UEFI log? Does it just get stuck in UEFI?

6

Hi @WayneWWW

Yes, right now the custom board can’t get flashed. We are addressing this right now in order to try to flash using the custom board

This is the log before enabling UEFI log. It gets stuck and that is the reason why we enabled the UEFI log
custom_board_boot_2024-07-24_0.log (73.7 KB)

7

It seems the HW reset rather than caused from SW.
You can remove the power cable and plug it back and you would get the same reset source.

It is the debug message rather than the error message.
Please check if there’s any possible reset may be caused from your custom design.

Or your reset issue could also be reproduced on the devkit?

8

Hi @KevinFFF

We found that the issue was related to the power supply. No, the Orin custom board can boot using JetPack 6. Thank you for the support provided!

On the other hand, we are currently trying to solve the flash issue since the custom board can’t get flashed. We are dealing with the USB configuration at the hardware level. The USB in the carrier board is setup as a Type A (host) and we think we need to change the USB type to device mode. However, from our research, we found in the following post Recovery mode using USB 3.2 for AGX Orin - #9 by WayneWWW that

Only USB0 port could be “recovery mode” port. But every usb port on the board could be used in device mode.

Recovery mode port is not fully equal to device mode port.

So we have some doubts about how the USB port should be managed. We would like to know if there are any complications with making it a peripheral device when hooked up to an external host (PC). You can check the hardware design for the USB 3 type A in the following PDF file:

USB3_0_A.pdf (27.5 KB)

Thank you in advance!

9

@EduardoSalazar96

Some clarification here.

A usb type A port by its nature could not be in device mode directly.

The reason a usb type A on USB0 could be a flash port is because recovery mode is triggered by hardware pin.

Once your board finishes the flash and enters kernel, it is back to standard usb driver behavior and usb type A cannot work as device mode directly.
Such case will affect initrd flash tool and it means if you want to directly flash nvme drive on your board, it will have problem.
Of course there are still method to “force” the port to always be device mode, but that does not follow the standard driver thus we don’t suggest that.

You need to clarify what do you want to do here exactly so that we can tell if it is okay. Reviewing a type A port schematic does not provide much help here.

You can also file a new topic as this one seems not related to original issue anymore.

12

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