Flash & boot with redundant kernel

Hi,
I read about the A/B rootfs mechanism.
My questions are:

  1. Is it possible that kernel_a image will be different than kernel_b
    That way I can use another kernel image and rootfs image as a backup mode

  2. How can I flash different kernel images into their appropriate partitions? (kernel image to kernel_a partition and other kernel image to kernel_b partition)

Thanks

Hi BSP_User,

Are you using the devkit or custom board for Orin NX?
What’s your Jetpack version in use?

Redundancy is used to prevent the failed in current slot. (no matter for rootfs or bootloader)
If there’s any error in current slot, it could boot from another slot to make the system working.
Please also refer to Update and Redundancy for details.

May I know what’s your use case to use different kernel image for 2 slots?
If you use different kernel image, you may also use different dtb for them respectively.
It seems not the official support from us and you may need to customize it manually.

I’m using both Orin AGX Industrial and Orin NX devkit / on custom carrier board.
Currently JP 5.1.2/5.1.3

My purpose is to create an additional “backup” operational system in case of rootfs/kernel corruption. In other words: set up a dual-boot environment which fallback to backup system in case of original system boot failure.

For my use case a system is: kernel , dtb and rootfs.

I divide my use case into two scenarios:

  1. both “regular” and backup systems are on the same boot device and I need to load the backup in case of corruption
  2. Each system is on a different boot device.

How can I implement these two options?

  1. Should I use/modify the initrd script?
  2. Should I modify the extlinux.conf to contain two labels with some conditionals?
  3. Should I edit UEFI ?

Thanks

Why you don’t use the same OS on both slot a and slot b?
When you hit the issue in current slot, it will switch to another slot and you can fix the issue from that slot.

You can try to switch to the backup slot and replace the kernel image/dtb in that system.
We don’t support and verify for this use case since our redundancy feature is to use the same bootloader/kernel/rootfs for both slots.

Why you don’t use the same OS on both slot a and slot b?

I want the option to use another os (different configuration for example).

When you hit the issue in current slot, it will switch to another slot and you can fix the issue from that slot.

what you are saying is that with the a/b mechanism I have two different kernel images separated from each other?

If that’s the case, can’t I flash the suitable kernel partition with a kernel image of my choice?

It seems another feature request rather than the redundant bootloader/rootfs we’ve implemented.

You can build and flash your custom kernel image.
Please refer to Kernel Customization — NVIDIA Jetson Linux Developer Guide 1 documentation for details.
For you use case(different kernel image for A/B partitions), maybe you can refer to partition layout XML about the A_kernel and B_kernel partitions. We use the same kernel image(LNXFILE) by default.

I looked at:

flash_l4t_nvme_rootfs_ab.xml

According to this file the kernel partition contains the LNXFILE which is boot.img
and the kernel_b partition contains the LNXFILE_b

Three questions:

  1. What is the value of LNXFILE_b and how can I modify it? from my understanding I have to modify it to point to another boot.img file (not the one pointed by LNXFILE)

  2. What is the boot.img file? what it contains and when its being generated?
    what is the relation between it and the kernel image?
    I’m asking because I’ll have to create additional one by myself

Assuming I’ll create two separate customised boot.image files and modify LNXFILE and LNXFILE_b values accordingly I think I’ll be able to get my goal.

  1. This scenario don’t let me use “backup” kernel+rootfs from a different boot device. Can I put kernel_b , app_b partitions in another boot device and boot from there in case of kernel_a , app_a boot failure?

Thanks

They are generating during flash. Please refer to flash.sh for details.

Boot device is selected from bootloader (UEFI). You can configure them in UEFI menu during boot up.
Every boot device has their A/B partitions for kernel and roofts(if you enabled). Please just customize the partition layout and the kernel/rootfs image for your use case.

If I use initrd flash, can I set their values there?

Yes, initrd flash will also call flash.sh to flash internal QSPI, you could use -p to pass the parameter.

I apologise, I don’t understand your answer. I think we are talking about two different things.

  1. I want to modify LNXFILE and LNXFILE_b variables to point to two different boot.img files.

As you instructed me, I looked at Flash.sh and saw that both boot.img files (for LNXFILE and LNXFILE_b variables) contain the same kernel image and its hard coded in the script.

So, my solution is to manually modify this script and make sure that each boot.img will be composed of different kernel image.

  1. I asked if its possible to do that when using initrd as well (since there is no reference to these variables in the initrd script).

you told me to use the -p flag.

I don’t understand the relation

The initrd flash is used to flash the external device like NVMe SSD.
It will call flash.sh so that you can still customize the flash.sh for the kernel image you want.
If you want to add parameter for flash.sh when you are runnning initrd flash script, you can use -p to pass parameter.

Thank you for the elaboration.
I’ll try what we talked about and update here for others to use.

One last question please:
You know how can I configure UEFI to automatically fallback to another boot device in case of system boot failure on first device? (without me choosing it manually on startup)

if you want, i can open other thread for this.

You can refer to the UEFI source for details.

Currently, if the boot-device is unavailable to be loaded, it will switch to boot from the next boot device.
If the boot-device is loaded but boot up failed in kernel, it may trigger watchdog reset, but the bootloader would not know the boot failed in kernel.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.