[adding Vladimir, because he showed interest in this, too]
Am 2021-09-30 15:56, schrieb François Ozog:
On Thu, 30 Sept 2021 at 14:07, Michael Walle <mich...@walle.cc> wrote:
Am 2021-09-30 12:50, schrieb Heinrich Schuchardt:
Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle
<mich...@walle.cc>:
Am 2021-09-30 08:56, schrieb Heinrich Schuchardt:
On 9/30/21 8:23 AM, François Ozog wrote:
[..]
Is U-Boot's UEFI loader implementation supposed to be the
recommended
UEFI firmware on ARM and RISC-V on a production /
deployment
system?
For Arm: yes, that is SystemReady spec.
For RISC-V it is required by the RISC-V platform specification.
Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB,
or
do
we
expect to load grub.efi which chain-loads a kernel without
CONFIG_EFI_STUB?
all paths should be possible , and the shim.efi is to be
supported
too.
With UEFI, I always see that UEFI is kept down to OS for
SecureBoot.
In
other words I don’t see grub.efi booting a non
config_efi_stub.
What do distributions normally do?
At least Red Hat made it clear at multiple Linaro Connect that
they
want
standards, and SystemReady is one that makes the life of
embedded
distros easy.
Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi
SecureBoot.
For Fedora see
https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description
SUSE started the UEFI implementation to boot on all
architectures in
the
same way. The current ARM and RISC-V images uses UEFI.
Debian and Ubuntu install for booting via GRUB if the installer
is
invoked via UEFI. A fallback solution using the legacy Linux
entry
point
exists.
For BSD the only way to boot on ARM is via UEFI.
What's our
position when compared to EDK II?
U-Boot implements only a subset of UEFI defined in the EBBR
specification.
For servers you need a larger scope which is offered by EDK II.
This
is
required both by the RISC-V platform specification as well as
the ARM
SystemReady ServerReady profile.
The number of boards supported by upstream EDK II is very low.
But
proprietary firmware based on EDK II exists.
the typical distro boot flow is not the most efficient and
drags
concept
dating where the Microsoft certs had to be part of the picture.
A
direct
U-Boot Linux.efi is my preferred; avoids yet another OS in the
boot
path
(grub), avoids convoluted platform cert management (shim) and
just
This is why U-Boot supports UEFI boot options specifying both a
binary
as well as an initial RAM disk.
I might be late to this, but where does the devicetree come from?
As
far
as I understand it right now, for most (all) the SytemReady IR
certified
boards, the compiled-in one from u-boot is passed to linux. This
won't
work
in the long run, because the devicetrees keep getting
incompatible
changes.
So while it work for one kernel version it might not work on the
next
version.
It would make sense to add the fdt devicepath to the bootoption
like
we did it for the initrd.
I haven't followed the much of the recent development, are there any
commits/files I can look at?
And I'm not just talking about the use case where the EFI stub of
linux
is booted directy, but also when there is grub in between.
The distribution would supply a bunch of devicetrees along with
the kernel (and initrd). Possibly also different versions of these.
In grub you would choose the desired kernel/initrd/devicetree
combination.
With SystemReady, DT from distros are ignored.
Err? Is this really true, I know about some incompatible changes
to the device tree which prevents you from using usb (or even a
kernel panic) with the imx8mm and I know that on the ls1028a
flexspi wont work if the devicetree doesn't match the kernel.
I.e. if you have a device tree from kernel 5.14 you cannot
use it on 5.10. If you have one from 5.10 you cannot use it on
a later kernel.
So, IMHO this is alreay a non-starter for SystemReady if it
should work beyond having a serial console and some storage :(
With SecureBoot on, dtb=<file> on the command line is disabled.
UEFI can have multiple boot options. Each boot option comes with:
- a list of "device paths" --> dp[n]
- a command line
The "device paths" are not your typical file path in operating system.
They can include configuration information (line speed for a UART
along with terminal emulation parameters). Each dp can be given a
specific class. An initrd "vendor media" class was created.
At present, dp[0] is loaded as the UEFI command and dp[1..n] are
ignored.
Linux kernel EFI_STUB can ask "load the "initrd vendor media here";
the EFI subsystem with browse through dp[1-n] for that element and
load it.
If measured boot is on, the initrd will be measured by the UEFI
subsystem.
So by having multiple BootXXX variables, one can achieve multiple
kernel selections.
But this means grub would need to (1) know the filename of the
devicetree, or (2) it is hardcoded in the grub config which is
generated by the distribution.
For (1) you'd need to convey the information from u-boot to grub.
(2) would mean the distribution will have to figure out the suitable
devicetree.
To make things worse, there are boards which have several
different devicetrees or there might even be overlays. Eg. my
board has different devicetrees which are expected to be chosen
by the user by setting the fdtfile variable.
That was practical when the "user" is also a developer. Things have to
mature to a different model, yet offering same flexibility.
For example some NXP layerscape processors can define the function of
pins by configuring a SerDes. A pin can thus be a PCI lane or an
ethernet MII lane. A board is built with either PCI or Ethernet
connectors or devices. It has nothing to do with a "user" choice: the
DT passed to the OS need to reflect the hardware configuration. U-Boot
need the SerDes device DT to be able to configure the SoC to match the
board hardware. The RichOS shall not see the SerDes, just the PCI or
Ethernet things. Those are known in advance and associated with the
board itself.
Thats understood and clear. But there are also different things to
consider, where the user might actually change something not related
to hardware but which is also contained in the devicetree. The
internal switch connection (and configuration) on the LS1028A comes
to mind (maybe Vladimir can be more specific here). In general, there
might be more than just a description of the hardware in the devicetree.
Could you describe the use case for multiple device trees for one
board?
The board is actually a plug-in module which you can put into
different carriers. The module comes in different variants (1
to 4). This is detected by the bootloader and the correct variant
device tree is loaded, but OTOH the carrier is not detected. This
is something the user has to provide (by now, they have to set
the fdtfile variable to match their carrier).
You can also have a look at
linux/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28*dts
for actual devicetrees.
-michael
