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

[Rob Clark]

On Sun, Jun 25, 2017 at 1:16 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> 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?
>

because I want to be able to update dtb w/ 'dnf upgrade' (or equiv cmd
for other distros).. the alternative seems to be figuring out how (via
distro u-boot script) to find the most recent dtb, or constantly
requiring users to upgrade their firmware.  Neither of which sounds
appealing.

(the whole idea of a single static dtb for a SoC is nice in theory
until you realize that complex SoC's like snapdragon are still pushing
the boundaries of what we have figured out how to model in dt)

BR,
-R