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:
- Changed the
cvb_eeprom_read_size value to <0x0> in the Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi MB2 BCT file.
- 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!
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.
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?
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)
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?
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!
@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.