Want to learn more about the Jetson A/B slot redundancy

[Sprite]

Hello！
after read the document
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/AR/BootArchitecture/JetsonOrinSeriesBootFlow.html
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Bootloader/UpdateAndRedundancy.html
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/RootFileSystem.html#root-file-system-redundancy

i want to know:

1. When the bootloader components(BR-BCT、PSCBL1、MB1…) are updated, they are packed into the Bootloader Update Payload (BUP) and then the UEFI Capsule payload. But how are they writen into the eMMC or NVMe disk when we flash the board for the first time? If i didn’t get this wrong, they shoud be in the “esp” partition in the flash_l4t_nvme.mxl kind of files, right?
2. I want to collect logs from the bootloader. In “sample-boot-log” section it says: “The message displayed from MB1 is available from an MB1 debug build that has messages enabled. Messages from MB2 are always available.” But i don’t know anything about building the MB1…
3. In “Rootfs Selection” section: “If the current rootfs fails to boot a specified number of times, cpu-bootloader marks its Status attribute and switches the roles of the current and unused rootfs slots.” Where can i find more material about the cpu-bootloader?
   And, in the " Partition Selection" section about bootloader redundancy: " If a bootable slot fails to boot, Bootloader sets its status attribute as unbootable and switches the roles of the current and unused slots." Which part of the bootloader is doing this judgment job? Where can i find more details about it ?
4. We use the flash_l4t_nvme_rootfs_ab.xml kind of file to define the the partition layout for a redundant file systems. And then we use something like
   $ sudo ROOTFS_AB=1 ROOTFS_RETRY_COUNT_MAX=1 ./flash.sh jetson-agx-orin-devkit mmcblk0p1
   to flash TWO rootfs into ONE storage device. So my question is: what if i want to flash TWO rootfs into TWO NVMe disk(In order to maintain reliability in the event of possible damage to the storage device)? Should i start with learning the flash.sh script?
   Thanks a lot!

[KevinFFF]

Hi Sprite,

@Sprite

But how are they writen into the eMMC or NVMe disk when we flash the board for the first time? If i didn’t get this wrong, they shoud be in the “esp” partition in the flash_l4t_nvme.mxl kind of files, right?

They are stored in QSPI rather than eMMC or NVMe so that you have to check flash_t234_qspi.xml for details.

@Sprite

I want to collect logs from the bootloader.

You can just check serial console log for them.

@Sprite

Where can i find more material about the cpu-bootloader?

It is UEFI we used as bootloader from R35.

@Sprite

Which part of the bootloader is doing this judgment job? Where can i find more details about it ?

They are stored in efi variable.

@Sprite

$ sudo ROOTFS_AB=1 ROOTFS_RETRY_COUNT_MAX=1 ./flash.sh jetson-agx-orin-devkit mmcblk0p1

Are you using Orin Nano or AGX Orin?
What’s the Jetpack version in use?

@Sprite

So my question is: what if i want to flash TWO rootfs into TWO NVMe disk(In order to maintain reliability in the event of possible damage to the storage device)? Should i start with learning the flash.sh script?

Yes, you have to customize the flash script if you want to use different system image for 2 rootfs partitions.

[Sprite]

Hi KevinFFF, thank a lot!

@KevinFFF

They are stored in QSPI rather than eMMC or NVMe so that you have to check flash_t234_qspi.xml for details.

got it!

@KevinFFF

You can just check serial console log for them.

Whenever a bootable slot fails to boot, i can find the information in the serial console log, and i do not need to worry about the “MB1 debug” thing, is that right?

@KevinFFF

It is UEFI we used as bootloader from R35.

As far as i know, UEFI is a standard. What i am looking for is the software tool you use as the “cpu-bootloader”.

@KevinFFF

They are stored in efi variable.

Do you mean “EFI System Resource Table”？ As metioned above, what i would like to know is: which part of code is do this “boot fail counting” and “A/B slot switching” job?
If it is something open source, maybe i can do some modification to this A/B redundancy mechanism.
If it is not open source, please let me know too.

Thanks again~

[Sprite]

Please……

[KevinFFF]

@Sprite

Whenever a bootable slot fails to boot, i can find the information in the serial console log, and i do not need to worry about the “MB1 debug” thing, is that right?

Sorry that I’m not clear about what do you mean here.
You can refer to Jetson AGX Orin, Orin NX and Orin Nano Boot Flow — NVIDIA Jetson Linux Developer Guide 1 documentation for the boot flow on Orin Nano.
There should be some logs showing in serial console log for each boot stage.

@Sprite

What i am looking for is the software tool you use as the “cpu-bootloader”.

Do you mean how do we build the UEFI binary and its source?
If so, please refer to GitHub - NVIDIA/edk2-nvidia: NVIDIA EDK2 platform support for details.

@Sprite

Do you mean “EFI System Resource Table”？ As metioned above, what i would like to know is: which part of code is do this “boot fail counting” and “A/B slot switching” job?

L4TLauncher
If you want to know its mechanism, you can refer to the following thread.
Reset Timing of Boot Retry Count - #7 by KevinFFF

[Sprite]

OK，Thank you！