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

[Rob Clark]

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

BR,
-R