Am 25.07.2017 um 19:23 schrieb Rob Clark robdclark@gmail.com:
On Tue, Jul 25, 2017 at 12:55 PM, Alexander Graf agraf@suse.de wrote:
On 25.07.17 17:47, Rob Clark wrote:
On Tue, Jul 25, 2017 at 10:25 AM, Alexander Graf agraf@suse.de wrote:
On 25.07.17 14:47, Rob Clark wrote:
On Tue, Jul 25, 2017 at 5:38 AM, Alexander Graf agraf@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