Flash using Ethernet

Hi,
Is it possible to flash the agx orin target without USB? maybe Ethernet?

Thanks

Not possible.

Thanks.

Follow up question:

Can I create a partition for example APP and generate system.img (or system.img.raw) on my host and then use some tool like dd to copy it into the partition?

I’m asking because maybe I’ll need to be able to flash certain partitions using ethernet instead of using the Nvidia flash tools with USB

In recovery mode a Jetson is a custom USB device. You might be thinking that recovery mode implies mass storage, but this is not the case. The only way you could write a partition with dd is if the system is (A) fully running, and (B) that partition is not in use. The flash software does essentially this: A binary copy of the image to the partition while the partition is not in use.

1 Like

so in theory (and practically) I can use the flash.sh script to generate all the images I need for each partition and then flash the target with Ethernet just without entering recovery mode and not using the flashed partition.

In theory, flashing the rootfs over ethernet is possible only if you have a way boot without using the rootfs, e.g., into an initrd that does not use, nor depend on, the rootfs. This would be equivalent to a rescue shell running in RAM.

As for other partitions, “sort” of. There might also be some QSPI content you cannot reach. However, all partitions other than rootfs/APP, must be signed. The default is to sign with a NULL key, but they still must be signed. A “--no-flash” operation exists for that purpose. The default is that images are created that are signed based preexisting images for non-rootfs content, used, and then deleted. The “--no-flash” helps. This doesn’t mean you’ll have access to everything, but this would cover a lot on the eMMC models like the AGX Orin.

Here’s what I’ll suggest: Log a command line flash. Take a look at the source and flash of every part of it. Maybe look closely at every XML file that is related to each flashed item, especially size and label and extents type information. Make sure you know which XML spec picks size and location. Keep in mind that if you change something manually that your change might not fit into the same partition layout and you might have move and/or resize partitions (it never helps if the end of one partition overlaps and collides with another partition). A typical command line flash logged:
sudo ./flash.sh jetdson-agx-orin-devkit mmcblk0p1 2>&1 | tee log_flash.txt

Things would be a lot easier if you only update the rootfs, but that won’t be easy because you need a fully running Linux system with ethernet, and it can’t use the rootfs partition while updating. No signing would be required for that.

Also, this is all from JetPack 5.x/L4T R35.x or earlier. There are some new mechanics with JP 6.x/L4T R36.x.

Thank you for your answer.

  1. If I use the A/B mechanism, can I flash the A partition using ethernet while booting from B partition? If your answer is yes:

    • How would you do it? maybe dd?
    • Can I use this same method to “flash” or dd any other partition? (again, now I boot from partition B)
  2. Does JP 6 support Ethernet flashing?

  3. If we talk about OTA updates, which is indeed possible using Ethernet, what is the difference between that and the method I suggested in section 1 (I’m asking for learning purposes)

Thanks

I have not tried working with the A/B partition scheme, so I can’t truly answer. I can make some observations though:

  • The new partition would have to match the size of the old partition.
  • Some partitions must be signed; rootfs is the only one which does not need a signature. The boot process though might look at something inside of the rootfs (I don’t know, though I doubt it does).
  • If you are running on the A partition, then in theory you could dd the B partition. If you know how to force boot to the B partition, then you could in theory do the same with the A partition.
  • I don’t know if UUIDs or any particular constraint is associated with the A/B scheme, e.g., maybe they use different partition UIDs, or the same PUID. I don’t know. Your partition would have to be valid.
  • Knowing how to temporarily swap to the A or B partition would help a lot since that means you could experiment on the B partition and make many attempts via running on the A partition; similarly, if B worked, then you would have the ability to work on A partition and make mistakes. I just have not worked on any A/B scheme to know. The answer for this might also change between different L4T releases.
  • It is the Jetson hardware itself that does not allow flashing normally. Jetsons do not have a BIOS, and this is why they cannot self-flash. It doesn’t matter if the media is ethernet, SD card, thumb drive, external SATA DVD, or anything else. If the boot stage driver supports the media, then it can read the media, but this requires booting normally, and not recovery mode. Even booting normally this is quite difficult. You would need an initrd to boot to that would then control the ethernet writing to partitions (and content would need to be pre-signed if you alter content other than the rootfs).

A Jetson in recovery mode is a custom USB device, like a keyboard, and the only method of altering this device is with a host computer with the driver to that custom USB device. The device is not mass storage. The part of the flash software which actually performs the flash is known as the “driver package”.

There are some backup/restore scripts related to all of this that also work with external media, e.g., to backup or restore NVMe. I have not gone into those scripts, but I suspect they use an initrd to do this. Initrd are amazing adapters. If you were to work on a partition when the system otherwise won’t run, you can flash the boot content to include an initrd. The initrd is a partition in RAM pretending to be a disk partition. This does not have the complicated file permissions structure of ext4, but every bootloader made will understand it. If done correctly, the initial RAMDISK can be edited to do either what it normally does, or something else:

  • Normally, get the kernel before running the initrd, and load modules/drivers and environment inside the initrd. Then pivot root from the initrd to the “/” of the actual disk.
  • Alternately, one could do the above, but instead of pivoting root over to the disk, it could either:
    • Pivot over to an NFS partition or iSCSI or other network device.
    • Simply copy network data into the new rootfs (either A or B), and then either reboot or transfer over to the new partition (the former won’t depend on NFS/network, the latter will depend on NFS/network each boot).

Note that as soon as the system reboots or pivots root to a new device that the RAM holding the initrd goes away. Aside from any drivers the kernel needs the initrd contains a simple init in the form of bash scripts (init is PID 1, the kernel is PID 0, and all processes after that are spawned by init; the kernel provides services, it is init that provides child PIDs).

Actually it depends on your definition of “flash” here.

Your “flash” sounds like just any kind of method to update the binaries on the board.

But generally the “flash” means the attempt from host PC to Jetson. Part of the flash process won’t work without using the usb interface. Even in jetpack6.

That is why I said it is not possible in the first comment.