Boot production module from external USB drive

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hi,

As many before us, we reached the point when we ran out of space on the internal eMMC. So far we were using the ‘nvmassflashgen.sh’ to be able to flash multiple units efficiently (this was very fast, simple and bulletproof).

Now we are using a USB drive as a rootfs and the process looks like:

  1. Create the rootfs on the USB drive
  • Partition and format USB drive
  • Mount the bootloader/system.img.raw and copy the contents to the USB drive
  1. Use the flash.sh to flash the eMMC
  • here we are uploading the kernel etc, and most importantly the the updated /boot/extlinux/extlinux.conf to the eMMC which would tell the system to use the sda1

The downside of this is that the installation process is more complicated and takes ~2x more time.

Ideally it would be the best to only create the USB drive plug it in the device and let it boot right away.

My question would be:

  1. Is there any hardware switch which controls the boot order and let us boot completely from the USB drive? (we are designing our own carrier board)
  2. If that is not possible what is the minimal set of files which needed to be flashed to the device eMMC? (at least to speed up the second step)

Thanks!

Bests,
Peter

3

There is no such hardware switch, and the boot order is controlled by U-Boot:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3274/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E05I0HA

You need QSPI bot not eMMC to be flashed.
Maybe something like this:

sudo ./flash.sh --no-systemimg -c bootloader/t210ref/cfg/flash_l4t_t210_spi_p3448.xml <your board config> mmcblk0p1

4

hi

Im not familiar with the QSPI configuration yet, can you provide a link where I can find documentation about it? I was searching the “NVIDIA Jetson Linux Developer Guide” but could not find the corresponding part how I could create the board configuration.

I was using this thread as a blueprint for my case:

The steps which I executed:

1, Create the rootfs on USB drive:

sudo parted /dev/sdc mklabel gpt
sudo parted /dev/sdc mkpart APP 0GB 238GB

sudo mkfs.ext4 /dev/sdc1

sudo mkdir /mnt/root_fs
sudo mount /dev/sdc1 /mnt/root_fs

cd Linux_for_Tegra/
sudo BOOTDEV=sda1 ./flash.sh --no-flash jetson-nano-emmc sda1

sudo mkdir tmp_system
sudo mount bootloader/system.img.raw ./tmp_system

sudo rsync -axHAWX --numeric-ids --info=progress2 --exclude=/proc ./tmp_system/ /mnt/root_fs
sudo umount  /mnt/root_fs

Then insert the USB drive into the Jetson Nano, put it to recovery mode and execute the following command:

sudo BOOTDEV=sda1 ./flash.sh jetson-nano-emmc sda1

So I wanted to get rid of this second step or modify it to only flash the required parts.

Are you aware of any better method to erase / clean everything on the prod module eMMC then executing a standard flash on the module? I would like to reset the board that I use for testing to factory settings to make sure that nothing is stuck somewhere (eMMC, eprom etc…) which could affect my tests.

Thanks!

6

Sorry I missed it.
For Jetson Nano series, QSPI memory only resides in the DevKit module (the one with SD card), but not the commercial module (the one with eMMC).
So you have to make sure the whole eMMC is flashed before you can boot from other storage devices, and the second step is therefore required.

7

ok I see, so this is the way to go.

One more detail about this, we were using the nvmassflashgen.sh utility, which enabled us to “mass flash” multiple units at once.

To create the installer we used this command:

sudo\
    BOARDID=3448\
    BOARDSKU=0002\
    FAB=400\
    FUSELEVEL=fuselevel_production\
        ./nvmassflashgen.sh \
            jetson-nano-devkit-emmc mmcblk0p1

There is very sparse documentation about the nvmassflashgen.sh (or I was not lucky with the searches) and based on the source I was also not able to clear it, so maybe you know. So if I modify the above command as:

sudo\
    BOOTDEV=sda1\
    BOARDID=3448\
    BOARDSKU=0002\
    FAB=400\
    FUSELEVEL=fuselevel_production\
        ./nvmassflashgen.sh \
            jetson-nano-devkit-emmc sda1

So adding the “BOOTDEV=sda” env var and use the “sda1” instead of the “mmcblk0p1” would it generate the mass flash installer as it would boot from the USB device? Or I do need to go with the one-by-one flash.sh? (of course I would need prepare the USB drive beforehand by copying the contents bootloader/system.img.raw to the USB drive)

8

well after I saved my previous comment I realised that I could use the empirical way as well :D to test it and see :D so I guess that would be my next step to create the mass flash installer like that and check if it produced the expected output.
But if you can confirm it would be great, I mean to know if that has any downside or something that I’m not accounting for.

9

Sorry for the late response.

Is this still an issue to support? Any result can be shared?

10

Hi

Sorry I missed to get back with the results, so I have solved it with the two stage approach mentioned above:

  • Create the USB pen drive(s) first, I have created a small script for that
  • Create the massflash installer with the command above
12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.