This is why reference platforms make sense as the canonical example.
There's a clear mission to create / support U-Boot with the EFI extensions
defined by EBBR.
On Tue, 12 Jun 2018 at 19:55 Dong Wei <dong....@arm.com> wrote:
> - DW
> -----Original Message-----
> From: Olof Johansson <o...@lixom.net>
> Sent: Tuesday, June 12, 2018 10:58 AM
> To: Dong Wei <dong....@arm.com>
> Cc: David Rusling <david.rusl...@linaro.org>; wmi...@ti.com;
> email@example.com; arm.ebbr-discuss <
> Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device
> On Tue, Jun 12, 2018 at 10:16 AM, Dong Wei <dong....@arm.com> wrote:
> > There may be a need for making EBBR more aware to the community.
> > I ran into a case at Computex last week. Ambedded makes storage servers
> using Marvell SoCs. Even though Marvell provides UEFI code for the SoC,
> Ambedded chose to do the uboot anyways.
> I think a relevant distinction here is that if someone wants to still do
> u-boot, they should strongly consider using a version new enough to
> implement EBBR interfaces such as UEFI services. On price-sensitive devices
> where you want to optimize flash BOM cost, skipping Tianocore
> *can* have cost impact, but if the interfaces are kept compatible that
> should be just fine.
> As always, if the SoC vendor provides a reference implementation for their
> platforms such that doing the right thing is also doing the easiest thing
> when making a derivative product design, everybody wins.
> 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.
David A Rusling
boot-architecture mailing list