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' 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
