Flash kernel dtb remotely via ssh session

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

I updated my dtb and confirmed it is working via the FDT in /boot/extlinux/extlinux.conf. /sys/firmware/devicetree/base shows my changes.

My question is how I can flash this dtb to the dtb partition remotely? Here is what I already tried:

I first confirmed the active partition to be A (sudo nvbootctrl get-current-slot), then dd my new dtb file to the partition:

sudo dd if=mycustom.dtb of=/dev/disk/by-partlabel/A_kernel-dtb bs=1K oflag=direct conv=fsync

I also removed FDT line from extlinux.conf

After reboot, sudo nvbootctrl get-current-slot show we are still on the same slot, but /sys/firmware/devicetree/base doesn’t show my changes.

3

— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —

To flash the kernel dtb remotely via ssh session, you can use the flash.sh script provided by NVIDIA. However, since you are trying to flash the dtb partition remotely, you can use the dd command to write the dtb file to the partition.

According to the provided context, the correct command to flash the dtb partition is:

sudo dd if=mycustom.dtb of=/dev/disk/by-partlabel/A_kernel-dtb bs=1K oflag=direct conv=fsync

However, this command alone may not be enough to ensure that the changes are persisted across reboots.

To ensure that the changes are persisted, you need to update the extlinux.conf file to point to the new dtb file. You can do this by adding the following line to the extlinux.conf file:

FDT /boot/mycustom.dtb

After making these changes, you can reboot the system and verify that the changes are persisted by checking the output of /sys/firmware/devicetree/base.

Note that the provided context does not explicitly mention the use of flash.sh for flashing the dtb partition remotely. However, it does provide information on how to flash a specific partition using the -k option with flash.sh. If you want to use flash.sh to flash the dtb partition, you can try the following command:

sudo ./flash.sh -r -k A_kernel-dtb jetson-agx-orin-devkit mmcblk0p1

However, this command may not work remotely via ssh session, and you may need to use the dd command instead.

I could not find clear support for flashing the dtb partition remotely via ssh session using flash.sh in the provided context.

— We support team will also look into your issue to have further suggestions soon. please stay tuned. —

5

The AI answer is contradicting itself, first it echos my dd command, but then says it won’t work, but finally it says I will need to use dd.

6

updating-dtb-files

Create your_filename.dtbo with only your changes.

Copy it into:
Linux_for_Tegra/kernel/dtb/

Add it to your board config, for example:
ls -al jetson-agx-orin-devkit.conf → p3737-0000-p3701-0000.conf

OVERLAY_DTB_FILE=“L4TConfiguration.dtbo,tegra234-p3737-0000+p3701-0000-dynamic.dtbo,tegra234-carveouts.dtbo,tegra-optee.dtbo,your_filename.dtbo,tegra234-p3737-camera-dual-imx274-overlay.dtbo,tegra234-p3737-camera-e3331-overlay.dtbo,tegra234-p3737-camera-e3333-overlay.dtbo,tegra234-p3737-camera-imx185-overlay.dtbo,T234SetFmpImageTypeGuid.dtbo”;

Flash your board.

7

I guess you meant using USB cable which is not what I asked. Maybe I wasn’t clear in my original post. My system is remote and the only access I have is ssh. I have an updated/custom dtb file. If I were to have it locally, I would be able to update my board config to point DTB_FILE to mine, and run ./flash.sh with -b kernel-dtb to update the dtb partition via USB. My question is if it is possible to scp the dtb file to the remote system and use dd to update the kernel-dtb partition. For now, I am using FDT in extlinux.conf as a solution and interested to know how to update the kernel-dtb partition via dd or other tools

8

Over ssh is not without risk. Your current FDT extlinux.conf may be safer.

# 1. Confirm current slot
sudo nvbootctrl dump-slots-info

Note: if B is active slot change following to A_ and 0 
# 2. Write only the inactive slot DTB
sudo dd if=new.dtb of=/dev/disk/by-partlabel/B_kernel-dtb bs=4M conv=fsync status=progress
sync

