Assuming target was booted from SD or USB instead of emmc.
The actual executable is from the “driver package” (which SDKM or JetPack will download). The driver is an x86 binary, and cannot run from arm64. Further, the Jetson itself is not booted when the driver package runs…it is in recovery mode. Recovery mode causes the Jetson to change from being a host to a custom device (and the device is understood only by the driver package…it isn’t an emulation of a hard drive). So there is no possibility…even if you could run virtualization to run an x86 program, the Jetson itself would have to be in recovery mode…which means it can’t be booted.
@linuxdev
Yes, I understand that flash.sh is a x86 tool and I am not trying to run it as is on the Xavier. Correct me if I am wrong, but there is no need to be in recovery mode to write to the emmc. (rootfs does it by default)
Let’s say I configure an SD card with rootfs, kernel and kernel_dtb on it.
I plug it in the Xavier SD slot and boot from it leaving /dev/mmcblk0 unmounted, ready for update.
These guys https://elinux.org/Jetson/AGX_Xavier_Alternative_For_Cloning use dd to read from it.
I could dd to it instead.
So the question really is has someone made a tool that gather all the image files (kernel, kernel_dtb, app, *_fw) put them in a Flattened Image Tree (mkimage(1): make image for U-Boot - Linux man page) or just a tgz, and it’s counterpart that will write it to /dev/mmcblk0?
And what to do with the *_b partitions? ( I am not looking to touch any of the bootloaders )
$sudo gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk0: 61079552 sectors, 29.1 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 37 entries
Main partition table begins at sector 2 and ends at sector 11
First usable sector is 40, last usable sector is 61079519
Partitions will be aligned on 8-sector boundaries
Total free space is 1 sectors (512 bytes)
Number Start (sector) End (sector) Size Code Name
1 40 58720295 28.0 GiB 0700 APP
2 58720296 58721295 500.0 KiB 0700 mts-mce
3 58721296 58722295 500.0 KiB 0700 mts-mce_b
4 58722296 58730487 4.0 MiB 0700 mts-proper
5 58730488 58738679 4.0 MiB 0700 mts-proper_b
6 58738680 58739703 512.0 KiB 0700 cpu-bootloader
7 58739704 58740727 512.0 KiB 0700 cpu-bootloader_b
8 58740728 58741495 384.0 KiB 0700 bootloader-dtb
9 58741496 58742263 384.0 KiB 0700 bootloader-dtb_b
10 58742264 58746359 2.0 MiB 0700 secure-os
11 58746360 58750455 2.0 MiB 0700 secure-os_b
12 58750456 58750711 128.0 KiB 0700 eks
13 58750712 58750967 128.0 KiB 0700 eks_b
14 58750968 58753015 1024.0 KiB 0700 bpmp-fw
15 58753016 58755063 1024.0 KiB 0700 bpmp-fw_b
16 58755064 58757111 1024.0 KiB 0700 bpmp-fw-dtb
17 58757112 58759159 1024.0 KiB 0700 bpmp-fw-dtb_b
18 58759160 58759671 256.0 KiB 0700 xusb-fw
19 58759672 58760183 256.0 KiB 0700 xusb-fw_b
20 58760184 58761207 512.0 KiB 0700 rce-fw
21 58761208 58762231 512.0 KiB 0700 rce-fw_b
22 58762232 58770423 4.0 MiB 0700 adsp-fw
23 58770424 58778615 4.0 MiB 0700 adsp-fw_b
24 58778616 58779639 512.0 KiB 0700 sce-fw
25 58779640 58780663 512.0 KiB 0700 sce-fw_b
26 58780664 58792951 6.0 MiB 0700 sc7
27 58792952 58805239 6.0 MiB 0700 sc7_b
28 58805240 59067383 128.0 MiB 0700 BMP
29 59067384 59329527 128.0 MiB 0700 BMP_b
30 59329528 59460599 64.0 MiB 0700 kernel
31 59460600 59591671 64.0 MiB 0700 kernel_b
32 59591672 59592695 512.0 KiB 0700 kernel-dtb
33 59592696 59593719 512.0 KiB 0700 kernel-dtb_b
34 59593720 59595767 1024.0 KiB 0700 CPUBL-CFG
35 59595768 59612151 8.0 MiB 0700 RP1
36 59612152 59628535 8.0 MiB 0700 RP2
37 59628536 61079518 708.5 MiB 0700 UDA
You can use dd from an alternate boot media, this isn’t a problem. There are a number of hurdles though. This may not be a complete list, but here are some common issues with that:
- The Jetson must be booted normally from an alternate rootfs. If any dd operation fails, then the unit is probably going to be unbootable and only flash.sh will work.
- All recent releases sign various partitions. You still need flash.sh on host side (or tools used by flash.sh) in order to perform signing.
- You cannot upgrade the rootfs to a more recent release unless all of the other partitions are also upgraded. Exceptions may exist for patch levels, e.g., it was possible to add the R28.2.1 rootfs to R28.2.
- If your update requires resizing partitions this may cause failure. Although in theory you would be able to adjust for a larger new partition this may be more difficult than it sounds.
if you are to use dd you may be do not need flash.sh, if you are writing directly, but for the use case when you are creating system.img from raw to write it with flash.sh.
However, you may as well use
echo u > /proc/sysrq-trigger
to write to or read from a halted filesystem of booted OS [not recommended, but works, as per my observations]
You may as well use the-alternative-II-method for reference Jetson/AGX Xavier Alternative II For Cloning - eLinux.org
Thanks @linuxdev, @Andrey1984, for your valuable input.
Just to be thorough, [url]https://github.com/rbonghi/jetson_easy[/url] will not work on Xavier because the script does not ( as far as I know ) write the kernel partition?
Xavier differs from the other Jetsons in that it doesn’t use U-Boot…boot is directly from CBoot, and thus the kernel must live in a partition (CBoot doesn’t understand ext4). I have no idea if the URL you named takes that into account or not. If it does, then it should work, but otherwise it would fail. You could always back up a rootfs copy, and then try it out to know for sure.