debugging a board, I found that when flashing to mmcblk0p1 the image file (rootfs/boot/Image) is being populating during the flash.sh.
but when flashing to nvme0n1 it doesn’t. it seems wrong.
I am talking about jetpack 5.0.1. and as edited there:
7. (update: 2022/2/14) SDKM is able to directly flash to NVMe on jetson after jetpack4.6
This is because the initrd flash tool in this link is implemented and it can directly flash the NVMe drive on jetson of TX2-series/Xavier series
I don’t understand how initrd related. not sure what it is.
can you explain if on 5.0.1 there is the option to do this: $ sudo ./flash.sh --no-flash jetson-xavier-nx-devkit-emmc nvme0n1 ?
and, which of the notes on the ’ Boot from external drive’ is still relevant? how it should be updated for 5.0.1?
does flashing to nvme0n1 should not ‘populate’ to rootfs? because that the problem I see there is no new image file there when doing that
This is mentioned in the rel-32.x document and it is still same in rel-34.x.
No matter which version you use, “flash.sh” won’t flash anything to your nvme drive. I mean if you plug an empty nvme drive to jetson, run flash.sh with nvme0n1. You will still get an empty nvme drive in the end.
My real issue is about flashing custom kernel (self build from sources, but with little changes) to custom board. so its more complicated than what described in this post. I tried to simplify the post.
The first thing that I see that seems like abnormal is the missing ‘populate’. The question is: is it ok that its not populating.
regarding running from the nvme:
I did succeed to run flash.sh to nvme0n1. and did notice that if the boot order is not from the nvme, the board doesn’t boot.
But then I noticed problems in the device tree, from there I noticed that the Image has not been updated, maybe not populated.
so I am not sure why you say its not possible.
(note that I did run the sdk manager on the same board at some point, and selected nvme)
The first thing that I see that seems like abnormal is the missing ‘populate’. The question is: is it ok that its not populating.
Yes, it totally makes sense because you are not really flashing nvme. “flash.sh with nvme0n1” is only doing one thing. Adding “root=/dev/nvme0n1” to the kernel cmdline. And that will only tell kernel to mount your file system from nvme0n1. It does not install anything to your nvme0n1. So if your nvme0n1 is empty, then it won’t boot.
Please be aware that the “kernel” is still from the emmc at this moment.
It makes sense that it does not populate rootfs. Why does it need to take few mins to populate something it won’t use?
I did succeed to run flash.sh to nvme0n1. and did notice that if the boot order is not from the nvme, the board doesn’t boot.
Yes, no one said “flash.sh” will fail. The boot order is also not related to what you are doing here. The only thing “flash.sh + nvme0n1” is tell kernel to mount /dev/nvme0n1. I just said it.
(note that I did run the sdk manager on the same board at some point, and selected nvme)
sdkmanager is not using flash.sh to flash nvme when nvme is selected in the GUI.
ok, Thanks.
for me, it seems like the problem is that the script called ‘flash’, the argument is nvme0n1, but its not really flashing to the nvme.
either removing the option, make it clearer that in the manual, or notify that in the script itself can be really helpful
