[U-Boot] [U-Boot,RFC] efi: variable support

[Rob Clark]

On Sun, Jun 25, 2017 at 1:06 AM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 06/25/2017 12:29 AM, Rob Clark wrote:
>> Mapping from EFI variables to grub variables.  Still almost as many
>> TODOs as lines of code, but just figured I'd send out an early version
>> for comments.
>>
>> I was thinking of it as a useful way for u-boot to pass values to grub
>> (although grub is still missing a way for grub scripts to retrieve
>> UEFI variables).
>>
>> The rough idea is to encode GUID + variable name plus "efi_" prefix
>> (to avoid unintended u-boot variables leaking into the UEFI world).
>> And then encode the type (and attributes?) in the string value of the
>> variable.  Ie. something like:
>>
>>   setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported (u64)0
>
> Hello Rob,
>
> thank you for your effort for a first implementation of EFI variables.
>
>
> The UEFI variable runtime services consists of the following functions:
> GetVariable, GetNextVariableName, SetVariable, QueryVariableInfo.
>
> SetVariable is meant to persistently store variables. The value has to
> be maintained across reboots.
>
> A variable consists of a variable name, a vendor GUID, an attribute
> bitmask and the variable value.
>
> SetVariable has to support appending to the value.
>
> The UEFI spec also defines some global variables marked by the
> EFI_GLOBAL_VARIABLE GUID.
>
>
> Grub uses UEFI variables to store boot entries for GPT disks.
>
> To do so it requires that the EFI runtime services are available after
> Linux is booted.

This is somewhat more ambitious than what I had in mind, at least for
the first step or two.  By the time linux is loaded, most of u-boot
has disappeared from memory, so currently there is very little it can
provide as far as runtime services.  (I was thinking read-only access
to variables might be possible as a 2nd step.)

otoh, at least for systems that have 1+gb of RAM, u-boot is relatively
tiny, so a build option to keep all of u-boot in RAM after boot might
be a way to approach this.

> So my conclusion is that it would be valuable to implement the EFI
> variable services. This implementation has to include a persistent
> store. The runtime service has to be available after Linux boot.

It would be nice, and it'd make u-boots implementation
(approximation?) of EFI somewhat more complete, for sure.

> If we want to manipulate variables from U-Boot we would need two new
> commands to set and get EFI variable names, GUIDs, attributes, and values.

hmm.. the approach of encoding GUID in variable name and attributes as
part of the string value would mean normal getenv/setenv is all we
need.  This seemed like a more natural approach to me.

> Could you, please, provide your use case for manipulating EFI variables
> from U-Boot.
>
> One use case I could think of is to let Linux write the dtb name into an
> EFI variable and let U-Boot read this EFI variable to decide which dtb
> file to load.

I was kinda thinking in the opposite direction, for u-boot to expose
dtb name to grub.  Also it would be nice for debugging if initial
value of grub's debug env var could be read from EFI.  For both these
cases, read-only access and no runtime access would be sufficient.
And from an implementation standpoint, that seemed like a reasonable
first goal.

BR,
-R