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

[Alexander Graf]

> Am 25.07.2017 um 19:23 schrieb Rob Clark <robdclark at gmail.com>:
> 
>> On Tue, Jul 25, 2017 at 12:55 PM, Alexander Graf <agraf at suse.de> wrote:
>> 
>> 
>>> On 25.07.17 17:47, Rob Clark wrote:
>>> 
>>>> On Tue, Jul 25, 2017 at 10:25 AM, Alexander Graf <agraf at suse.de> wrote:
>>>> 
>>>> 
>>>> 
>>>>> 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:
>>>>>> 
>>>>>> 
>>>>>> 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 :).
>>> 
>>> 
>>> I know recently on one board there were some issues because of the way
>>> host and otg usb were muxed (I'm not sure the details, I'm not a usb
>>> expert, nor do I have time to be), which at some point will require a
>>> non-backwards compatible dt change.  In the past it took a while to
>>> describe more complex display topologies with bridge chips.  There is
>>> still the yet unanswered question of how to handle interconnect/NoC
>>> bus scaling.  Probably other cases that don't come to mind offhand..
>>> I know downstream kernel has a lot of tricks for power saving which we
>>> haven't figured out how to do upstream yet.
>>> 
>>>>> 
>>>>> 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 ;).
>>>> 
>>> 
>>> I don't think we have an choice if we want to have cross-distro
>>> "firmware", since post-RTS variables aren't going to be possible on
>>> all devices, I don't think.  Otherwise I would have just stuck with my
>>> u-boot hack patch that loads \EFI\fedora\grubaa64.efi directly and not
>>> bothered with all this work ;-)
>>> 
>>> Anyways, it wouldn't really break you.. it would just change the logic
>>> above to not do the hack of installing as a live-media image that
>>> thinks it owns the whole disk.  And then we could install multiple
>>> distros on different partitions on the same disk (with the caveat of
>>> having to edit efivars.txt to change boot-order... possibly we could
>>> invent a u-boot script or bootorder.efi that shows a menu on screen if
>>> you boot with some key held down, similar to what you get on x86).
>> 
>> 
>> No, we either implement real EFI vars to Linux or none at all, but I don't
>> want to see us reinvent random non-UEFI standard ways of doing what people
>> expect it to do.
>> 
>> So while yes, before exit_boot_services I think we can expose efi variables,
>> I definitely don't want to see anything "fake" or "different from standard
>> UEFI" within Linux. And that only works with dedicated (or virtualized)
>> storage.
> 
> I wasn't planning to expose efi vars to linux (or anything post EBS).
> My rough plan was to persist all the env vars that start with efi_ in
> EBS while we still have u-boot drivers, to make them available on next
> boot, but *only* to shim/fallback/grub.. not post-EBS.
> 
> Like I said earlier, on devices without a proper way to do efi vars,
> you have to 'sudo vim /boot/efi/efivars.txt'

There shouldn't be efivars - the efi variables should get persisted through saveenv.

> instead of 'grub2-reboot
> 2', etc.

Yup, and that much sounds reasonable to me :). We have to be very careful to not create a special, parallel UEFI world with this though ;).

As an example: I can imagine that once this works, someone will send patches to grub to modify env.txt if it finds a u-boot uefi implementation. And then we by accident created a parallel universe where uefi lost its unification :/.


Alex