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.
1. 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.
2. 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.
3. 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.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
