Little update from my side. I was surprised that the guide now uses this command addition instead of relying on the EMMC_CFG in the conf file of the board:
Hi @WayneWWW
We received our Jetson Orin Nano Devkit yesterday. So I went ahead and wanted to flash it.
Inititally I was trying the flash command from here:
That command is the same as in the developer guide.
I initially used it wrong because I omitted the “–network usb0” part. It was working like that on Xavier NX, so I read “–network eth0” and assumed I won’t need it.
Obviously the way of flashing was changed between Xavier and Orin. Inititally you used to have an RNDIS gadget on the device which mounted it’s NVMe partition on the host so the host could write to the device.
The new method seems to use an NFS server on the host exporting parts of the L4T directory so that the device can access it directly and use the data to flash itself. I am not sure if I am happy about the NFS share yet, but that’s another topic.
After fixing the command so that it looks exactly the same as in the dev guide I managed to flash the board but it is not able to boot.
I moved the
part into a .conf file as the EMMC_CFG and the otherwise exactly same command flashes correctly and the system is able to boot.
I was using custom .conf files to represent all the possible combinations between devkits/modules and our custom board. Due to the change in the flash commands that has become a bit cumbersome as I do not only have to change the .conf file but also adapt the flash command to the selected board in my flash script…I would’t really need the conf files if I need to parse what I flash anyway.
A suggestion from my side:
The “-c [NAME].xml” was added to the flash commands for NVMe flashing.
How about adding an “EXTERNAL_CFG” variable to the conf files for parsing by initrd_flash.sh so that the user can write the parameters for NVMe flashing in there? You need to switch the EMMC_CFG from qspi_sd or qspi_emmc to qspi anyway, so a new config file is required for NVMe flashing.
Use these configs in your command:
A/B Support: tools/kernel_flash/flash_l4t_nvme_rootfs_ab.xml
Single Filesystem: tools/kernel_flash/flash_l4t_nvme.xml
I need to unplug the board and reconnect it between the first and the second command because it becomes unreachable to the flash script after the first command.
Still waiting for @WayneWWW or @DaveYYY answer why the command in the developer guide does not work.
that’s from the tools/kernel_flash/README_initrd_flash.txt
Anyway, the two step process is not what makes it fail. It does not work with one or two steps.
The --no-flash command is used so that you can create the flash files without having the actual board attached. The --flash-only can then reuse that data multiple times without always recreating the data.
As you can see in the very first comment I also tried it without the “flash” options
Honestly, I have to say that you always put your story too long and actually I don’t have time to read your whole story. Sorry that none of us is native Englisher speaker.
Could you just share it as a item list
What is your current error/issue?
What is the diff between your setup and default config from BSP?
To Flash the Jetson Developer Kit Operating Software
Point 6, first Command
→ does not work
The flash succeeds but the bootloader is not working
[0000.444] E> BL_CARVEOUT: Failed to allocate memory of size 0x8000000 for CO:31.
[0000.452] C> Task 0x0 failed (err: 0x49490003)
[0000.456] E> Top caller module: BL_CARVEOUT, error module: BL_CARVEOUT, reason: 0x03, aux_info: 0x00
[0000.465] C> Boot Info Table status dump :
1
[0000.469] I> Busy Spin
Jetson Orin Nano devkit with Jetson Orin devkit edition module and NMVe
Rootfs and kernel is customized. But the bootloader or uefi has not been touched. I’d say standard setup.
The old commands we know from xavier series still work.
Yeah, that’s how it seems to me. I’ve only read about people in the forum using the same command, but they already fail with a timeout.
Maybe I am doing something wrong, missing a character or so. But for me this command does not work.
I have not done, and I will not do the test with unmodified rootfs. I’ve done that numerous times to 90% find out that the issue was not on my side. The chance that my rootfs has an influence on MB1 should be zero.
I’ve found an undocumented working command now. If you want, ignore my posts.
But maybe you want to see if it actually works for others or not.
Hi @WayneWWW
Sorry , I am third person here in this topic. I too faced error.
I used same command what you you have mentioned.
But i got time out. Flash Logs attached . What would be reason. I am trying with default BSP.
========logs==========
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Timeout
Cleaning up…
hmecd001409@DSC:~/BSP/flashdir/Linux_for_Tegra