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

[Heinrich Schuchardt]

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.

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

Best regards

Heinrich Schuchardt