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

[Rob Clark]

On Tue, Jul 25, 2017 at 5:38 AM, Alexander Graf <agraf at suse.de> wrote:
>
>
> On 19.07.17 18:38, Rob Clark wrote:
>>
>> 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's perfectly ok to mismodel things at first. Then the dt would simply
> contain the "old way" nodes as well as the "new way" ones.

sometimes, easier said than done

> Every time we find a case where this approach does not work, we need to ask
> ourselves why. And every time we should ideally find a solution so that next
> time we don't break backwards compatibility.
>
> One good example for that is all of the clock framework mess we have today.
> As a result of that, Andre started to push that logic into ATF and made
> Linux just call into it. Conveniently that also fixes issues with
>
>   a) partitioning hypervisors
>   b) trustzone controlling devices in the same clock domain as linux

snapdragon has the same issue, but also some clks and regulators, etc,
are also used by various other cores on the SoC (dsp's, etc).. for
those resources, they actually manage via an "rpm" core (resource
power mgr, iirc).

tbh, I think just going the UEFI+ACPI route would, I think, make it
much easier for qcom to upstream their firehose of rather complex
SoC's by abstracting a lot of the complexity below linux.  But not my
call.

> and I'm sure for other cases where we see it fail we will find solutions -
> at least if people care enough :).

I agree.. it's just a big task.  Which is why I said earlier that I'll
agree with your position in 5 yrs ;-)

>> 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)
>
>
> Well, the holy grail would be:
>
>   ATF generates DT
>   U-Boot uses that DT to configure itself
>   U-Boot passes the same DT on to Linux
>
> Of course you can cut the chain at any point. And we have to make sure that
> overrides are always easy enough.
>
>> 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 ;-)
>
>
> I agree :). We still want to have overriding mechanisms. And we do have them
> today. But the normal end user case should really not force them to have
> dtbs and kernels in lock-step.
>
> Take a look at all the server platforms out there. They do work with dtb
> just fine and most of them managed to keep backwards compatibility working.
> The 2 cases I'm aware of really boiled down to "don't care" attitudes and
> thus would've been avoidable.

The idealistic approach that you want is fine for servers and a bunch
of other simple industrial SoCs out there.. simply because they are so
much less complex.  I don't think it is as much of a "don't care"
attitude (at least not all of the time).. as much as a whole different
level of complexity in the SoC.  Trying to say that this approach
works for something like am33xx so it ought to work for anyone is just
misunderstanding the scope of the problem.


>>> 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)
>
>
> That's why I wanted to push these pieces into EL3, as there's no way anyone
> can make U-Boot drivers work properly with UEFI's dynamic relocation mess
> :).
>
> So if you want a "full uefi env" enabled platform, you'd have to steal a
> storage device completely into the secure world and only drive it from
> there. U-Boot would only call into EL3 to access that device and handle its
> own environment though it. Both in the boot time as well as the runtime
> case.
>
> It really gets tricky if you don't have any dedicated storage available.
> Then we would be able to expose variables in the boot time case, but not in
> the runtime one. And I'm not sure how hard that would confuse applications
> ...

I think for the immediate problem of making an installed OS partition
(as opposed to "live media") work, just having variables before we
exit runtime services is sufficient.  It means, for example, having to
edit efivars.txt instead of using grub2-reboot.. but ok, it's a pretty
big improvement over the current state.

Post runtime-services is definitely not part of the first patchset.

BR,
-R