I have 2 related questions about the flash script that I am having trouble figuring out from the documentation.
The end goal is we want to have an artifact that contains everything we need to flash to a Jetson Nano and not need to have the person flashing have to download the SDK and run the build process.
We thought that if we generate the system.img file it would be everything we need for the flash.sh script to flash all partitions on both the B01 SD card board and the final EEMC board. If we look at the system.img partitions we can see that it contains all 14 partitions (EDIT: the output from the jetson-disk-image-creator had all 14 partitions). However, when we run flash.sh with the -r flag it pulls data blobs from the bootloader (and the internal signed directory) directory. It seems the only thing that system.img is being used for is flashing the APP partition. Why is this happening if we already built a system.img file? Shouldn’t it be flashed flat to the device? We are not sure why we the flash.sh script is going through the trouble of building the system.img with all the partitions if it is not using it.
The second question then comes out of the first one, if the system.img file is truly only useful for the APP partition, what are the other required data blobs we should be storing out of the build step for a future flash step? We don’t want to require a download of the whole sdk, we were really hoping for a single data blob that we can have a user pull down from our repository and flash it to the Jetson Nano.
it’s the flashing process to copy binaries into rootfs folder and making system.img.
that’s APP partition to contain this image file, please also check Flash Script Usage, if you include -r options into flash command, it’ll skip building system.img; re-use the existing one for image flashing.
there’re binary files and also scripts, tools to detect the board and running the flashing process.
however, you should create a massflash blob if you’re going to have a portable blob that could flashing Jetson devices anywhere, please refer to README_Massflash.txt for the instructions.
Yes we understood the -r flag. But we had assumed (wrongly it seems) that system.img contained all the partitions and not just the APP partition. We thought it was the only artifact we needed in our build process.
We are looking at the massflash process now. What we want is the portable blob that can be flashed in a non-trusted enviornment.
Will the massflash process work with the SD card version of the Nano so we can finish developing the process with the dev boards before moving to EEMC modules?
On the SD card version, assuming they are using a rootfs/APP image which is recent, you could use the flash script to flash just the QSPI target of a recovery mode Nano (flash.sh has a QSPI target which can be named for a recovery mode SD card model of Nano). Then any method of cloning the SD card rootfs/APP would do the job.
So there isn’t a way we can prove out the production pipeline using B01 boards then? We have to keep using the flash script for the B01 boards it sounds like and figure out massflash once we get access to the production boards.
Mass flash works, but was designed for eMMC versions. For SD card versions you can mass create SD cards, but I don’t know if flash.sh can mass flash QSPI on SD card versions. Can someone from NVIDIA comment on mass flash versus QSPI of an SD card model?
Note that QSPI is not an issue with eMMC models. Mass flash will work with that.
Why do you want to do a massflash work on nano SD module? We don’t have any tool support “massflash” on such module because this kind of module is not able to do massflash.
This kind of module only sold along with devkit.
Unless you want to buy a devkit, separate the module from carrier board and put that module on your own product. But this makes no sense to do that.
Yes but we want to develop our whole process and get the production team the scripts they need. Right now we all have devboards to test with. We are wanting to prove the process works with what we have.