my devices:Jetson TX2 NX(jetpack 4.6.2)
What do you mean by flash a system to a USB device? Do you mean flashing from a USB device? Backing up to a USB device? Using a USB device on host PC to avoid requiring disk space on the host PC during flash of the Jetson?
Sorry, I didn’t make it clear about my purpose. In fact, what I want to achieve is to back up the system in my Jetson device to a USB device. There are two options: directly copy/backup from the EMMC device in Jetson to the USB device, or use Linux_for_Tegra/flash.sh to flash the pre-backed up image to the USB device. Below is the method I use to back up the image using flash.sh:
#Set the device where the image needs to be backed up to recovery mode and connect it to the Host PC
sudo ./flash.sh -r -k APP -G backup.img jetson-xavier-nx-devkit-tx2-nx mmcblk0p1
cp backup.img bootloader/system.img
cp backup.img.raw bootloader/system.img.raw
#Use sudo ./flash.sh -r jetson-xavier-nx-devkit-tx2-nx mmcblk0p1 to flash my own image
Ultimately, I would like to prioritize booting my system from the USB device by modifying the U-Boot boot order on Jetson. I attempted to back up the system to a USB device on the Jetson by executing sudo dd if=/dev/mmcblk0p1 of=/dev/sda1 bs=4M status=progress. This method allows me to start the system from the USB device by modifying the root path in /boot/extlinux/extlinux.conf (but I believe it actually boots from the EMMC system and then starts the system from the USB device based on the root path). I tried to start the system from the USB device copied by the dd command in U-Boot, but ultimately this boot method failed.
The flash.sh method you is the best because the filesystem is not in use at the time of the backup. The system is recorded in its shut down state. If you use something like rsync, then there might be lock files and other “open” files, which isn’t ideal. Also, flash.sh creates an exact bit-for-bit partition image which can be used later with flash software. It does not matter if the image is on an external USB device or not, it is a good backup.
However, your copy of files to the bootloader/ subdirectory is not needed until you flash. In fact, if you ever flash without the “-r” option on command line, then this would be overwritten.
Incidentally, you can flash using either the sparse image (system.img) or the raw image (system.img.raw). Both result in the same flash, but the sparse image is usually smaller and faster. However, you cannot examine or modify the sparse image. During a regular flash the raw image is first created as system.img, and in the old days, this is where things stopped…the image was used for flash. The huge size of a full partition though slows things down. Later on the flash script was appended to move system.img (raw) to file name system.img.raw; then the sparse image was generated from this as file system.img (sparse). There is a mksparse tool which uses the NULL (“0”) byte as a filler to create the sparse system.img. That tool is available so you could modify the raw image if you choose, and then create a new sparse image.
Booting from external media can require different procedures because of the possible need for either chain loading or using an initrd. In turn, that content may not actually be on the rootfs partition that system.img represents…so cloning the rootfs may not be enough to restore an external media. You should consult the documentation for your exact model under your exact L4T release when looking at external media flash and backup/restore (see “head -n 1 /etc/nv_tegra_release” for the L4T version). Look up your L4T release here:
https://developer.nvidia.com/linux-tegra
Boot priority is one of those values that might not be in the rootfs. The same documentation listed for your model on your L4T release is where you would start. I have not personally worked on external boot media (I don’t have the media) so I’m the wrong person to ask about that.
Note that dd is almost exactly what flash.sh cloning is. However, dd works on a running Jetson. It is possible for files to change during the dd clone, and you would also have the issue of not cloning in the shut down state (some lock files and other content might appear open). However, if steps are taken to put the filesystem in read-only mode, then this is also a reasonable system.img.raw that can be flashed directly via change to name system.img while using the -r option (it would take longer due to large size). A sparse image can be created from the dd clone via the mksparse tool with NULL byte filler.
FYI, changing device in extlinux.conf is chain loading. This is possible because the boot stages already have all drivers needed, e.g., a driver for the external drive and a driver for the ext4 filesystem. This is one case where cloning the rootfs might also be sufficient to work with external media. I recommend adding a second boot entry for native boot to eMMC as well in case something goes wrong (you’d access that with serial console). If this fails, then it might indicate that you need an initrd boot (see the official docs for initrd flash). Chain loading does require eMMC to have valid /boot content, and then control transfers to the external device; initrd can skip /boot on the eMMC, but it still uses non-rootfs parts of the eMMC.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.