On 4/9/19 3:49 AM, AKASHI Takahiro wrote:

On Mon, Apr 01, 2019 at 01:28:24AM +0700, Alexander Graf wrote:

...

On 28.03.19 14:11, Heinrich Schuchardt wrote:

...

Describe the target scope of the UEFI implementation in U-Boot.

Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de

doc/README.uefi | 11 +++++++++++ 1 file changed, 11 insertions(+)

diff --git a/doc/README.uefi b/doc/README.uefi index b38efbc0cc..66b6abece5 100644 --- a/doc/README.uefi +++ b/doc/README.uefi @@ -12,6 +12,15 @@ the interaction of drivers and applications with the firmware. The API comprises access to block storage, network, and console to name a few. The Linux kernel and boot loaders like GRUB or the FreeBSD loader can be executed.

+## Development target

+The implementation of UEFI in U-Boot strives to reach the minimum requirements +described in "Server Base Boot Requirements System Software on ARM Platforms - +Version 1.1" [4].

+A full blown UEFI implementation would contradict the U-Boot design principle +"keep it small".

I'm not sure we ever want to be fully SBBR compliant. We might be, but it's not been a goal so far. We do however want to be *EBBR* compliant.

@Alex: I did not receive your mail. I cannot find it on https://lists.denx.de/pipermail/u-boot/2019-April/date.html either. Please, resend if the citation above is incomplete.

If found the following additional requirements in SBBR relative to EBBR:

GOP protocol: direct access to framebuffer recommended

Address transalation support: Some PCI related protocols are required if PCI is supported.

UEFI Configuration Table Entries: EFI_ACPI_20_TABLE_GUID SMBIOS3_TABLE_GUID both with detailed requirements.

Required UEFI protocols: EFI_RNG_PROTOCOL

Optional UEFI protocols (so the ones we probably will not implement): EFI_REST_PROTOCOL

Recommended ACPI tables: see SBBR

So the main difference is on the ACPI and SMBIOS side.

Our implementation state is:

We provide EFI_ACPI_20_TABLE_GUID on x86. We provide SMBIOS_TABLE_GUID and not SMBIOS_TABLE3_GUID.

We do not provide PCI related protocols.

We do not provide the EFI_RNG_PROTOCOL nor the optional EFI_REST_PROTOCOL.

The EFI_RNG_PROTOCOL is used by the Linux kernel for randomizing the kernel layout. iPXE uses it for https connections. So I think it makes sense to implement the protocol.

I will create a patch to change our development target to EBBR and provide SBBR as additional reference.

The current U-Boot still lacks lots of EBBR features. Our 'minimum' set may be even much smaller than that.

I agree that we are still far from reaching EBBR compliance. But I hope using a reference document like EBBR as guidance helps use to stay focused.

I think our reference point should not be 'our minimum set' but what operating systems and other EFI payloads could reasonably expect. So we should refer to some industry standard.

EBBR is an active area of work:

https://github.com/ARM-software/ebbr https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

Best regards

Heinrich

-Takahiro Akashi

...

Alex

...

## Building for UEFI

The UEFI standard supports only little-endian systems. The UEFI support can be @@ -335,3 +344,5 @@ This driver is only available if U-Boot is configured with http://uefi.org/specifications - UEFI specifications

• [2](./driver-model/README.txt) doc/driver-model/README.txt - Driver model
• [3](./README.iscsi) doc/README.iscsi - iSCSI booting with U-Boot and iPXE

+* [4](https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-...)

• Server Base Boot Requirements System Software on ARM Platforms - Version 1.1

-- 2.20.1