Persisting Suricatta/hawkBit update state (ustate) on Orin Nano . Recommended backend?

[TheBlackWolf20]

Hi all,

I have rootfs A/B + capsule updates working on a Jetson Orin Nano (NVMe), scarthgap / L4T r36.5 (JetPack 6), using meta-tegra together with the swupdate integration from tegra-demo-distro (layers/meta-tegrademo/dynamic-layers/meta-swupdate). Manual swupdate -i <image>.swu installs and switches slots correctly, and rollback via retry_count works as expected.

I now want to drive updates from a hawkBit server using SWUpdate's Suricatta mode. The blocker is the post-reboot status confirmation: Suricatta needs to persist its update state (ustate) across the reboot so it can report SUCCESS/FAILED back to hawkBit , and there doesn't seem to be a persistent place to store it on Orin.

From reading the sources, the core limitation is the lack of a persistent variable store:

• SWUpdate only has built-in support for persisting bootloader/state variables via U-Boot fwenv . This Jetson uses UEFI + L4TLauncher and has NO U-Boot, so the U-Boot environment that Suricatta would normally rely on simply does not exist.
• core/state.c persists ustate exclusively via bootloader_env_set/get(). The tegra-demo-distro swupdate_%.bbappend applies disable-uboot.cfg -> CONFIG_BOOTLOADER_NONE=y, and bootloader/none.c keeps the environment in a RAM dict -> lost on reboot.
• The cboot backend (bootloader/cboot.c) dlopens libtegra-boot-tools.so.1, but tegra-boot-tools/bootinfo.c rejects any chipid other than 0x21/0x18/0x19 (T210/T186/T194). Orin is T234 = 0x23, so bootinfo_open() returns ENODEV, and there is no t234 offset table.

So: no U-Boot env, and the tegra-bootinfo/cboot path doesn't support Orin.

Questions:

1. On Orin (T234), what is the recommended way to give SWUpdate a persistent bootloader-env backend for Suricatta's ustate (and action_id), given there is no U-Boot and tegra-bootinfo does not support T234?
2. Is T234 support planned or available anywhere for tegra-boot-tools (a branch/PR I might have missed)?
3. As a workaround I'm considering Matt Madison's generic "custom bootloader" patch (as used in tegra-test-distro) with a small interface script that stores ustate in a dedicated EFI variable (its own GUID, not touching RootfsStatusSlotA/B). ustate is written ~twice per update, so EFI write frequency is low. Does this seem reasonable, or is there a cleaner recommended path I'm missing?

Thanks!

[madisongh]

Have you looked at Dan's more-recent adaptation in the demo distro?

[TheBlackWolf20]

Thanks @madisongh ! Yes, I've read through it and I can see the new changes from Dan — the postinst() now uses set_efi_var (via uefi_common.func) to reset RootfsStatusSlotA/B on the target slot, and the new TEGRA_SWUPDATE_LAST_CAPSULE_UPDATE_COMPLETE_SLOT_MARKER writes a per-slot completion marker to a persistent partition (with the systemd WantsMountsFor wiring so the data partition is mounted before swupdate runs). That power-off-recovery mechanism looks great.

My remaining question is specifically about Suricatta/hawkBit. To report SUCCESS/FAILED back to a hawkBit server after the reboot, Suricatta persists an update state (ustate) through swupdate's bootloader-env interface (core/state.c -> bootloader_env_set/get()), and reads it back on the next boot to send the result. That interface is abstract — the actual storage depends on the selected bootloader backend. On this layer the backend ends up as BOOTLOADER_NONE (bootloader/none.c), which only keeps the env in a RAM dict, so ustate is lost across the reboot. Dan's new marker does persist, but it's written/read by scripts (the postinst lua and swupdate-genconfig.sh), so it isn't connected to that bootloader-env interface that Suricatta uses — i.e. the persistent storage exists, but Suricatta has no path to it.

So my questions:

1. Can I reuse Dan's changes to bridge this — e.g. provide a persistent bootloader-env backend that stores Suricatta's ustate on the same partition the completion marker already uses (reusing the WantsMountsFor mount sequencing)?
2. Is there anything already wired for hawkBit/Suricatta on Orin , or is a Suricatta integration something you're considering adding to this layer?

[madisongh]

I should have tagged @dwalkes directly the first time on this, hopefully he can answer these questions.

[dwalkes]

Yes sorry I missed this post

Can I reuse Dan's changes to bridge this — e.g. provide a persistent bootloader-env backend that stores Suricatta's ustate on the same partition the completion marker already uses (reusing the WantsMountsFor mount sequencing)?

Yes I think this should be possible.

Is there anything already wired for hawkBit/Suricatta on Orin ,

I haven't done anything specifically for this and haven't used it myself.

is a Suricatta integration something you're considering adding to this layer?

An option to enable suricatta integration and using bootloader-env backend to store state would be a great addition IMO.