Jetson Orin Nano, flashing bootloader on custom carrier board

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
1

Hi,

I am in the process of bringing up the software on a Jetson Orin Nano 8GB (with SD card) mounted on a custom carrier board.

I have been able to program the board OK (JetPack 6) with the Jetson mounted in the DevKit, but when I boot it in the custom carrier board, the boot log in the serial port gets to the pinmux section then endlessly reboots.

I have edited the pinmux using the Excel spreadsheet to match the new carrier board, and created a new my_board.conf to point to the new .dtsi files.

I’m running the command:
$ ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmblk0p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 my_board internal

flash_log.txt (5.0 KB)

It gets to the point where it appears to be flashing the bootloader, but this fails because the jetson crashes when it is trying to write blob.bin to the bootloader.

debug_port_log.txt (7.0 KB)

What I would like to know is where is the bootloader data stored? Is this a QSPI in the Jetson module? I see that the binary blob it is trying to write is 78MB in size.

I did some experiments with the python scripts to find out which command was causing the board to crash, and it appears to be due to the option “–pollbl” in the tegrarcm command, where it is sending the binaries to the BL. If I comment that option out, the command runs without crashing the board, but I don’t think it has actually done anything with the received data.

Any help appreciated!

-Jon

3

Hi,

Most of the time, the board can still be flashed normally regardless of pinmux changes.
Are you able to flash it with the default pinmux file in our BSP?

4

I have fixed my problem, slightly embarrassing though… our custom carrier board has wired one of the GPIO’s to the reset line of the Jetson, so funnily enough, when the pinmux was initialised, it was immediately resetting the CPU. Doh!

So it was fixed by changing the state of GPIO14 to be Open-Drain/Drive 1 in the pinmux spreadsheet.

1 Like
5

Hi

Just wanted to know what device tree changes you did
,if at all to to configure flashing usb2.0 port 0 to make the flashing successful.

As we need to configure jetson device in OTG mode during second half of the flashing process using tje initrd.sh command

Please share the changes if possible. Thanks

6

Sorry, no DT changes were required, the USB came up when the board is in recovery mode and we can flash the device without making any other changes.

8

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