Is it possible flash only QSPI-NOR?

Is it possible to flash only the QSPI-NOR independent of the rest of the system?

In the “NVIDIA Jetson Linux Developer Guide” under “Preparing a Jetson Developer Kit for Use” it states:

you can follow these instructions to flash the QSPI-NOR, or flash the QSPI-NOR and a microSD card inserted in the Jetson Nano module

However, there is no further mention of the procedure for how to do this for QSPI-NOR only.

hello Kangalow,

may I know what’s the actual use-case to flash QSPI-NOR only?

you may also check flash cfg, which only include SPI device types.
i.e. $OUT/Linux_for_Tegra/bootloader/t210ref/cfg/flash_l4t_t210_spi_p3448.xml

it’s possible to achieve this by using the specific flash configuration, i.e. jetson-nano-qspi.conf
so,
it should works as following, $ sudo ./flash.sh jetson-nano-qspi mmcblk0p1

1 Like

Thank you, I will try this out. I will guess that this is for all of the Jetson Nanos.

I have two cases for the QSPI-NOR flash. The first is for when I have a project SD card with an earlier version of JetPack. Flashing a new empty SD card with the older JetPack (which also flashes the QSPI) so I can use the project SD card is a lot of work. Also, it’s not very intuitive to many folks why their older project SD cards don’t work once you switch over to JP 4.5+, or why a newly flashed JetPack 4.4+ SD image doesn’t work on an upgraded machine.

The second case comes from another little project. I had been trying to boot a Nano 2GB from a SSD USB drive, but depending on how the drive was connected to the Jetson (connected directly or through a powered USB hub) the device was not being recognized. My guess was that the ‘usb start’ in UBoot did not wait long enough for the SSD to come online before enumeration. I changed the UBoot environment variables to wait a little while after starting, and then ‘usb reset’ which causes a USB renumeration. The drive appears as expected.

However it’s easy to make a mistake and put the UBoot system in a bad state since this is not an area I frequent much. If it’s just a matter of a quick flash of the QSPI-NOR to get back to the default state in UBoot, life be good. If you have to flash the whole system again (which takes more than 10 minutes in my dev environment on top of the amount of time it takes to download all the source material) this significantly effects development time.

actually, you’re able to Flashing U-Boot Only instead of flashing the full Jetson Linux driver package to the target.

How much of the environment which U-Boot sees on startup is from the QSPI-NOR? I can see the logic of flashing QSPI as opposed to flashing U-Boot if it is about inherited environment.

In my case, I was jiggering around the UBoot environment variables (you can see them using the printenv command at the UBoot command line). The env vars appear to hold small scripts, some of which I changed in order to do my bidding.

I guessed that the UBoot environment variables were in the NOR as a fresh SD card flash had no effect on them. It’s kinda in the middle, flashing UBoot only would probably reset the its environment variables it controls. However, I do not know whether that resets all of the environment variables, or if any of the environment variables there are not related to UBoot itself.

In any case, jetson-nano-qspi works for my case. Thank you @JerryChang !