Let’s see if it can successfully achieve 100% and boot up.
I’ll let you know when the results come out.
Can you tell me what I can test if the flashing is done well?
It seems to be working as shown in the picture below.
I think that nx is working pretty well. Not so bad.
But, the flashing time was strangely long, so I want to test if it is normal. Can you tell me how to test it quantitatively?
Do you have other ubuntu host to test the flash? I want to check if different host can give out faster result.
It is really abnormal to take >50 min to flash the board. We don’t see such case locally.
There are currently no other flashing host PCs available.
When the flashing host is ready, let’s test it again.
Please test again internally.
If I do anything else on the host PC, can the flashing time be affected?
We tested this internally already.
This is the test result we have in 5/5/2020
- Xavier NX: 10m11s
And another customer told us this result:
- NX: 10m
Also, no other users here reported a > 50 min flash time… thus I can only ask you to try different host first.
If there are disk errors I could see this taking a very long time. If you monitor “
dmesg --follow” on the host PC during the flash, do you see error messages?
There are ways to momentarily attach and then detach
strace to see what system calls are churning, but that is a lot of output in a very short time. It could provide a clue, but you’d need to be very motivated.
I need to flash kernel alone in the Jetson Xavier NX. Is kernel should be updated in /boot partition of the rootfs? or Can it be flashed using the below command:
sudo ./flash.sh -k kernel jetson-xavier-nx-devkit mmcblk0p1
also make sure the output of
df -h shows the Host PC to have more than 50GB free space at the system partition
How to flash kernel alone in Jetson Xavier NX? @WayneWWW
Prior to rel-32.3.1 -> cboot does not support exlinux boot, so you have to use “sudo ./flash.sh -r -k kernel board_name mmcblk0p1”.
For release like 32.4.2/32.4.3, it supports the extlinux boot so you could just replace the kernel image with path /boot/Image on device. No need to flash.
More important thing is flash may not work because by default the bootloader loads the /boot/Image but not the partition.
Thank you! @WayneWWW
This time it took 20 minutes to flash on the xavier-nx sd card version.
Can you see this as normal?
Does anyone else in this thread also have 20 min flash time on NX sdcard module and 50min on NX emmc module?
restoring of image with dd from dd archive, also compressed?
dd typically can be used with
bs= argument to speedup recovery of raw image
e.g. raw clone restoration of emmc 32-64 gb could take up to a hour without the bs argument
Just my opinion, but writing a lot of data to an SD card is indeed slow. Between the time to generate an image, and especially the time to transfer the data to the SD card, I would consider 20 minutes as slow, “but reasonable for conditions”. You should log flash to SD and check the timestamps. You could alter the flash.sh script to provide more timestamps, especially the start and complete time of creating
system.img. Once this is created you can keep using it without spending time generating it again via the “
-r” option, but much of the time involved will be actual copy to SD.
Note: I do not see this long of a time. However, SD cards are much slower than regular hard drives for me.
The flash time on NX production module is slower than Nano production module because NX also uses qspi flash but Nano production module does not.
But what I didn’t expect is someone needs to take 50 min to finish the flash, while our internal test can finish in 10 mins.
Thus, I want to know if anyone else also has such behavior…