I have a Jetson Nano that will not boot to the SD card. I have confirmed that the image is fine (another Nano boots to this image). A suggested fix is to reflash the QSPI-NOR. I have read and re-read posts and documents about how to do this and I’m still not quite sure how to complete this task.
I do not have access to a linux host, so it seems like my choice is to use the sdk manager docker. I’ve gotten that up and working.
I am not actually testing this, so beware I might leave out a detail. The basic command line environment is available somewhere in “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/”. You will want to change to that location before starting. Example for Nano plus JetPack 4.6: cd ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra
(this will be in place if you’ve run sdkmanager once)
The general formula for a command line flash is what you are interested in. Notice there are several “jetson-*.conf” files which serve as a target to pick what it is you want to flash (there is more than one model of Jetson, and among models there can be differences; for example, the SD card model as a whole or just the QSPI). An example flash for QSPI, assuming the content was set up where my example is: sudo ./flash.sh jetson-nano-qspi mmcblk0p1
In the above you leave off the “.conf” extension, but effectively named the Jetson Nano QSPI. The location mmcblk0p1 differs depending on model, and in this case it is ok for use with QSPI. The Nano would need to be correctly connected to the host PC and in recovery mode. Your container may fail if the USB does not pass through correctly, so you’ll have to be sure your host PC always passes USB through even if it disconnects and reconnects. It is up to you to configure this, but sometimes if USB is lost unplugging and replugging the USB will work.
Do note that you are correct that QSPI content can differ. The SD card image was designed for some version or release. The JetPack release used must match for the version on the SD card. If you need an older release, then you can use the newer SDKM via this command line (do not use sudo): sdkmanager --archivedversions
(which starts sdkmanager normally, but offers a list of older releases)
Thank you for responding. I am using the docker container because I don’t have a Linux host. I’m following these directions regarding the docker version of the sdk manager: Docker Images :: NVIDIA SDK Manager Documentation
I’m unclear how to use the sdkmanager container to flash the QSPI-NOR. Do you know how this is done? In this context, I’m not sure how to change to the directory you indicate above. I’m also not sure how to run the flash script through sdkmanager using the container.
Thanks for your time and anyone else who responds.
Use command line flash, and name that target. As mentioned in a prior reply, this is an example, and in this example it is the target of compile which says to flash QSPI (and telling JetPack/SDKM to download and set up for flash will install that command line environment): sudo ./flash.sh jetson-nano-qspi mmcblk0p1
(there are possibly other options, but this should do the job…if not, then just post the result)
I was hoping to do this all using a linux host, but it died. So now I have to use docker which I don’t really understand except at a really high level. So, I understand that Docker is a conduit through which I can access a different OS than the one I’m using and that it creates the environment I need to issue commands. However, when you tell me to issue “sudo ./flash.sh jetson-nan-qspi mmcblk0p1” I’m confused. Do I need to envelope this in a DOCKER RUN or something like that? I’ve been through the SDK Docker info and that hasn’t made it less opaque. I hope you can help me bridge this inexperience, but in the meantime I’m going to hit the Docker tutorials to see if that helps any of it make sense. :P. Thanks so much for your time!
2 hours later (with a French accent)… So, I think I understand this better. I’ve managed to make a Dockerfile that makes the updates necessary to use the docker image. I just need to get the “Creating a user section” up and running: I get how to do that I just have to provide with the user and pwd.
I know how to run the docker container, but am still not entirely clear if when I run the container I am now in a position to run cmds as if I am inside the container. I know I can start bash from the docker run, is that the secret piece I’m missing? LOL, am I getting warmer?
Finally, the NVIDIA SDK Manager documentation indicates that you need to map the target image folder to your host machine AND map usb ports by running --privileged -v /dev/bus/usb:/dev/bus/usb/ . However, this looks like you are mapping a linux style usb port to another linux style. I have a mac. How is it done on a mac can I legit map /dev/tty.usbmodem… to /dev/bus/usb?
I know dealing with people who are new to a topic is difficult, so I appreciate the response. Don’t give up on me yet. :)
I can’t answer the docker questions, it isn’t something I’ve dealt with. Others could, but I think you have the basic idea. Docker will more or less create a miniature environment pretending to be some particular o/s and release, the parent o/s will pass through some hardware or services (such as USB), and this miniature “disposable” environment will have some minimal environment which the running software will neither be aware of, nor care about.
The JetPack/SDK Manager software is just a front end to flashing software. This software installs other requirements (and downloads them) for you. The result is that the driver package is installed (a recovery mode Jetson is a custom USB device, and the driver package understands the Jetson in this mode).
The location of the driver package is somewhere in: ~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/
“Linux_for_Tegra/” is the driver package, and in that location most commands can be entered manually (when SDKM flashes it just calls the programs there).
The “flash.sh” program is located there, and if you change to that directory listed above, then you can run commands based on “flash.sh” manually. You’d simply cd to that location, and type in the command I listed in the previous post. If the Jetson is present in recovery mode, then it should succeed.
Incidentally, if something were to go wrong, then you’d want a log of the flash. You can slightly change the flash command line and get a log for posting if you wish. Example: sudo ./flash.sh jetson-nano-qspi mmcblk0p1 2>&1 | tee log_flash.txt
(and “log_flash.txt” would contain a log of all you saw during manual command line flash)
I can’t help on docker setup, but there are differences in how USB or other hardware works on a Mac (though it is nice that it is UNIX-like), and part of the job of docker is to abstract out those differences. I don’t know how to tell a Mac to pass through a USB device to a docker container, but once it is done, then the container should do the rest.
Thanks for the additional information about creating the log. I appreciate your time. Still not sure how to make this happen using Docker, but I’ve reached out to another contact and hope they might provide me with some guidance.