Jetpack 5 and mender

[cmcquinn]

Commit 7d907b0 removed the tegrademo-mender disto stating that the existing mender integration will not work with Jetpack 5. What specifically is incompatible and is there some other way to integrate mender with Jetpack 5? I am working on a project currently based off of dunfell-l4t-r32.5.0 and would like to move to the latest kirkstone branch to get Jetpack 5 but mender updates are a feature that we use frequently. I would be willing to help make this work if it is possible.

Thanks,
Cameron

[dwalkes]

See OE4T/meta-tegra#1006 (reply in thread) for the latest status I know about. Help would be welcome if you'd like to take this on.

[cmcquinn]

Do we need to keep the platform-specific do_compile functions in https://github.com/mendersoftware/meta-mender-community/blob/kirkstone/meta-mender-tegra/recipes-mender/tegra-state-scripts/tegra-state-scripts_1.0.bb?

[dwalkes]

You will ultimately need a state script copy step somewhere, however the first priority should be figuring out what content to put in the state script and getting everything working from the command line.

[cmcquinn]

I have an initial attempt at updating the state scripts at https://github.com/cmcquinn/meta-mender-community/tree/tegra-jetpack-5/meta-mender-tegra/recipes-mender/tegra-state-scripts-edk2. How do I test them?

[dwalkes]

You'd test them by running them as scripts, which is what Mender will ultimately do. However I think you are referencing things which aren't available yet, for instance I don't think the slot checks here will work yet and I don't think it's going to be possible to only update one slot yet, I think you'll need to update both slots at once with either multiple calls to tegra-bootloader-update or using nv_update_engine --forced-install as described in https://docs.nvidia.com/jetson/archives/r35.1/DeveloperGuide/text/SD/Bootloader/UpdateAndRedundancy.html#update-bootloader. I suggest getting the scripts tested and working individually first before you try the mender update though, they are difficult to debug once they are built into the update package.

[dwalkes]

Possibly related discussion in OE4T/meta-tegra#1115 - I'm wondering if we can skip the entire A/B integration headaches with NVIDIA going forward and use a similar recovery partition scheme for updates:

1. Across L4T releases/handling partition layout changes
2. Written to other storage devices like nvme
3. Optionally applying encryption
4. As a basis for image updates instead of requiring A/B partitioning.