Over-the-air update

Hi,

I’ve a AXG Orin board with version R35.2.1 of jetson linux. I would like to utilize the OTA-tools to update say only the rootfs of the system without bumping the version of jetson linux.

However, if I’m reading the documentation correctly I would have to bump the version to R35.3.1 at least for this to work. Have I understood this correctly ?

Hi christian.johansen,

Are you using the devkit or custom board for AGX Orin?

Do you mean that you just want to update the rootfs only? (w/o update bootloader)

Do you mean the image-based OTA or debian-based OTA?

Hi Kevin,

Are you using the devkit or custom board for AGX Orin?

We’re using the DSBOARD-AGX from FORECR

Do you mean that you just want to update the rootfs only? (w/o update bootloader)
Yes, without updating the bootloader.


https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/SD/SoftwarePackagesAndTheUpdateMechanism.html#updating-jetson-linux-with-image-based-over-the-air-update

Do you mean the image-based OTA or debian-based OTA?
Image-based OTA

It is a custom carrier board for AGX Orin.

You could just refer the steps in the link you shared and add -r paramter when you are generating OTA package.

  • -r: Generate an OTA payload package to only update rootfs. This option is meaningful only for an update without layout change.

You’ve said you can use one can use custom board configuration for image-based OTA in this thread: Image based OTA for jetson-orin-nano-devkit and costum board - #7 by KevinFFF

I can’t seem to find any documentation on this though. Could you point me in the correct direction? :)

Yes, you could use image-based OTA for your custom board if the layout doesn’t change.

Have you refer to the developer guide step-by-step to perform the image-based OTA for roorfs only on your board?

Yes, i’ve looked into the step-by-step guide.

But in step 7 in Steps Performed on the Host Machine the l4t_generate_ota_package.sh script does not accept any custom target_board.

<target_board> is the appropriate configuration name.

What is board config you used to flash your custom board?
(i.e. what’s the full flash command you used which could flash your board successfully?)

sudo ./flash.sh jetson-agx-orin-custom mmcblk0p1

Where I’ve created a jetson-agx-orin-custom.conf file

So, you should use jetson-agx-orin-custom for <target_board> with l4t_generate_ota_package.sh.

Okay.

However, for <target_board>=jetson-agx-orin-custom to work I guess I have to add our board spec to the ota_board_specs.conf file ?

Yes, you might add them for custom board config, or you could just replace the jetson-agx-orin-devkit.conf with your custom board config.

Do you have any custom layout change for your custom board?

1 Like

If by

Do you have any custom layout change for your custom board?

you’re referring to " Partition Layout Changes", then no, we do not have any custom layout changes at this point.

However, we’re considering it for some future use cases.

okay, if you have custom partition layout change, you may have issue with using OTA tool directly.
You are just asking update rootfs only here so that it should be fine with your use case.

I’ve now successfully created a ota-package doing as you suggested:

or you could just replace the jetson-agx-orin-devkit.conf with your custom board config.

However, when executing step 8 in Steps Performed on the Jetson Device i get the following error:

Failed to swap partition names.
Failed to swap partition name and guid of recovery and recovery_alt.
Failed to run “update_specified_partitions_alt recovery /ota_work/internal_device/images-R35-ToT/recovery.img /tmp/sha1sum.t
mp”
Failed to run “install_partition_with_alt /ota_work/internal_device/images-R35-ToT recovery”
Failed to run “update_partition_with_alt /ota_work recovery”
Failed to run “update_misc_partitions /ota_work”

I’ve attached the full log
ota_20230327-180029.log (6.3 KB)

I’ve also tried to reboot the device.

Any idea what’s wrong ?

Are you using custom BSP for both R35.2.1 and R35.3.1?

Do you use -r parameter to generate OTA package for rootfs only?
Please also share the full log when you generated the OTA package on host PC.

Are you using custom BSP for both R35.2.1 and R35.3.1?

Yes. And I’ve updated the target board to version R35.3.1 in advance. So both BASE_BSP and TARGET_BSP were on R35.3.1

Do you use -r parameter to generate OTA package for rootfs only?

No. I ran sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh jetson-agx-orin-devkit R35-3 . Thought I might try to update the bootloader as well.

Please also share the full log when you generated the OTA package on host PC.

Does the l4t_generate_ota_package.sh script save the logs in the same manner as nv_ota_start.sh? If so, where is it stored ? If not, I do not have that log available any more. But I can rerun the script and save those logs.

So, you are using image-based OTA update from R35.3.1 to the same BSP?
What I ask is, are you using the custom BSP from your vendor for the custom carrier board?

You said you are going to update rootfs only before…
What do you want to verify for image-based OTA now?

There should be the log stored in your host PC, but I would suggest re-run the whole update flow and store the logs in every stage.
There should be two logs to check.

  1. The log on host PC when you are generating the OTA update package
  2. The log on the board when you trigger the OTA update process

So, you are using image-based OTA update from R35.3.1 to the same BSP?

Yes

What I ask is, are you using the custom BSP from your vendor for the custom carrier board?

We download the official BSP and customize it our selves.

You said you are going to update rootfs only before…
What do you want to verify for image-based OTA now?

Sorry for causing confusion, it was not my intention. The goal is the same as before. I will rerun all the steps again, and using the -r option for l4t_generate_ota_package.sh script

While updating the bootloader is not something we’re looking to do right now, we might go at it in the future. Therefore I thought I’d give it a try as well.

I’ve tried again with the -r option. But I still get the same results. Here are the logs: