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

Rob Clark robdclark at gmail.com
Tue Jul 25 17:23:34 UTC 2017


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' instead of 'grub2-reboot
2', etc.

BR,
-R

> 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


More information about the U-Boot mailing list