The one from the document with the correct quotes. Currently I am seeing the same issue with the default L4T.
But please let me finish my logs and you get the flash/serial log for both yours and my command.
Hi,
OK, so the current situation is even the direct copy & paste command from document cannot flash it, hit with busyspin and it is based on clean BSP (downloaded from sdkmanager, no other modification)?
Fresh L4T: https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v3.1/release/jetson_linux_r35.3.1_aarch64.tbz2/
Rootfs: https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v3.1/release/tegra_linux_sample-root-filesystem_r35.3.1_aarch64.tbz2/
The only difference between what you asked me to do and what I did is that I used the “–no-flash” and the “–flash-only” commands. I had to use that because my board is not instantly ready after creating the flash package due to the use of USB-IP. Maybe the issue is related to that?
Command 1 from the dev guide (Busy spin):
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --network usb0 jetson-orin-nano-devkit internal
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only
No-Flash Log:
fail_noflash.txt (219.7 KB)
Flash-Only Log:
fail_flash.txt (58.5 KB)
Flash Serial Log:
fail_flashserial.txt (87.4 KB)
Command 2 modified by me (working)
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml --network usb0 jetson-orin-nano-devkit-nvme-fixed internal
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only
With this config:
jetson-orin-nano-devkit-nvme-fixed.conf (1.6 KB)
No-Flash Log:
success_noflash.txt (244.6 KB)
Flash-Only Log:
success_flash.txt (49.4 KB)
Flash Serial Log:
successserial.txt (78.3 KB)
Hi,
I had to use that because my board is not instantly ready after creating the flash package due to the use of USB-IP
Is this related to the use of WSL2? This is NV devkit so shall not have this issue.
What would happen if you don’t split things to 2 step? Do you keep the log for this case?
WSL does not have a native USB support. So the device has to be connected to the Linux with USB-IP.
That has no effect on how the device works after it is connected. A difference is that it takes longer to connect the device after it resets.
That has no effect on the flash process as it connects successfully. Please check the logs.
If I do not split it up it just tells me that there is no device to flash. Do you want the logs too?
Sure. Please attach the log for record too. We may enhance that case in future.
For the current issue, could you help share the content of your tegra234-mb1-bct-misc-p3767-0000.dts in the BSP directory?
Does the content get modified? Should I copy it after the failed command?
No, no need to copy it after flash. Just the original one.
From bootloader:
tegra234-mb1-bct-misc-p3767-0000.dts (2.1 KB)
From temp_initrdflash\bootloader0
tegra234-mb1-bct-misc-p3767-0000.dts (2.1 KB)
From bootloader/t186ref/BCT
tegra234-mb1-bct-misc-p3767-0000.dts (2.1 KB)
Could you also share this ? It seems still missing info
- The “cat /etc/nv_boot_control.conf” result of your module
I can’t do that as it does not boot.
Do you want it with my successful flashed command?
Yes, with the successful boot case. And we will no need any further logs from your side after this for now.
BTW, I am not sure. But the key difference seems to be you cannot directly run the flash command from document because the USB IP issue didn’t happen on my side.
I will use your 2 steps commands to see if I can reproduce issue.
Wait!
I ran the command again for you without the --no-flash and was lucky that it got the perfect timing and is currently running through. Will attach that log as a replacement. Then you do not have to try.
1 Like
you seem to be right. It looks like the “–no-flash” and “–flash-only” command is broken for the new orin style flash command.
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" --network usb0 jetson-orin-nano-devkit internal
Flashed successfully and boots.
Log for comparison with the “–no-flash”
flash_devguide1step.txt (298.9 KB)
Ok. I will spend some time checking what goes wrong with that 2 step flash case.
Thanks.
Another thing which did not seem important to me before.
I started my flash command with the “–showlogs” option today and it did not work:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml –-showlogs --network usb0 jetson-orin-nano-devkit-nvme-fixed internal
Instead of
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml --network usb0 jetson-orin-nano-devkit-nvme-fixed internal
When I do that the --flash-only fails too. Maybe there is some issue with parsing the parameters.
Do you have any news yet?
I’ve got a different approach to flashing NVMe, which doesn’t use SDKManager.
I’ve documented that in this post below, let me know if that works.
1 Like
Hi,
I remember even the default command is actually a 2-step flash.
Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p -c bootloader/t186ref/cfg/flash_t234_qspi.xml --showlogs usb0 jetson-orin-nano-devkit internal
Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --usb-instance 1-8 --device-instance 0 --flash-only --external-device nvme0n1p1 -c “tools/kernel_flash/flash_l4t_external.xml” jetson-orin-nano-devkit internal