Understand now, thanks Dong, Daniel and Grant. That is the UEFI U-Boot port for
embedded system. edk2 is not the only implementation for UEFI on embedded
system segment.
Thanks
-Original Message-
From: Grant Likely [mailto:grant.lik...@arm.com]
Sent: Friday, April 27, 2018 6:03 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>
Cc: arm.ebbr-discuss <arm.ebbr-disc...@arm.com>;
boot-architecture@lists.linaro.org
Subject: Re: Question about EBBR
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
