Different charge numbered jetson orin nano's behave differently when writing to QSPI on custom carrier boards

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
,
1

I found regular errors in a batch of jetson module flash jetpacks for customized carrier boards, where the motherboard with charge number 0524 worked fine and the motherboard with charge number 5123 always failed,

[ 13.5680 ] Start flashing
[ 13.5682 ] tegradevflash_v2 --pt flash.xml.bin --create
[ 13.5684 ] Bootloader version 01.00.0000
[ 14.0899 ] Erasing spi: 0 … [Done]
[ 15.0971 ] Writing partition secondary_gpt with gpt_secondary_3_0.bin [ 16896 bytes ]
[ 15.0972 ] […] 100%
[ 15.1005 ] 000000004d4d2c01: E> NV3P_SERVER: Failed to initialize partition table from GPT.
[ 15.3339 ]
[ 15.3339 ]
Error: Return value 1
Failed modules are uniformly numbered as follows:

image
image1288×580 89.2 KB

image
image1288×580 97.2 KB

Is this a known discrepancy due to the production lot? Any clues would be appreciated.

2

May I know which JetPack SW you’re using?

4

Do this instead:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh -p "--no-systemimg -c bootloader/t186ref/cfg/flash_t234_qspi.xml" --network usb0 jetson-orin-nano-devkit internal

Or for JetPack 6:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh -p "--no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml" --network usb0 jetson-orin-nano-devkit internal
5

Tested in both jetpack 5.1.1/5.1.2, which incidentally uses a custom BSP, will this have any effect? Would like to confirm if it is a hardware or software issue that is causing this discrepancy.

6

Since using a custom carrier board and a non-devkit som, the command I use is:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1
-c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/t186ref/cfg/flash_t234_qspi.xml”
–showlogs --network usb0 p3509-a02+p3767-0000 internal

I guess I need to use the command you provided and replace the part about the board name in it?
Also is it possible to provide the specific information I mentioned about the differences between the two SOM versions?

7

YES.

The QSPI chip on modules produced earlier has the protecion bit turned on, which cannot be hanled correclty by MB2 bootloader.
New modules will not have this problem has the bit is by default turned off.

9

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

10

@nickkkula one question. What was the flashing command you used intially when you reported this issue to us?

We are trying to understand why you saw this issue. If you were using initrd_flash.sh which is the recommended way to flash Orin NX and Orin Nano, then you should not have seen this issue at all.