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

Tue Jul 25 14:25:29 UTC 2017

On 25.07.17 14:47, Rob Clark wrote:
> 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

Yes, I know :).

> 
>> 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.
Well, the DT alternative to ACPI byte code are PSCI calls ;).

>> 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 ;-)

So any time you come across such a situation, I'd love to hear back on 
why it was hard. I'm just afraid that if nobody attacks the problems 
that do arise, we will have the same statement again in 5 years :).

> 
>>> 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.

Yes, as I mentioned above, I want to learn about all the cases where it 
went wrong, take a step back and figure out why it was impossible to 
stay compatible.

Maybe the end result of that will be to dispair and rip all my hair out. 
But maybe we will find ways to ease the pain next time :).

>>>> 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.

Well, it wouldn't be efivars but just the already existing bootenv which 
can also already be stored in .txt format on SD card ;).

Also, openSUSE has special support for non-efi-var booting. It detects 
that there is no efi var support and in that case simply installs grub 
with --removable --no-nvram. That way booting "just works" for the 
default case that basically everyone cares about.

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

So yeah, maybe this can work. I definitely don't want to expose any sort 
of fake RTS variable services, as that would break the logic above ;).

Alex