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

[Heinrich Schuchardt]

On 06/25/2017 02:12 PM, Rob Clark wrote:
> 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.

The dtb is passed to EFI in memory (2nd parameter of bootefi).
So why should grub need the dtb name?

Regards

Heinrich

>  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
>