Is there documentation somewhere to help folks develop their own UEFI/EBBR/SBBR to get rid of U-Boot?

poddigue,

With the help of our resident expert and Arm Fellow, I was able to get quite a bit of information to answer your question(s). I hope this helps! 

>> I have not yet understood what "Arm Server Ready" means and what are its main advantages, but it looks like it is tightly linked to UEFI/SBBR.

The detailed information on Arm ServerReady is at https://developer.arm.com/architectures/platform-design/server-systems. It is a compliance program that provides a solution for servers that “just works”, allowing partners to deploy Arm servers with confidence. The program is based on industry standards and the Server Base System Architecture (SBSA) and Server Base Boot Requirement (SBBR) specifications, alongside Arm’s Server Architectural Compliance Suite (ACS).  Arm ServerReady ensures that Arm-based servers work out-of-the-box, offering seamless interoperability with standard operating systems, hypervisors, and software. SBBR provides the minimum firmware requires based on the UEFI, ACPI and SMBIOS interfaces.

>> I have seen that some people were trying to create UEFI for the Raspberry Pi, so there must be a good incentive to do so.

Yes. Generic off-the-shelf operating systems and hypervisors typically expect standard firmware interfaces to be provided. This is critical in the horizontal integration market. For example, VMware is very interested in seeing ESXi running on edge devices based on Arm SoCs. VMware expects UEFI and ACPI interfaces. Therefore there are members in the community actively developing UEFI and ACPI based firmware for the Raspberry Pi. Please refer to https://rpi4-uefi.dev/. The goal is to make Pi as close to “ServerReady” as possible for these generic OSes. More resources are at

• Community driven collaboration (including VMware, Arm, and others in the community)
  • EDK2 up-stream: https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/
  • Discord community channel: #rpi4-uefi-dev (https://discord.gg/H5ETM7C)

>> Sometimes, U-Boot is seen as tinkering and not as a robust system, so it's maybe time to shift to UEFI/SBBR. I have quite a few 64 bits boards, and even if it looks >> like a daunting tasks, where should I start if I ever felt like doing it? Would anyone have a few hints, a documentation, or at least a few pointers so that I can better understand the whole ecosystem?

See the above Raspberry Pi example. If you need any help, use the Discord community channel to discuss with the experts there. In addition, you can also put UEFI ABI on top of U-Boot to realize some of the benefits such as UEFI Secure Boot and firmware update. U-boot community already supports that. This would allow standard OS bootloader such as GRUB to load and boot Linux OSes. See  https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/uefi/uefi.rst

Thanks!

poddigue,

With the help of our resident expert and Arm Fellow, I was able to get quite a bit of information to answer your question(s). I hope this helps! 

>> I have not yet understood what "Arm Server Ready" means and what are its main advantages, but it looks like it is tightly linked to UEFI/SBBR.

The detailed information on Arm ServerReady is at https://developer.arm.com/architectures/platform-design/server-systems. It is a compliance program that provides a solution for servers that “just works”, allowing partners to deploy Arm servers with confidence. The program is based on industry standards and the Server Base System Architecture (SBSA) and Server Base Boot Requirement (SBBR) specifications, alongside Arm’s Server Architectural Compliance Suite (ACS).  Arm ServerReady ensures that Arm-based servers work out-of-the-box, offering seamless interoperability with standard operating systems, hypervisors, and software. SBBR provides the minimum firmware requires based on the UEFI, ACPI and SMBIOS interfaces.

>> I have seen that some people were trying to create UEFI for the Raspberry Pi, so there must be a good incentive to do so.

Yes. Generic off-the-shelf operating systems and hypervisors typically expect standard firmware interfaces to be provided. This is critical in the horizontal integration market. For example, VMware is very interested in seeing ESXi running on edge devices based on Arm SoCs. VMware expects UEFI and ACPI interfaces. Therefore there are members in the community actively developing UEFI and ACPI based firmware for the Raspberry Pi. Please refer to https://rpi4-uefi.dev/. The goal is to make Pi as close to “ServerReady” as possible for these generic OSes. More resources are at

• Community driven collaboration (including VMware, Arm, and others in the community)
  • EDK2 up-stream: https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/
  • Discord community channel: #rpi4-uefi-dev (https://discord.gg/H5ETM7C)

>> Sometimes, U-Boot is seen as tinkering and not as a robust system, so it's maybe time to shift to UEFI/SBBR. I have quite a few 64 bits boards, and even if it looks >> like a daunting tasks, where should I start if I ever felt like doing it? Would anyone have a few hints, a documentation, or at least a few pointers so that I can better understand the whole ecosystem?

See the above Raspberry Pi example. If you need any help, use the Discord community channel to discuss with the experts there. In addition, you can also put UEFI ABI on top of U-Boot to realize some of the benefits such as UEFI Secure Boot and firmware update. U-boot community already supports that. This would allow standard OS bootloader such as GRUB to load and boot Linux OSes. See  https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/uefi/uefi.rst

Thanks!