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 ?
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.
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”
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.
The log on host PC when you are generating the OTA update package
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.