Is it possible to run L4T's flash.sh ( or equivalent ) from the target Xavier?

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 (https://linux.die.net/man/1/mkimage) 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 https://elinux.org/Jetson/AGX_Xavier_Alternative_II_For_Cloning

Thanks @linuxdev, @Andrey1984, for your valuable input.

Just to be thorough, https://github.com/rbonghi/jetson_easy 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.