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? 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? What do distributions normally do? What's our position when compared to EDK II? Regards, Bin
