Driver model at UEFI runtime

[Heinrich Schuchardt]

On 9/9/21 10:00 PM, Simon Glass wrote:
> Hi Heinrich,
>
> On Thu, 9 Sept 2021 at 05:29, Heinrich Schuchardt <xypron.glpk at 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.
>>
>> 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?
>
> Not to dump on the original author but here again we are paying the
> price for the shortcuts taken at the time and not since revisited.
>
> My original request then was to create a new build of U-Boot, since we
> need to build (and load) the runtime stuff separately. Then we can

Do you mean by new build something like TPL, SPL?

Tom is right in complaining that the UEFI implementation is getting too
big for some boards. Duplicating a lot of binary code, e.g. the complete
libfdt or everything needed for UEFI variables, does not look a viable
option. The good thing about tagging functions as __efi_runtime is
minimizing binary code duplication.

It would be possible to leave the whole U-Boot binary in memory when
launching the operating system at the cost of loosing < 1MiB of RAM.
This could eliminate the __efi_runtime tagging.

The problematic stuff are the memory structures that we need to convey
between the boottime and the runtime. It is here where pointers need to
be updated. You cannot resolve this data side problem by duplicating code.

The first thing we should work on is an easily parsable structure
without pointers for conveying runtime device information.

Something like a concatenation of structures with

* length
* driver id
* private data

might be sufficient.

> avoid all this mess and just use the normal U-Boot code (and driver
> model). It also scales up to whatever else we want to do to the runtime
> stuff in the future.
>
> This will be somewhat easier with the VPL series applied, and even

VPL? Please, provide a link.

When thinking of which drivers are needed at runtime it is restricted to
the following:

* reset driver. Some like SBI can be blindly called at runtime because
   configuration tells us that there is an SBI. For others, e.g GPIO,
   we need information from the runtime devicetree. For others we may
   want the result of probing at boottime to avoid code duplication.

* tee driver: for managing variables at runtime it would be
   good to have access to non-volatile memory managed by the TEE.
   This has not been realized yet.

All devices that are managed by the operating system must not be touched
by the runtime firmware.

Best regards

Heinrich

> easier if we can make the different builds more easily configurable.
> TBD on that and Tom has suggested an approach with CONFIG options that
> should tidy things up.
>
> Of course the 'tools' builds solve this by copying/symlinking the C
> files into a different directory so they can be built again in a
> different context. I think that could get quite out of hand though. So
> I favour a separate build.
>
> Regards,
> Simon
>