On 25.07.17 14:47, Rob Clark wrote:
On Tue, Jul 25, 2017 at 5:38 AM, Alexander Graf <ag...@suse.de> wrote:
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.
sometimes, easier said than done
Yes, I know :).
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
snapdragon has the same issue, but also some clks and regulators, etc,
are also used by various other cores on the SoC (dsp's, etc).. for
those resources, they actually manage via an "rpm" core (resource
power mgr, iirc).
tbh, I think just going the UEFI+ACPI route would, I think, make it
much easier for qcom to upstream their firehose of rather complex
SoC's by abstracting a lot of the complexity below linux. But not my
call.
Well, the DT alternative to ACPI byte code are PSCI calls ;).
and I'm sure for other cases where we see it fail we will find solutions -
at least if people care enough :).
I agree.. it's just a big task. Which is why I said earlier that I'll
agree with your position in 5 yrs ;-)
So any time you come across such a situation, I'd love to hear back on
why it was hard. I'm just afraid that if nobody attacks the problems
that do arise, we will have the same statement again in 5 years :).
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.
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 :).
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
...
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 ;).
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
