[U-Boot] [U-Boot,RFC] efi: variable support
xypron.glpk at gmx.de
Sun Jun 25 17:16:18 UTC 2017
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?
> 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.
More information about the U-Boot