It simply means that you have to flash the Jetson itself with the correct release, and that creating an SD card or other boot media is insufficient by itself. There are several ways to create boot media, but you need JetPack/SDK Manager to flash the Jetson module.
Thanks, the picture is comming into focus. I like it that you used the word simply. That is what I understand.
I think you also said I can go back to Jetpack 4.6 by using recovery mode. Am I correct?
Does recovery mode revert to the QSPI which was orginally delievered on the Jetson Xavier NX Development Kit?
If so, My concern is still with the written instructions about how to replace the QSPI in the documentation. If you examine the provided instructions, I do not see how flashcp finds jetson-xavier-nx-devkit.spi.img from the Download folder or from the Jetson_Xavier_NX_QSPI_35.1.gz file unless it is hard coded in flashcp module.
Yes, recovery mode is what puts the Jetson in a mode the flash software can talk to. The mode itself does not change anything unless the flash software runs, and the primary purpose of the flash software is to update QSPI. All “revert” behavior is strictly from the flashing itself since recovery mode itself only temporarily makes some commands available rather than actually causing a change.
One does not normally specifically flash QSPI. One merely flashes, and this by default updates QSPI. On an SD card model a normal flash is essentially a QSPI update.
I do not keep up on which specific file is loaded from where, but in general the theme is that you should log a “normal” flash of your board, and the log will show you exactly what file was used from where. In some cases there are reference files, and one is picked based on the model of board being flashed (JetPack can flash many models), and perhaps placed in the working location of the “
Linux_for_Tegra/bootloader/” subdirectory or the “
Linux_for_Tegra/kernel/” subdirectory, followed by later copy to the “
rootfs/boot/” or similar location (including flash to a partition after signing). The log is the key to finding what goes where. An example:
sudo ./flash.sh jetson-xavier-nx-devkit mmcblk0p1 2>&1 | tee log_of_flash.txt
Incidentally, the actual flash target is the name of one of the “
.conf” files with the “
.conf” part of the file name removed. If you are in the “
Linux_for_Tegra/” directory you will find many such files via “
ls *.conf”. Many of these are just symbolic links (aliases) for a conf file which is named after a combination of the SoC number and carrier board number (those two combined determine the device tree and kernel). In some cases, if you are building custom hardware, you might choose to copy a conf file, rename it for your board, edit for something in those files, and then simply use that name as the flash target.
related to this topic, i just encountered an issue along the QSPI update:
the first flash_eraseall /dev/mtd0 has been done
unfortunately the machine has been interrupted/powered off before the new img is written.
Then, the NX does not boot anymore.
How to solve this issue ? Is there any recovery mode… ?
You would need to flash the Jetson again. Recovery mode does nothing more than make the Jetson able to respond to flash software, and does not change anything by itself. There is no “factory image” reset, and flash is the only way to fix such things.
I face similar issue. and I used SDK manager to flash my NX ( flash nvme0n1 directly). it works for 5.0.1, but cannot boot via nvme after flash 5.0.2. I know there a script to transfer the system to NVME. but it not so convenient (but can be acceptable).
Is there someone have tried PXE to exchange different jetpack verison? i found 5.0.2 can support PXE already.
thanks for these answers. I installed sdkmanager on another linux machine.
After a long download period, the installation process starts. However, when ready, the flash process (for both Jetson Linux image AND Jetson Xavier NX steps) fails since the host cannot connect along the USB cable using IP address with the Jetson. However, be sure that the Jetson is seen by the sdkmanager when connecting it (lsusb indeed reports the device).
Maybe this is due to the fact that /dev/mtd0 has been cleared… and nothing done since then…
How to come over this ?
i got the following lines:
→ INFO: start to check if ip and ssh with customize ip
→ DEBUG: running command < true >
INFO: command finished successfully
→ INFO exec_command: nc -z -vv -w 5 192.168.55.100 22
→ ERROR nc: connect 192.168.55.100 port 22 (tcp) timed out: operation in progress
→ Cannot connect to the device via ssh. Check user name and password… or use the Manual Setup instead
What you’ve described is actually a successful flash, but a failure of network setup after the flash completes. For clarity, consider that no networking is used during flash in recovery mode, but once flash completes, the Jetson then reboots. It is then that
ssh and optional package installs occur (using
ssh). Flash finished, only the optional content failed.
The IP address mentioned is for the virtual network device the fully booted Jetson provides over USB. If the host PC security denies using the USB virtual network, then this could only be fixed by telling the host PC to allow this (the default is to allow). Or if the first boot account setup fails, then even if networking succeeded, no
ssh login would be possible. Note that if the wired networking were used instead, and the IP address were entered in the SDKM setup, then the USB virtual ethernet would not be required (but first boot account setup would be required).
Consider that flash did complete, and that you could later run SDKM again, but tell it to skip flash and only install optional packages. You don’t have to reflash if you managed first boot account setup.
Note also that if video to the monitor fails, that often flash is still successful, and that serial console could be used instead for first account setup (which also makes debugging and fixing video issues easier).
In this case you would probably want two things to report:
- A serial console boot log from the Jetson.
- Monitor “
dmesg --follow” on the host PC, and note what is seen as you plug in a fully booted Jetson’s USB (this would offer networking clues).
Well, as suggested, the manual installation (flash modality proposed by the sdkmanager) solved the problem and flashed the jetson making it able to at least boot (but not booting linux).
Next step was to install the linux image but the jetson could not communicate via ssh so i had to copy system on the sdcard as for a clean install and everything was OK.
All good, thanks
Trying now to install 5.0.1 and update it to 5.0.2.
Thank you a lot for your suggestion! I also thinking about this possibilites.
Do you have the link about how to update from 5.0.1 to 5.0.2?
I tried to upgrade 5.0.1 to 5.0.2 and it didn’t rebooted !!!
I did this but didn’t work for me :
And this :
ok, Then I suggest to flash the SD card or eMMC first. after that follow instructions from https://github.com/dusty-nv/jetson-inference.git to transfer the system to SSD.
it works for me. Hope this would work for you too!
Will try this tonight
I have the same question as above,
where is the “jetson-xavier-nx-devkit.spi.img” file which is needed for the step sudo flashcp jetson-xavier-nx-devkit.spi.img /dev/mtd0 ?
Please help me.
Moreover, if I try to extract the QSPI file “Jetson_Xavier_NX_QSPI_35.1.gz”, it seems to be not in a valid gzip format. I have downloaded the file on Windows/Ubuntu/Debian on 4 different machines with 2 different Internet connections. Everytime it is around 15MB in size but not in a gzip format (bad format). Please let me know how to get the jetson-xavier-nx-devkit.spi.img file which is needed to be flashed.
Hi are you having bad time flashing nx through gui and no issue with 5.0.1 also ?
Yes. I followed the below procedure to reflash the board. There are some pre-req for the host machine which are not mentioned in the guide (qemu installation and libxml requirement), but overall this is the process which worked for me smoothly.
I don’t know where to download specific image files, but normally such a thing would be with the specific L4T release page:
So far as the file being invalid, under Linux, what do you see from:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.