Why include the A_kernel, A_kernel-dtb, B_kernel, and B_kernel-dtb partitions in builds with a/b boot?

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

For systems that have a/b boot enabled, is there a good reason to include the A_kernel, A_kernel-dtb, B_kernel, and B_kernel-dtb partitions, given that a/b boot already provides redundancy? I’m asking because I see this partitions in my board’s _ab_ partition layout in Jetson_Linux_R36.4.4_aarch64.

My motivation for asking is that having these partitions complicates OTA and introduces some odd failure modes where the kernel and/or dtb in /boot/ could fail, and the system still boots the selected slot using the (older, I presume) Android-style images. I’d rather the system failover to the alternate boot slot if the extlinux boot fails.

For reference, the ‘extlinux’ → ‘kernel partition’ boot flow I’m talking about is this one.

4

hello vanvugt,

do you have bootloader logs for reference?

5

I’m not seeing any failures at this time. I’m only asking:

  1. Am I correct in understanding that, on systems that use the ExtLinux boot (i.e. kernel and dtbs are normally loaded from /boot), the kernel and dtb partitions are only intended to provided redundancy in case the ExtLinux kernel and/or DTB fail to load for some reason?

  2. Does it make sense to have this redundancy on systems that already have redundancy from having a/b boot, since they already have a failover method?

  3. Is there any problem with removing these partitions to simplify things on systems with a/b boot?

Thanks!

6

hello vanvugt,

>> Q1
that’s correct.
In ExtLinux boot mode, L4tLauncher first tries to load the kernel from the rootfs according to /boot/extlinux/extlinux.conf.
If that kernel image cannot be loaded, it can fall back to the kernel image in the slot’s kernel partition.
For device tree, if the FDT entry is missing or the DTB file cannot be loaded from rootfs, it uses the UEFI DTB; the kernel-dtb partition is used when booting the kernel from the kernel partition path.

>> Q2
ya, this still has value with rootfs A/B because it covers a different failure path. Rootfs A/B failover switches between rootfs slots after boot failures/retry handling. The A_kernel/B_kernel and A_kernel-dtb/B_kernel-dtb partitions are slot-associated payloads and provide a fallback or partition-boot path for the selected slot.

>> Q3
it’s not recommend removing these partitions from the standard BSP layout. They are part of the supported boot/update flow, and some flashing/OTA/secure-boot paths expect the kernel and kernel-dtb partitions to exist. If you remove them in a custom layout, you would need to validate the full flow yourself, including flashing, OTA, recovery boot, secure boot/signing if used, and the behavior when /boot/extlinux.conf or the kernel image is missing/corrupt.