On Tue, Jul 25, 2017 at 1:29 PM, Alexander Graf <ag...@suse.de> wrote: > > >> 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.
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
