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

[Alexander Graf]

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 can understand that it feels appealing to only have a small hack in 
Linux to get the full UEFI greatness, but I really believe we should 
either stick to the spec or not expose functionality at all. Anything in 
between will result in terrible divergence, breakage and means we're 
still not compliant - which goes against the whole idea.

Of course if instead you're interested to change the UEFI spec to 
standardize an alternative mechanism for variable storage, I'm all ears :).


Alex