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

[Rob Clark]

On Wed, Jul 12, 2017 at 8:57 AM, Alexander Graf <agraf at suse.de> wrote:
>
>
> On 25.06.17 00:29, 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
>
>
> That's a pretty nice idea altogether, I agree. I don't think the goal you
> have in mind is good though.
>
> I don't really think we should ever allow grub to override the device tree
> files - unless for development purposes. The reason we are in the dt mess we
> are in today is because it's too easy. People associate device trees with
> kernels, not hardware. That's just plain wrong: device trees describe
> hardware, not Linux interfaces.

I kinda wish I could agree with you, but it breaks down quickly when
you start getting into more complex SoC's.  There is enough that we
simply haven't figured out how to model properly in dt.  5yrs from now
I might agree with you ;-)

It might mostly sorta work most of the time if u-boot finds the most
recent dtb (which at least in fedora would mean parsing all the
dtb-x.y.z directory names and figuring out which is newest)

and btw, as someone who works on kernel to the "development purposes"
is an important use-case to me..  and generally it isn't a good idea
to make kernel developer's boot process significantly different from
end users, or you'll just end up in a state where things constantly
work for developers and are broken for distros ;-)

> As for real variable support (for example to boot using a native EFI boot
> order), I think this approach can work. But before committing to a specific
> path to take, I'd like to see a full solution that allows us to maintain
> these variables consistently in runtime services too, as that's required for
> the boot order.

persisting variables, especially after we exit boot-services will
be... interesting.

Rough idea is move env_htab into __efi_runtime_data and some simple
accessors into __efi_runtime.  I think we'll need some board support
to saveenv after a variable is written.  It seems tricky depending on
where the variables are stored (ie. if they are on same eMMC that
linux thinks it owns).

In some cases it might make sense for u-boot to own eMMC (and hide it
from linux) and keep grub and rest of distro media on sd-card /
usb-disk / etc.  I'm not entirely sure how that would work from
kconfig option standpoint, and it would mean that we start adding
drivers and a bunch more in the efi_runtime section.  (And then how to
deal w/ dynamically allocated memory, etc)

BR,
-R

> So far my thinking was that maybe we could push all u-boot variables into
> EL3. That way we could still call into the same space during Linux
> execution. However of course only if there is separate storage to put those
> variables into...
>
>
> Alex