Am 2021-09-30 17:47, schrieb François Ozog:
On Thu, 30 Sept 2021 at 17:12, Michael Walle <mich...@walle.cc> wrote:
[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.
What you describe is the situation we want to avoid and that comes
from years of tinkering.
how is that tinkering? That means once you have a device tree, it is
set in stone. which isn't reality, sorry.
Consider the ls1028a and the flexspi "bug". For the 5.10 kernel/dtb
there was a wrong clock connected to the flexspi device. There wasn't
even a driver for the correct clock. Thus, I introduced a new clock
driver and wired it correctly in the device tree. Which was introduced
in 5.11 (or 5.12 I don't know anymore). u-boot is now providing a
devicetree from the 5.14 kernel. Thus, it has the clock input connected
to the new clock driver. But debian, for example, has kernel 5.10. Which
doesn't have the clock driver, oops. The flexspi tries to enable the
clock which fails and the whole probe will fail.
Regarding the imx8mm usb error, apparently the node was renamed. If
you're
using older kernels with newer dtbs, the kernel oopes. If you're using a
newer kernel with older dtbs, USB doesn't get probed. (Although I was
told that there is a "fix" for this, that is, both node names are
tried.)
https://developer.arm.com/architectures/system-architectures/arm-systemready/ir
lists a number of certified boards and the list is going to grow
significantly.
And the sl28 board will likely be there soon, too.
On those boards, you will be able to boot any kernel.
Actually I don't think so, because you might hit the imx8mm bug, too.
May
just be lucky by the devicetree/kernel combination.
The image I have in mind with OS provided DT is:
as a French driver, my DT says that the steering wheel is on the left
hand side of the car.
Shall I whine about the cars in England that do not comply to my DT?
or accept to use the car provided DT?
The situation is comfortable for tinkerers, but not sustainable. It is
a matter of organization and not technology to solve the problems you
describe.
Mh, I'm not sure I understand what you're trying to tell me. The
distribution also provides you the kernel, why shouldn't it provide
devicetree which exactly matches this kernel and was also tested
against.
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.
Indeed and DPAA2 configuration also comes to mind. But then where
shall the use configuration be described?
DT shall describe the hardware, and not its configuration which tends
to be OS dependent or more precisely, driver dependent.
U-Boot is probably the best placed to do some of the work. It can have
ways to describe the desired configuration in auxiliary persistent
configuration data.
That auxiliary information can be stored in various places under
various formats. One possible way is to have overlays.
Another one is to have U-Boot use DT format as way to stored some
configuration (U-Boot private bindings). This method is actually used
by TF-A, for instance to describe the static secure partitions.
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.
For hats, capes, SoMs, carrier boards and others, we need to better
organize.
The EEPROM based approach by RPI and Beagle shall give us hints on how
to deal with this at scale in an industrial manner.
We have EEPROM SPDs for DIMMs: it feels so natural to leverage the
same concept to bring enumeration to those hot/cold pluggable
elements.
It is my intent to sit down with RPI, Beagle and 96Boards to agree on
something around those lines.
In the meantime, manual composition is a nuisance with have to deal
with. But for sure, that should be entirely transparent to the OS.
Well there are boards out there, where auto detection is not possible,
or intentionally not wanted. And of course it should be transparent
to the operation system. But you have a way to load a different
devicetree but the _only_ one you got with your firmware (or let it
be a set of devicetrees, doesn't matter).
-michael
Side note to read in a positive mindset even if it does not look
positive:
If we keep things like they are, what may end up happening is that
business leaders will direct their teams to use ACPI to avoid DT
related pains.
One would say ACPI does not support everything and it comes with
EDK2...
Well, let's just be patient and we will witness that business guys
have a different view of what is a solution to a problem.
