Flashing Nano eMMC with RAW Disk Image over USB

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

How do you flash the eMMC on a production Nano over recovery mode with a raw image? The raw image that has been created includes all partitions. It was created with a similar method to the tool “jetson-disk-image-creator.sh”

I have looked as far as I can in the python source of tegraflash.py and tegraflash_internal.py and also tegradevflash --help.

It seems the only way to program the eMMC with tegradevflash is with the flash.xml.bin partition table and each partition file. Really I just need a raw write like dd, I am sure the bootloader (TegraBoot?) supports this but it isn’t exposed via tegradevflash?

The reason we need to do this would be to do a final checksum of the entire emmc when flashing multiple units to verify it is correct and also further down the line to verify the integrity of the unit.

Thanks

2

You would not use an image which includes other partitions. What you’d do is flash a root filesystem, and let the software put in the correct surrounding support partitions for you.

Those other partitions are different for eMMC versus SD card models, and would not correctly boot if mixed.

If you were to flash on command line and add the “-r” option to “reuse” the APP partition (the rootfs), then this would accomplish what is needed. The rootfs would be yours (you’d put it at “Linux_for_Tegra/bootloader/system.img” prior to flashing), and the surrounding content would be correctly signed and valid for the eMMC model. If you have modifications for a custom carrier board, then you’d have those in place prior to the flash.

I do not know for sure if the eMMC model mandates partition signing the way other Jetsons do mandate this (at least the non-SD card models), but I suspect this is mandatory. In that case you would not be able to simply copy an entire partition…you’d take the data part, sign it against the particular eMMC Nano, and then flash. The data would be constant, but the signature would change.

Do note that if you know the size of your content for a non-rootfs partition, and then use dd to extract the partition, you could look at just the non-signature part and perform your checksum for validity against the non-signature part of the partition. This would be a bit time consuming, and it would require the Jetson to be booted in order to use dd, but it could be automated.

I don’t know which of these URLs would be most useful to you regarding signing, especially since I’ve not checked this with an eMMC Nano (I only have an SD card Nano), take a quick look at these URLs (some of these are old, but I believe still correct, especially the sign.py script or l4t_sign_image.sh which is newer):

FYI, most Jetsons use U-Boot, but Xavier does not. Xavier’s CBoot has modifications to provide many U-Boot style options, e.g., reading extlinux.conf options. So if you look at Xavier documents you might notice some differences, but I think the non-rootfs signing will be the same regardless of whether Xavier uses CBoot instead of U-Boot.

EDIT: Note that if you have a single binary file which includes the entire content, then dd can extract a partition, followed by extracting the non-signature part of the partition. Or you can just extract the non-signature part directly, although I suspect that is more error prone.

1 Like
3

hello lyndonamsdon1,

you may also refer to mass flash script file for flashing multiple Jetson devices simultaneously.
please check the read me file in the release image, i.e. $OUT/Linux_for_Tegra/README_Massflash.txt for more details.
thanks

4

Perhaps you misunderstood what I was asking.
The point is for production it would be nice for example to have a 6GB or 8GB binary image that is copied byte for byte. I don’t want things to be re-created each time a module is flashed - there is potential for that to go wrong. Making a complete image shouldn’t be a problem, it’s getting that complete image into the eMMC that is the problem. It also means a year or two later you can verify that image is byte for byte identical to the one it was originally flashed with. See below the lack of options:

Usage: tegradevflash [--instance <number/path>] [--pt <file>] [--create ] [--read <name> <file>] 
                     [--write <name> <file>] [--erase <name>] [--storageinfo <file>] 
                     [--reboot <coldboot/recovery>] 
                     [--generategpt <primary/secondary> [out file]] [--flush_sata ] 
                     [--sata_fwdownload <file>] [--oem <cmd arg2 arg3>] [--skipsanitize ] 

   --instance         USB instance
   --pt               Partition layout
   --create           Recreate and write all partitions as per specified Partition layout
   --read             Read a partition into file
   --write            Write a partition with data from file
   --erase            Erase a partition
   --storageinfo      Storage information retrieved from tegrarcm
   --reboot           Reboot the device or put device in recovery
   --generategpt      Generate GPT from given partition layout
   --flush_sata       Flush the NAND cache of SATA drive to prevent sluggishness on boot
   --sata_fwdownload  Download the firmware to the SATA drive
   --oem              Run Oem Command
   --skipsanitize     Skip sanitize SDMMC

Are you saying that the eMMC contents need to be different for each Jetson Nano, as parts are signed? How does that work in the case of the SD-Card image that is provided on NVIDIAs site? That one works for all Nanos…
I thought by default the sign key is all zeroes unless the odmfush is written - therefore all Nanos would be able to run the same image…

Also, theres not much help with u-boot as the eMMC could be blank, unless you use the TegraBoot to load a secondary bootloader like u-boot into memory and then use u-boot commands.

5

The Massflash is probably as close to getting done what I wished for. I modified it so it doesn’t re-create the system image as that is cloned from the device. At least with this method the files are not re-created each time it seems.

Thanks

6

For the non-rootfs partitions, yes. So far as I know the signing is required even if the fuse is not burned…but burning the fuse prevents flashing without knowing the “non-all-zeros” key. I could be wrong about that, but so far as I know, the signatures resulting from flash without the fuse burned still work the same way as when the fuse is burned…but when the fuse is burned you need a secret to flash and have working keys.

Someone from NVIDIA may be able to confirm that individual Jetsons can or cannot share a non-rootfs partition which was signed on a different module and then transferred to a new module (when neither have fuses burned).

8

hello lyndonamsdon1,

you may also check flashing logs,
you should notice that several binaries were adding encrypt in the end of file-name.
for example,

[  14.8799 ] Writing partition NVC with nvtboot.bin.encrypt
[  34.1701 ] [................................................] 100%
[  44.6859 ] Writing partition NVC_R with nvtboot.bin.encrypt
[  44.9372 ] [................................................] 100%
..
[ 248.4141 ] Writing partition TBC with nvtboot_cpu.bin.encrypt
[ 259.9820 ] [................................................] 100%
[ 259.9929 ] Writing partition RP1 with tegra210-p3448-0000-p3449-0000-a02.dtb.encrypt
[ 260.6023 ] [................................................] 100%
[ 260.6178 ] Writing partition EBT with cboot.bin.encrypt
[ 260.6727 ] [................................................] 100%
[ 260.6986 ] Writing partition WB0 with warmboot.bin.encrypt
[ 260.7811 ] [................................................] 100%
[ 260.7891 ] Writing partition BPF with sc7entry-firmware.bin.encrypt
[ 260.8282 ] [................................................] 100%
[ 260.8365 ] Writing partition TOS with tos-mon-only.img.encrypt
[ 260.8729 ] [................................................] 100%
[ 260.8830 ] Writing partition DTB with tegra210-p3448-0000-p3449-0000-a02.dtb.encrypt
[ 260.9492 ] [................................................] 100%
[ 260.9648 ] Writing partition LNX with boot.img.encrypt
[ 261.0345 ] [................................................] 100%

if you’re not enable secureboot, that’s okay to duplicate the image to each platform.
otherwise, you’ll need keys of each platform, you’ll need to assign them to complete flashing process.
thanks