# 3. Set boot to the matching inactive slot only if you also updated its rootfs/kernel as needed
sudo nvbootctrl set-active-boot-slot 1

# 4. Reboot
sudo reboot

# Before reboot, verify the DTB you just wrote matches what you intended
sudo dd if=/dev/disk/by-partlabel/B_kernel-dtb bs=4M count=1 2>/dev/null | \
  head -c $(stat -c%s new.dtb) | sha256sum
sha256sum new.dtb

# Before reboot, make sure someone is physically at the Orin in case it needs power cycled unless you got an ip or other remote power switch.
9

Hi user100132,

Are you using the devkit or custom board for AGX Orin?
What’s the Jetpack version in use?

Your DTB is loaded from rootfs rather than partition currently.
May I know why you want to update it from the partition(i.e. A_kernel-dtb/ B_kernel-dtb)?

If you want to update those 2 partitions, please perform image-based OTA.

10

Hi @KevinFFF

This is custom board. We have already done OTA from Jetpack 6.2 to 7.2, but found out 7.2 has one GPIO pin (PZ.02) used/busy by default, so we have to update dtb to disable that, so that our custom board can use it. Are you saying we could do another OTA from 7.2 to 7.2, with the updated dtb?

11

@whitesscott I tried your dd command, and then also extracted the bytes from the partition to compare sha256sum to the dtb file as suggested in your post. All looks good. After reboot, and “sudo nvbootctrl dump-slots-info” show it is booted from the correct slot that I updated, but “gpioinfo” still uses the pin “used”. In my new dtb, I disabled this pin, so the gpioinfo should show it as “unused”. Now if I update /boot/extlinux/extlinux.conf and use FDT to point to the same new dtb file, reboot, now “gpioinfo” shows this pin as “unused”, meaning my new dtb works.

12

Here’s the csv extract of hidden row283 that contains a use of PZ.02.

@KevinFFF may know if that matters.

Row 283: [None, None, 'GP280_XHALT_TRIG', 'XHALT_TRIG', 'unused_XHALT_TRIG', 'GPIO3_PZ.02', 'XHALT_TRIG', '', '', '', 'B', 'B', '', '', '', 'XHALT_TRIG', 'RSVD1', 'RSVD2', 'RSVD3', 'RSVD1', 'xhalt_trig_pz2', 'vddio_gpiod', '', '', '', 'XHALT_TRIG', 'GPIOD', 'ST/DD', 'BDGPIOLTL_DFCT6M16L_VD121812NC', '20K', 'z', 'RSVD1', None, 'PULL_DOWN', 'TRISTATE', 'DISABLE', 'N/A', True, True, True, True, True, True, 'VALID', 'unused_XHALT_TRIG', 'Not_Assigned', None, None, None, 'Disable', 'Disable', 'Disable', 'Enable', 'Mid', 'Disable', None, None, None, None, None, None, None, None, 'BM14', None, None]

I’ve seen other forum posts where Nvidia confirmed ota $same_jetpack to $same_jetpack works.

13

We had to add below to our custom dts to free up PZ.02 since we use it for something else on our custom board:

// Override inherited DevKit PCIe Wake mapping to free PZ.02 for our custom board GPIO
&{/bus@0/pcie@14100000} {
    /delete-property/ nvidia,pex-wake-gpios;
};
14

Since we aren’t touching the rootfs, I’m wondering if ota upgrade has an option to not touching rootfs partition?

15

Yes, performing an OTA update within the same release version is fully supported.
Please refer to Updating Jetson Linux with Image-Based Over-the-Air Update for details.

image
image1183×519 38.4 KB

16

@KevinFFF thanks!

The link says: -b: Generate an OTA payload package to only update Bootloader. This option is meaningful only for an update without layout change. Is kernel-dtb partition considered “Bootloader”?

17

Kernel DTB is stored in internal eMMC or external NVMe rather than QSPI(for bootloader).
So, you need to perform the image-based OTA to update them.