Looks like after the first flash, the qspi is locked for writing somehow.
Jetpack is 6.2 using Orin NX.
Our current (not nice) sollution is to flash on an un-bugged OrinNX, then transferring the nvme to a bugged (but flashed once) module.
adding console log
I should add that the crash is on the qspi erasing part.
It’s says ‘done’ on the flash log, (Erasing spi: 0 … [Done]) but it’s not. bug-flash-qspi-console.log (29.4 KB)
This should reprogram only the QSPI without flashing. If it writes partitions successfully after the [ 9.3418 ] Erasing spi: 0 … [Done] log line, then you can flash normally using the initrd flash script instead of the plain one:
B. If you still see the same issue after reprogramming the QSPI:
[ 10.3510 ] Writing partition secondary_gpt with gpt_secondary_3_0.bin [ 16896 bytes ] [ 10.3525 ] […] 100% [ 10.3562 ] 000000004d4d2c01: E> NV3P_SERVER: Failed to initialize partition table from GPT.
Reboot the board, enter in recovery mode and try directly with the same initrdflash script. If neither work, please save the UART and flashing logs and share them please.
Hello Fabian, thanks for the answer.
The first ‘flash.sh’ command (with changes) failed on the same error.
The second ‘l4t_initrd_flash.sh’ (with changes) worked up to having the Orin boot to initrd shell state, which is fine because the qspi rewriting worked fine!
That’s was the command to fit Jetpack6.2 with our setup:
./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/generic/cfg/flash_t234_qspi_nvme.xml --no-systemimg” --network usb0 --showlogs jetson-orin-nano-devkit-super-maxn-nvme external
Now the full flash procedure works fine.
Thank U very much