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

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:



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

May I know which JetPack SW you’re using?

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

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.

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?

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.