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 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
