Jetson Tx2 - flashing

Hi,
in Tx2, is there any way we can just copy dtb, rootfs as we do for Image file?
Currently using ./flash.sh script to flash the dtb and rootfs file.
can we just copy the dtb and rootfs file to Jetson and reboot will update the dtb and rootfs?

-jay

In order to enable copying both the kernel and the dtb file to your TX2 you will have to modify the /boot/extlinux/extlinux.conf file. This is the file that is read by U-Boot to figure out how to boot up the kernel

This is what mine looks like:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL NVIDIA TX2 Devboard
      LINUX /boot/Image
      INITRD /boot/initrd
      FDT /boot/tegra186-quill-p3310-1000-c03-00-base.dtb
      APPEND ${cbootargs} quiet

LABEL backup
      MENU LABEL NVIDIA TX2 Devboard Backup
      LINUX /boot/Image.back
      INITRD /boot/initrd
      FDT /boot/back.dtb
      APPEND ${cbootargs} quiet


# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

I think the default extlinux.conf that the TX2 initially gets flashed with omits the FDT entry, and U-Boot pulls an FDT that is baked into U-Boot itself. This can be frustrating because you can’t update the Device Tree the same way you would with the kernel.

Although I am not sure if cboot, the bootloader before u-boot, modifies this device tree in some way.

In my extlinux.conf I’ve added the ‘backup’ entry (as the note on the bottom suggests) and I also copied the /boot/Image to /boot/Image.back and copied the /boot/tegra186-quill-p3310-1000-c03-00-base.dtb to /boot/back.dtb that way if I mess something up I can always select the backup boot over the serial console.

If you wanted you could also omit the FDT entry in the backup so it behaves ‘normally’.

Dave

@dmc already mentioned device tree details. For rootfs you will want to use flash.sh since you can’t really replace an entire partition while it is in use. There are some cases where a dtb needs to be signed prior to being added, but if the content is signed correctly (or using a release which did not require signing), then you can work with this as a file. Note that a device tree is used during boot, but once this is loaded, then the original device tree file is not used…there is no conflict in overwriting a dtb file once boot is complete (although doing incorrectly could lead to needing to flash).

Thanks for reply guys.

  1. So it means, we can just copy the Image and dtb file to /boot/. directory. But the rootfs, I need to flash all the times (whenever it is changed), I cannot just copy-paste-reboot for rootfs to take effect. Is my understanding correct?
  2. extLinux.conf file → what is the command to use backup copy? how/where to notify the Jetson to take backup copy, when the primary copy fails?

BR
Jay

@yajforforum

Yes, but you do need to modify the extlinux.conf to use that specific DTB file. As an example if you wanted to be able to just copy over the tegra186-quill-p3310-1000-c03-00-base.dtb the same way you would with your kernel you would need to specify where to find that file in FDT value within the extlinux.conf file for your entry.

If you would like to change the root file system you could change it on the actual TX2 after you boot or if you would like you could re-flash the TX2.

I think the difference is dependent on the situation. Generally I don’t re-flash our TX2’s rootfs. Perhaps I am using our TX2 differently than you.

After you have modified the extlinux.conf you can use a serial console to select one of the options from the extlinux.conf

Here is information on the NVIDIA TX2 Serial Console:

NVIDIA TX2 Serial Console

When you turn on the TX2 instead of waiting for the GUI to come up you can see the TX2 boot through the various boot-loaders until it is ready to boot the kernel, right before it does it pauses for a few seconds to let you interrupt the boot process and allows you to select which version of the kernel you wish to boot, as a reference this is what it looks like for me:

...
U-Boot 2020.04-tegra (May 15 2020 - 17:20:30 +0000)

SoC: tegra186
Model: NVIDIA P2771-0000-500
Board: NVIDIA P2771-0000
DRAM:  7.8 GiB
MMC:   sdhci@3400000: 1, sdhci@3460000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:
Warning: ethernet@2490000 using MAC address from DT
eth0: ethernet@2490000
Hit any key to stop autoboot:  0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1180 bytes read in 22 ms (51.8 KiB/s)
L4T boot options
1:      NVIDIA TX2 Devboard
2:      backup
Enter choice:

If you don’t enter anything after a 3 second timeout the first option from the extlinux.conf will automatically be selected and booted.

@linuxdev
I haven’t had to deal with signed DTB files, thanks for the info!

Dave

Thanks Dave for details.

This is correct. Mostly the kernel is just the “/boot/Image” file, and can be updated as a simple copy on a running system. The Image file is not accessed after initial load…it is really the bootloader which uses this in file format, not the Linux operating system…within Linux this is already in RAM (unless an initrd does the loading, and then you must also deal with initrd updates if the initrd does something unusual).

So far as device tree goes, there are differences depending on release. In some cases you can just add the dtb file through the extlinux.conf DTB entry with the file in “/boot/dtb/”, but sometimes it has to go into a partition (some releases require earlier boot stage access to the tree, but those stages have no ability to read ext4…so those particular releases need the tree as a binary partition instead of a file format on ext4…releases not requiring early access, and releases where earlier stages understand ext4 do not have such a requirement).

In later releases the dtb also needs to be signed, though in earlier releases this was not the case. You have to check with the documents of that particular type of Jetson and that particular release.