Newbie guide to A/B kernel/dtb updating and fallback

[arrow53]

I have a stock orin nano dev kit using kirkstone with machine jetson-orin-nano-devkit-nvme

I'd like to be able to manually update my bootloader stuff, namely kernel/dtb. I'm kinda fuzzy on the procedure / tools. I think it goes something like this but I'm missing some steps that I'm hoping I can get help filling in.

1. I added this to my local.conf

IMAGE_INSTALL:append = " tegra-bup-payload"
TNSPEC_BOOTDEV = "nvme0n1p1"

2. I can boot the orin and nvbootctrl get-number-slots returns 2 slots
3. I see a file in my deploy directory tegra-minimal-initramfs-jetson-orin-nano-devkit-nvme.bl_only.bup-payload that I copy over to my target into /opt/ota_package/

But, now I'm lost. Do I use nv_update_engine? This seems to want to update both the A/B slots. I'd like to just update the non-active slot, make sure that finishes, then manually switch to that slot.

thanks!

[kekiefer]

The modern approach to bootloader updates is the capsule update. You deploy a special payload into to the esp partition, tell uefi about it, and it handles the rest.

Basically:

• build tegra-uefi-capsules
• install the tegra-bl.cap to /opt/nvidia/esp/EFI/UpdateCapsule/TEGRA_BL.Cap, creating the destination directory if needed
• execute /usr/bin/oe4t-set-uefi-OSIndications to tell uefi there's an update available
• reboot

If you use swupdate (or even if you don't), here is a good example that shows where the capsule package goes, and how to flag down UEFI: https://github.com/Trellis-Logic/meta-swupdate-boards/pull/1/files

[arrow53]

@kekiefer wow, this is perfect. Thanks a ton for pointing me in this direction.

[arrow53]

@kekiefer is the tegra-bl.cap just the bootloader? When I modify my device tree and try to update using this method I don't see a change. I see in the recipe there is also a tegra-kernel.cap. Is that what I want instead? If so, how do I generate it?

[kekiefer]

It looks like tegra-kernel.cap is generated at the same time, and put in the deploy dir the same way, so you should be able to use it. In the past we had different update engine payloads for kernel, bootloader, or everything.

I use extlinux with my own setup, so I don't have personal experience trying to add both payloads, and I don't know if it will work or not. Maybe someone else has tried and can provide some input here, or you could just try it and report back.

[arrow53]

ok. I'll do some digging. I'm not getting a tegra-kernel.cap so unclear why that's not happening.

build/tmp/deploy/images/jetson-orin-nano-devkit-nvme$ ls *cap
jetson-orin-nano-devkit-nvme-tegra-bl.cap  tegra-bl.cap

thanks.

[arrow53]

@kekiefer seems capsules only work for non external partitions. Orin nano / nx have dtb / kernel on external drive as why I'm probably not getting the tegra-kernel.cap

[arrow53]

@dwalkes I read this thread element but i'm a bit confused

For an orin nano with external NVME is the recommended way to update dtb / kernel to use meta-swupdate? I'm not sure I can use this layer for my purposes.

If I wanted to take a more manual approach could I just mount the dtb / kernel partitions and copy new files in place?

[arrow53]

@kekiefer I mean that sounds good to me. Ideally I'd be able to just manually put in place dtb, kernel, and my own rootfs updates in A / B partitions.

Ok, dumb question, how do I go from UEFI to extlinux?

[arrow53]

reading more about it, it seems better to stick with UEFI and try to figure out how to get it to work with that as UEFI is the future.

[kekiefer]

In our case, "extlinux" refers to a boot mode for the same UEFI loader, as opposed to the "direct" mode. See here: https://github.com/OE4T/meta-tegra/wiki/extlinux.conf-support

[arrow53]

@kekiefer very interesting. It seems this won't work with stock A/B redudancy?

https://github.com/OE4T/meta-tegra/wiki/extlinux.conf-support#incompatible-with-ab-redundancy

I don't see the cboot-extlinux package at any rate. This may have gotten nix'd in later releases

https://github.com/OE4T/meta-tegra/blob/nanbield/classes/l4t-extlinux-config.bbclass

[madisongh]

For R35.x and later, the recipe for creating the file is l4t-launcher-extlinux.bb.