On 10/21/23 17:42, Simon Glass wrote:
Hi Tom,
On Fri, 20 Oct 2023 at 09:24, Tom Rini <tr...@konsulko.com> wrote:
On Fri, Oct 20, 2023 at 05:40:03PM +0200, Heinrich Schuchardt wrote:
On 20.10.23 15:21, Simon Glass wrote:
+Doug Anderson
Hi Heinrich,
On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
On 19.10.23 15:55, Simon Glass wrote:
Hi Heinrich,
On Wed, 18 Oct 2023 at 02:15, Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
On 10/18/23 05:33, Simon Glass wrote:
Hi Heinrich,
On Tue, 17 Oct 2023 at 07:50, Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
Forward and backward compatibility of Linux kernel device-trees is
sometimes missing. One solution approach is to load a kernel specific
device-tree. This can either be done via a U-Boot scripts (like the one
generated by Debian package flash-kernel or by a boot loader like GRUB.
The boot loader approach currently requires to know the device-tree name
before first boot which makes it unusable for generic images.
Expose the device-tree file name as EFI variable FdtFile.
This will allow bootloaders to load a kernel specific device-tree.
The variable will not be exposed on ACPI based systems or if the
environment variable fdtfile is not defined.
Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
---
v2:
Use a unique GUID to enable future U-Boot independent
standardization.
Do not try to add the variable on ACPI based systems.
---
include/efi_loader.h | 5 +++++
lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+)
I was too slow to reply to v1.
Does grub load the DT? I was assuming that U-Boot would pass it on?
What is the interface between U-Boot and grub?
The device-tree built into U-Boot is often out of date and not usable to
boot current Linux. A single device-tree can be loaded by U-Boot from
file and passed on as EFI configuration table. This device-tree may not
be compatible with all kernel versions exposed by GRUB.
GRUB provides a devicetree command. It is disabled if you use secure
boot. At least in Debian and Ubuntu GRUB invokes the
EFI_DT_FIXUP_PROTOCOL exposed by U-Boot to run U-Boot's device-tree
fix-ups after loading a device-tree.
Vendor scripts for GRUB like Ubuntu's /etc/grub.d/10_linux add
devicetree commands to the boot options in grub.cfg.
Thanks. I wonder if you could document this somewhere? It seems like
there are a lot of options and it is quite complicated.
Back to the question, I suppose you are expecting grub to load the DT
using this filename? But why doesn't U-Boot load it instead? It seems
very convoluted.
A separate file of this name exists for every kernel version installed.
The loaded dtb must match the kernel. U-Boot does not know what kernel
version will be chosen in GRUB. And for a generic image GRUB does not
what board it is on.
Also, can we test this interface?
Neither the sandbox nor QEMU have environment variable fdtfile. And we
don't create the EFI variable with ACPI as used on the sandbox.
I worry that this is creating another interface that some poor sod is
going to have to deal with in the future. Is this part of the EFI
standard?
No, the UEFI standard does not care much about device-trees. It only defines
the GUID for the configuration table.
We should really be using the compatible string to choose the
devicetree. Why are we using filenames at all? What is the
relationship between the compatible string and the filename? Is there
a lookup table, or should we create one?
There is no 1:1 relationship between compatible string and filename, e.g.
the following arm64 device-trees use the same compatible string:
amd/amd-overdrive-rev-b0.dts
amd/amd-overdrive-rev-b1.dts
amlogic/meson-axg-jethome-jethub-j110-rev-2.dts
amlogic/meson-axg-jethome-jethub-j110-rev-3.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts
The correct way of doing this is implemented in U-Boot with
CONFIG_FIT_BEST_MATCH.
Why should we write complicated code to find a *possibly* matching file if
we already know the filename that needs to be loaded?
I think that is the unfortunate key here. We can make a guess, or best
match, but it might not be right. And we need a reliable way to find and
use the correct tree. And the U-Boot portion of that may be "set the EFI
var if it's not already set" rather than "and now load it".
That is not my understanding of how it works. The compatible string is
how Linux knows what the hardware is...if it doesn't match, then
things are going to go wrong. It is also how U-Boot works, e.g. with
FIT. I don't believe this is a 'guess'. The compatible string is used
programmatically and must be correct.
It is not how U-Boot works. In distroboot U-Boot uses environment
variable fdtfile to load the correct device-tree.
Your suggestion would mean that distroboot or GRUB would have to sift
through literally hundreds of device-tree files which would considerably
increase the boot time. The process might end up with multiple dtb files
that match.
fdt_node_check_compatible() does most of the work...then you need to
check which FDT has the most specific match (i.e. latest in the string
list). That handles things like board revisions, variants, etc.
My concern is about adding a feature when there is already a defined
spec and mechanism for this to work. What happens when we load the
file and the compatible is wrong?
At best, I see the filename as a hint.
[Perhaps this is the wrong time to ask, but why are kernels +DT not
shipped in FIT on ARM?]
FIT is U-Boot specific. For Linux distributions it is easier to use a
firmware agnostic method of booting.
Can we mirror something like that in grub, etc?
I'm splitting this part out because no, having to have N projects write
the same bit of code, but with its own quirks and bugs doesn't sound
like the right direction. It's why today we have a few different sets of
logic to try and find / set the right device tree, so that whatever
follows after doesn't have to also do that, and get updated for every
new platform too.
And of course yes, ideally, boards would be manufactured with an up to
date and correct device tree on them.
OK, well I perhaps have the wrong end of the stick here.
As I learn more about how distros boot I see a great need for
information about what is actually being booted. For example, the
current 'bootflow menu' mostly shows useless information when EFI is
used to boot, since it doesn't know what the things are. We have to
jump to grub (or whatever) to find out. Grub knows because the OS set
up a grub menu.
The menu should show the EFI boot options. Then you can decide which of
the multiple operating systems on your device you want to boot.
The bottleneck is secure boot. As Red Hat did not want Microsoft to sign
every single kernel they came up with shim. Now we can only have one EFI
boot option per operating system. It is only after shim that you can
load one of multiple kernels.
Really we need to see this standard boot thing to the end. Each OS
should provide information from /etc/lsb_release as well as info from
menu.grub (sorry can't remember the right name), so that we know what
/boot/grub/grub.cfg
can be booted. Having to jump to an OS-specific bootloader to even be
able to show a menu is a pretty poor show.
With secure-boot you still would need to load the OS specific shim.
Further you would need a means to communicate your decision to whatever
program loads the kernel.
Anyway I think I understand why this variable is needed. Please add
some documentation on all this.
Yes I should add a paragraph on the variable.
My main concern is whether this sort of thing is going to make it even
harder to boot in a simple, standard manner.
Re Heinrich's comment:
There is no 1:1 relationship between compatible string and filename,
e.g. the following arm64 device-trees use the same compatible string:
amd/amd-overdrive-rev-b0.dts
amd/amd-overdrive-rev-b1.dts
That just seems like a bug to me. The compatible should include the
board rev as it does for xlnx,zynqmp-zcu102-rev1.1 etc.
Yes, here it is a bug.
In theory you could have different device-trees for different device
configurations (e.g. USB OTG vs USB host). In this case having the same
compatible string would be correct.
Best regards
Heinrich
Regards,
Simon
