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

[Rob Clark]

On Tue, Jul 25, 2017 at 1:29 PM, Alexander Graf <agraf at suse.de> wrote:
>
>
>> 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.

hmm, possibly.. that would be simpler.. I had mainly wanted to
separate efi and u-boot state, but I think I could go either way on
that.

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

btw, I realized I think some of the confusion was my fault.. I
probably had previously mentioned the possible 2nd step of moving some
of env block into efi_runtime section to make read-only efi variables
available to linux.. but without mentioning that I have no immediate
plans to actually implement that (and I can't really think of a reason
that would be useful).  (If there *was* a use-case for that, I think
the opensuse installer could detect that by trying to *write* an efi
var, I guess.. but really my main interest right now is to have efi
vars for pre-EBS).

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

grub is pre-EBS so it can just use the normal UEFI interfaces.  If you
do see such a patch, pls NAK it ;-)

BR,
-R