I have one (only one) jetson nano based custom board that is currently flashed with jetpack-4.4.1 based custom firmware (at least for uboot, dtb and kernel). I have not the sources of what has been flashed on that board, but it works well as is.
I would like to be able to experiment with newer versions of jetpack and my own customisations of uboot dtb and kernel but need a reliable way to restore software on the board to its current state. All the software is currently on the emmc. Is there a way, once the CPU is put in recovery mode to read the whole emmc across the USB bus and put it in a file, and conversely to erase the whole emmc and write that raw backup file into the emmc ?
you’re able to back-up/copy your APP partition, (i.e. system.img), which is rootfs to contain all your data.
please refer to developer guide, To clone a Jetson device and flash. thanks
Additional notes you might find useful: There is more than one method of loading a device tree, firmware, or kernel. If you have those items on your rootfs (e.g., in “/boot”), and specify those items from the “/boot/extlinux/extlinux.conf” (e.g., the FDT key/value pair for the device tree), then mostly you already have what you need.
The actual non-rootfs partitions and the rootfs have some dependencies. You would not want to boot with non-rootfs content which is flashed via a different release versus the release which originally created the rootfs. Flashing using the right L4T version gives all of the correct non-rootfs content. The exception is of course if you have custom non-rootfs content, and in that case you’ll still get the right thing if your content is correctly added to the flash software on the host PC.
Regarding multiple methods of using some of the boot content, consider that people who have burned security fuses will always pull that content from signed partitions, and none of the kernel or device tree specified in extlinux.conf would be honored. However, unless you have decided to use content in partitions (and not in extlinux.conf specification), then you might as well just use your rootfs clone for that content.
Another observation is that non-rootfs partitions are signed, even if signed by a NULL key (the key is non-NULL if security fuses are burned). I can’t say for sure, but there could be cases of signed content of non-rootfs partitions not being interchangeable with other Nanos (although the private key is NULL, the signing itself might include other content which I don’t know about, and which might require a match to the specific hardware). Burning fuses is irrelevant for SD card models though, this only matters with eMMC models.
FYI,
the fuse is “PKC hash”, which is calculated based on a given PKC key. it’s actually the key (i.e. PKC key) with all zeros to perform fuse burning.
there’s odmfuse.sh it generates a config in odmfuse_pkc.xml, please check BootSecurityInfo for details.
thanks
there is no FDT entry in the extlinux.conf file on my board, so I surmise that the dtb comes from the DTB partition, and maybe some initialisations are also done by u-boot. I would like to save that also.
The aim is not to the save the APP partition, but to save the whole content of the EMMC of one specific board, and afterwards be able to use that backup of the EMMC (and only that backup, with the help of some programs or script but no other data) to reflash the EMMC of the same board
please check $ ls -la /dev/disk/by-partlabel, I assume you don’t need to copy all of them.
for example,
you could back-up device tree binary. please check the partlabel for DTB. i.e. DTB -> ../../mmcblk0p10
you may use dd commands to copy the binary and back-up that by yourself. $ sudo dd if=/dev/mmcblk0p10 of=back-up.dtb.encrypt
note, those binaries need to be sign/encrypted before writing into the partition.
If I do a backup of my nano board, and restore that backup afterwards on the same board, I do not need to sign the binaries again because they are already correctly signed, isn’t it ?
Is it possible to download the whole emmc (by parts if needed) using only tegrarcm_v2, and later use again only tegrarcm_v2 to restore the backups on the same board ?
please check $ ls -la /dev/disk/by-partlabel, those were sequenced partitions, you may write a script file to enable dd commands to dump all those binaries and maintain by yourself.
I just wanted to add that technically saving all partitions is not necessarily everything. If you run this command: sudo gdisk -l /dev/mmcblk0
…then you will see that the first partition starts at sector 4104, and the there is a block size of 512 bytes. There is some partitioning information hidden in sectors 1 through 4100.
This is more for the same of curiosity, but consider that you could in fact dd the entire drive (assuming it is read-only since the APP/rootfs could change during backup if not read-only). The entire drive would be via this once the rootfs is read-only: sudo dd if=/dev/mmcblk0 of=/some/non_rootfs/storage_device/disk.bin
(you could use a “bs” of multiples of 512 to speed this up)
Then, on a host PC, you could cover the entire file with loopback, followed by using dd on the loopback device to pull individual partitions. Or you could just use dd to pull data from lower than sector 4104 (either from the full clone on PC or when on the Jetson).
If the unit being restored had already been partitioned correctly to match this, then you’d never need to worry about any of the above. However, as an example, if you were to try to restore this to a new module which had never been partitioned, then you might need the metadata from before sector 4104, but I’m not sure how the flash software could ever put this in place in recovery mode.
So far as I know recovery mode only allows installing partitions, and has no way to specify installing binary data to eMMC based on sector or byte offset. Would NVIDIA people happen to know if there is a way to use recovery mode to install binary data to an offset instead of to a partition label? The last time I saw this possibility was back in the early TK1 days.
Note: Not sure if it would be the same thing to dd “/dev/mmcblk0boot0” and “mmcblk0boot1” (or “mmcblk0<not p#>”), but these do not have labels so far as I know. Same as saying “not a partition” for the purposes of the flash software.