> Am 25.07.2017 um 19:23 schrieb Rob Clark <robdcl...@gmail.com>: > >> On Tue, Jul 25, 2017 at 12:55 PM, Alexander Graf <ag...@suse.de> wrote: >> >> >>> On 25.07.17 17:47, Rob Clark wrote: >>> >>>> On Tue, Jul 25, 2017 at 10:25 AM, Alexander Graf <ag...@suse.de> wrote: >>>> >>>> >>>> >>>>> On 25.07.17 14:47, Rob Clark wrote: >>>>> >>>>> >>>>>> On Tue, Jul 25, 2017 at 5:38 AM, Alexander Graf <ag...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
