On Thu, 30 Sept 2021 at 09:38, Bin Meng <bmeng...@gmail.com> wrote: > > On Thu, Sep 30, 2021 at 2:23 PM François Ozog <francois.o...@linaro.org> > wrote: >> >> >> >> Le jeu. 30 sept. 2021 à 07:12, Bin Meng <bmeng...@gmail.com> a écrit : >>> >>> Hi Heinrich, >>> >>> On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt <xypron.g...@gmx.de> >>> wrote: >>> > >>> > Hello Simon, >>> > >>> > The EBBR specification requires that the UEFI SystemReset() runtime >>> > service is available to the operating system. >>> > >>> > Up to now this has been implemented by overriding function >>> > efi_reset_system() which is marked as __efi_runtime. >>> > >>> > Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM >>> > and the System Reset Extension for SBI on RISC-V. This has kept the >>> > number of implementations low. The only exceptions are: >>> > >>> > * arch/arm/cpu/armv8/fsl-layerscape/cpu.c >>> > * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs >>> > * arch/sandbox/cpu/start.c >>> > >>> > Bin has suggested in >>> > https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use >>> > reset drivers based on the driver model. >>> > >>> > Currently after ExitBootServices() the driver model does not exist >>> > anymore. >>> > >>> > When evaluating Bin's suggestion one has to keep in mind that after >>> > invoking ExitBootServices() most operating systems call >>> > SetVirtualAddressMap(). Due to the change of the address map all >>> > pointers used by U-Boot afterwards must be updated to match the new >>> > memory map. >>> > >>> >>> Yeah, this was discussed 3 years ago: >>> https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken >>> >>> > The impression that Ilias and I have is that keeping the driver model >>> > alive after SetVirtualAddressMap() would incur: >>> > >>> > * a high development effort >>> > * a significant code size increase >>> > * an enlarged attack surface >>> > >>> > For RISC-V it has been clarified in the platform specification that the >>> > SBI must implement the system reset extension. For ARMv8 using TF-A and >>> > PSCI is what ARM suggests. >>> > >>> > So for these architectures we do not expect a growth in the number of >>> > drivers needed. >>> > >>> > Ilias and my favorite would be keeping the design as is. >>> > >>> > What is your view on this? >>> >>> Is U-Boot's UEFI loader implementation supposed to be the recommended >>> UEFI firmware on ARM and RISC-V on a production / deployment system? >> >> For Arm: yes, that is SystemReady spec. > > > How about EDK II? Is EDK II supposed to be used in the server environment > where UEFI + ACPI is the way to go? >
Yes ACPI pretty much means EDK2. Specifically for Arm SystemReady-ES/SR (embedded server ready and server ready), require ACPI. Boards passing that certification today use EDK2. > Does any board that ships EDK II with UEFI + DTB? The Socionext SynQuacer box is the only board I know off, that works with EDK2 and can use either DT or ACPI. > Can we safely assume that U-Boot's UEFI loader is the reference > implementation for UEFI + DTB on Arm? There's even more to that. EDK2 is bound to the PI spec as well as the UEFI spec. U-Boot is a UEFI implementation that doesn't need to adhere to that. Regards /Ilias >>> >>> >>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we >>> expect to load grub.efi which chain-loads a kernel without >>> CONFIG_EFI_STUB? >> >> all paths should be possible , and the shim.efi is to be supported too. With >> UEFI, I always see that UEFI is kept down to OS for SecureBoot. In other >> words I don’t see grub.efi booting a non config_efi_stub. >>> >>> What do distributions normally do? >> >> At least Red Hat made it clear at multiple Linaro Connect that they want >> standards, and SystemReady is one that makes the life of embedded distros >> easy. >> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot. >>> >>> What's our >>> position when compared to EDK II? >> >> the typical distro boot flow is not the most efficient and drags concept >> dating where the Microsoft certs had to be part of the picture. A direct >> U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path >> (grub), avoids convoluted platform cert management (shim) and just enhance >> security and boot time. Note: Since kernel 5.10, initrd can be measured >> (with TPM) when loaded by efi-stub. > > > Regards, > Bin