What does the Cboot of Jetson agx orin means? how does UEFI replace cboot?

[japhaeching]

hi friends, im studing the jetson agx orin boot flow, i was confused when i read “UEFI replaces CBoot in the Jetson boot flow as the CPUBL for Jetson Linux devices”.

in my impression, cboot is the cold boot which is a boot type instead of a stage of bootflow like UEFI. furthermore, whats the connection between UEFI and CPUBL? do they represent the same stage?

who can solve me the mystery?

[WayneWWW]

Hi,

Cboot is a software binary name for our bootloader software. It is not “cold boot”.

The role of it got replaced by UEFI in rel-35.1.

[japhaeching]

@WayneWWW

t

thinks, what is the full name of Cboot?

And I wonder the connection between UEFI and CPUBL, is UEFI the CPUBL? can you give me a futher guidance?

[WayneWWW]

There is no full name of it… just cboot.

Yes, UEFI is the CPUBL.

[linuxdev]

I have seen it presented as “CPU Boot” (unofficially). Personally, I like to think of bring-up of clocks and power rails (the Boot Power Management Processor, BPMP) and old CBoot as what would be in the BIOS of a PC (but there is no BIOS, so it is done in software). UEFI is a wonderful abstraction too, and the “equivalent” of the BPMP and CBoot would be something private, adapting to a uniform specification, and handed to a bootloader which is more or less a standardized object since the hardware and firmware are abstracted by those earlier stages. It’s boot beginning to become more object-oriented.

[japhaeching]

Whether the cboot is completely replaced with UEFI? or partially replaced?

[japhaeching]

Can’t agree with you more!

But I still don’t understand the role of uefi in boot flow, and whether some later boot stages exist after uefi?

In other words, is the Cboot replaced completely or partially with uefi?

[WayneWWW]

The next stage of UEFI is linux kernel.

Whether the cboot is completely replaced with UEFI? or partially replaced?

Completed replaced.

[linuxdev]

CBoot is being removed. There are public documents on UEFI design. See:
https://forums.developer.nvidia.com/t/jetson-agx-orin-uefi-test/232846/2

UEFI can be complicated, but here are some points about this:

• Normally a PC would have a BIOS. That BIOS is in a way a hardware abstraction that allows some of the hardware to be abstracted. Individual designers of operating systems don’t need to know how to bring up clocks and power rails, so on.
• Even a PC will have migrated to UEFI. I (and many people) still call it a “BIOS”, but in reality a motherboard which understands only UEFI and not legacy BIOS no longer has a BIOS: It is UEFI.
• UEFI is the ultimate abstraction of firmware and hardware, with a published and standardized API for people designing bootloaders. Once firmware and hardware is set up with custom software, one can put any UEFI compliant bootloader in using standard API calls.
• MB1, MB2, and CBoot are what a past Jetson used for getting to the point of a bootloader. Originally, CBoot itself ran U-Boot, and U-Boot was the bootloader. MB1, MB2, and parts of CBoot were the equivalent of the BIOS.
• Eventually, CBoot absorbed some of the U-Boot functionality and U-Boot went away. At this point CBoot more or less became a “hybridized” BIOS+bootloader and not just BIOS-style setup before the bootloader. This took lots of customization.
• UEFI replaces all of that. Technically, the bootloader itself is not part of UEFI. However, because a bootloader uses a standardized API for a given UEFI specification, it is modular, and one could pick any bootloader which works with that API. NVIDIA has theirs, but it could be GRUB2.
• Once the bootloader itself runs, it’s job is basically to overwrite itself with the operating system kernel. In order to do this the filesystem must be readable by the bootloader. The NVIDIA bootloader (and GRUB2) will natively understand ext4. Additionally, the NVIDIA version understands signed partitions, and security modes can be enabled in earlier stages and the bootloader (if it understands this) can securely verify various media before continuing boot (security starts in earlier stages though).
• If the filesystem type is not ext4, then in general the initrd initial ramdisk needs to be used. This is itself a cpio archive filesystem, which runs entirely in RAM, and which all Linux bootloaders understand. Any kernel modules needed for reading non-ext4 filesystem can be within the initrd before performing a pivot_root to the actual hard drive (note that this applies to reading some alternate boot devices as well, e.g., drivers for reading an NVMe, if not present in the bootloader, and not present in a default kernel, can be added in an initrd as an “adapter”).

In the documents in the URL you would find the most use in the parts which describe the standardized API for the bootloader itself. Consider CBoot gone, and hardware abstraction layers not needing customization unless it is something unusual.