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

[Rob Clark]

On Sun, Jun 25, 2017 at 5:07 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 06/25/2017 09:06 PM, Rob Clark wrote:
>> 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
>>
>
> Have a look at Debian/Ubuntu package flash-kernel.
>
> After installing a new kernel update-initramfs triggers flash-kernel.
> flash-kernel looks up the value provided by file
> /proc/device-tree/model
> in a database file to find the correct dtb and installs it in /boot. It
> further sets a symbolic link
> /boot/dtb
> to the dtb. So u-boot can simply load /boot/dtb and pass it to grub.

but this doesn't work if you want to be able to (for example) unplug a
disk from device A and plug it in to device B, does it?

> If static dtbs are not enough for your requirements look at device
> overlay trees.

I do have some interest in overlays, mostly because currently the
firmware generates psuedo-random eth/wifi/bt MAC addrs based on some
board specific info (like emmc part serial #, for example).. which we
currently loose out from if not using the qcom specific lk->kernel
boot chain.  But I guess that is a bit of a different topic.

BR,
-R