Hi Abner,
Answers below...
On 27/04/2018 07:06, Chang, Abner (HPS SW/FW Technologist) wrote:
Not sure if this mail list works or not.
Hi Grant, GiIbert (from HPE, I think he is also in the mail list) and I are new to this discussion thread . Here are couple questions for you, your answer can give us the clear plan of EBBR spec.
- I see EBBR spec on ARM web site, however seems it was released in last Sep. Any newer version of this spec?
As Dong said, there is no newer version of the spec. The copy on the Arm website is only a draft release. The feedback we received on it was we need a more open process for this spec; hence this group.
- The purpose of EBBR is to standardize embedded system firmware on different processor archs and also intends abstract platform-specific implementations?
The purpose of EBBR is to standardize the firmware interface for different platforms of the same architecture so that OS distributions can support multiple boards. For example, the SUSE AArch64 image should be able to boot on any EBBR compliant AArch64 platform (providing the SoC is supported in the SUSE kernel).
Originally EBBR was only intended to address Arm platforms, but after receiving interest from other architectures we've expanded the scope.
EBBR builds on existing specs, so it doesn't define a new firmware interface. Rather, it starts with the UEFI spec and adds additional requirements that are relevant for the embedded market.
- EBBR aligns embedded SWF with UEFI spec (minimum requirements) and leverage EDK2 implementation on uBoot? 3-1 That is to use uBoot to initialize and boot system, but uBoot mimics UEFI protocols and EFI system table then boot to UEFI OS boot loader? 3-2 Or, Uboot could be one of EDK2 packages, wrap the necessary Uboot drivers into UEFI protocols (like the UEFI binding on top of uBoot) and build it using EDK2 build process then generate EDK2 format system firmware?
3-2 makes more sense to me but not sure which one is EBBR intention. I may have more question if the intention of EBBR is 3-2. :)
3-1 is the intent. EBBR specifies UEFI, but doesn't say anything about implementation. U-Boot implements a subset of the UEFI spec which is completely independed from EDK2/Tianocore. A vendor can produce an EBBR compliant system using either U-Boot or EDK2/Tianocore.
The first release of EBBR (level 0) will specify a subset of UEFI compliance. The intent is to reflect what is currently implemented in the U-Boot project. Therefore, a vendor who is currently using U-Boot firmware has an easy migration path to become EBBR compliant.
UEFI support in U-Boot is rapidly evolving, so I expect future revisions of EBBR (level 1 and onwards) to require a larger subset of UEFI, with the ultimate goal of being 100% compliant to the UEFI spec.
As you'll have gathered from the meeting, handling of persistent variables is an important topic right now. The UEFI spec requires the GetVariable()/SetVariable() runtime services to work, but U-Boot does not yet have the ability to set variables at runtime. Similarly, Tianocore/EDK2 on the 96Boards HiKey doesn't support setting variable at all. Therefore, EBBR needs to define the behaviour of firmware when SetVariable() does not work.
Cheers, g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.