On 19.07.17 18:38, Rob Clark wrote:
On Wed, Jul 12, 2017 at 8:57 AM, Alexander Graf <ag...@suse.de> wrote:
On 25.06.17 00:29, Rob Clark wrote:
Mapping from EFI variables to grub variables. Still almost as many
TODOs as lines of code, but just figured I'd send out an early version
for comments.
I was thinking of it as a useful way for u-boot to pass values to grub
(although grub is still missing a way for grub scripts to retrieve
UEFI variables).
The rough idea is to encode GUID + variable name plus "efi_" prefix
(to avoid unintended u-boot variables leaking into the UEFI world).
And then encode the type (and attributes?) in the string value of the
variable. Ie. something like:
setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported
(u64)0
That's a pretty nice idea altogether, I agree. I don't think the goal you
have in mind is good though.
I don't really think we should ever allow grub to override the device tree
files - unless for development purposes. The reason we are in the dt mess we
are in today is because it's too easy. People associate device trees with
kernels, not hardware. That's just plain wrong: device trees describe
hardware, not Linux interfaces.
I kinda wish I could agree with you, but it breaks down quickly when
you start getting into more complex SoC's. There is enough that we
simply haven't figured out how to model properly in dt. 5yrs from now
I might agree with you ;-)
It's perfectly ok to mismodel things at first. Then the dt would simply
contain the "old way" nodes as well as the "new way" ones.
Every time we find a case where this approach does not work, we need to
ask ourselves why. And every time we should ideally find a solution so
that next time we don't break backwards compatibility.
One good example for that is all of the clock framework mess we have
today. As a result of that, Andre started to push that logic into ATF
and made Linux just call into it. Conveniently that also fixes issues with
a) partitioning hypervisors
b) trustzone controlling devices in the same clock domain as linux
and I'm sure for other cases where we see it fail we will find solutions
- at least if people care enough :).
It might mostly sorta work most of the time if u-boot finds the most
recent dtb (which at least in fedora would mean parsing all the
dtb-x.y.z directory names and figuring out which is newest)
Well, the holy grail would be:
ATF generates DT
U-Boot uses that DT to configure itself
U-Boot passes the same DT on to Linux
Of course you can cut the chain at any point. And we have to make sure
that overrides are always easy enough.
and btw, as someone who works on kernel to the "development purposes"
is an important use-case to me.. and generally it isn't a good idea
to make kernel developer's boot process significantly different from
end users, or you'll just end up in a state where things constantly
work for developers and are broken for distros ;-)
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.
As for real variable support (for example to boot using a native EFI boot
order), I think this approach can work. But before committing to a specific
path to take, I'd like to see a full solution that allows us to maintain
these variables consistently in runtime services too, as that's required for
the boot order.
persisting variables, especially after we exit boot-services will
be... interesting.
Rough idea is move env_htab into __efi_runtime_data and some simple
accessors into __efi_runtime. I think we'll need some board support
to saveenv after a variable is written. It seems tricky depending on
where the variables are stored (ie. if they are on same eMMC that
linux thinks it owns).
In some cases it might make sense for u-boot to own eMMC (and hide it
from linux) and keep grub and rest of distro media on sd-card /
usb-disk / etc. I'm not entirely sure how that would work from
kconfig option standpoint, and it would mean that we start adding
drivers and a bunch more in the efi_runtime section. (And then how to
deal w/ dynamically allocated memory, etc)
That's why I wanted to push these pieces into EL3, as there's no way
anyone can make U-Boot drivers work properly with UEFI's dynamic
relocation mess :).
So if you want a "full uefi env" enabled platform, you'd have to steal a
storage device completely into the secure world and only drive it from
there. U-Boot would only call into EL3 to access that device and handle
its own environment though it. Both in the boot time as well as the
runtime case.
It really gets tricky if you don't have any dedicated storage available.
Then we would be able to expose variables in the boot time case, but not
in the runtime one. And I'm not sure how hard that would confuse
applications ...
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
