On 6/28/21 6:26 PM, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini <tr...@konsulko.com> wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass <s...@chromium.org>
Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of
code to U-Boot. For example, with nokia_rx51 the size delta is about
90KB. About 170 boards explicitly disable the option, but is is clear
that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the
years UEFI support has become more complete, but a lot of that new
code implements features that are not at all essential for just
booting an OS from storage. If that growth leads to the suggestion to
disable EFI_LOADER completely by default, we're putting the cart
before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found
EFI_LOADER being used in the wild on armv7, but wasn't sure about the
BSD families. I did see that Debian doesn't use it, and that Armbian
doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world,
and some of its Microsoft-isms are really annoying (yay UCS-2). But
it works, it provides a standardized approach across several platforms
(ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally
I'd wish the industry had standardized on Open Firmware instead, but
that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for
something that is going to include a multi-MB Linux kernel. This
isn't code that lives in SPL or TPL where severe size restrictions
apply.
In one of those cases where I need to pop back in to the other (Nokia
N900 specific) thread and see if the big size reduction really was just
disabling EFI_LOADER, it's perhaps just one of those "fun" things about
Kconfig and anything other than "make oldconfig" for spotting new config
options that default to enabled.
Yes it will be interesting to see what you find there. My results on
nokia_rx51 were something like this:
default
arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0
rodata +10989.0 text +109846.0
without ebbr
arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0
rodata +5333.0 text +29712.0
with various other things:
CONFIG_OF_LIBFDT_ASSUME_MASK=7
# CONFIG_OF_TRANSLATE is not set
# CONFIG_SIMPLE_BUS is not set
# CONFIG_TI_SYSC is not set
# CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata
+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works
for booting Linux, and forces people to combine u-boot, kernel,
initial ramdisk and other firmware components into a single image.
That is really undesirable as:
- This makes it sigificantly harder to update individual components of
such an image. Making it hard to update a kernel is obviously a
serious security risk.
- This makes it impossible to build an OS install image that works om
multiple boards/SoCs.
I would really like to understand this better. The whole thing is a
complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It
seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At
least in the systems I have used, they are built together, even having
the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64
System.map-5.10.40-1rodete1-amd64
vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux
and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it
allows for a hash / signature check.
Finally, for the firmware components, do you mean system firmware? If
so, I would expect it to be more convenient to distribute updates to
that separately, although I suppose they could be combined with the
kernel if the combinatorial explosion can be contained. What is the
problem, exactly? (If you mean peripheral firmware, I would expect
fwupd to handle that.)
What exactly is impossible? Can you please be more specific?
FIT is just a container. It seems to have been rejected by the EFI
crew at some point. Perhaps I just need to try to use it with one of
the distros out there, to actually understand what is going on here.
But any help is appreciated.
FIT and EFI are orthogonal. A FIT image can contain an EFI binary. See
CONFIG_BOOTM_EFI.
(I think that is a different topic; FIT can of course contain any image)
EFI_LOADER is required by EBBR, a new boot standard which aims to
bring in UEFI protocols to U-Boot. But EBRR is not required for
booting. U-Boot already provides support for FIT, the 'bootm' command
and a suitable hand-off to Linux. EBRR has made the decision to create
a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing
infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several
platforms as well as generic Linux distros. For example
OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on
EFI_LOADER to boot and have done so for the last 4 years. The fact
that ARM has embraced UEFI as an embedded boot standard and branded it
EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other
technologies had become dominant for technical rather than inertia
reasons, but here we are. Having played around with it on aarch64,
there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far
backwards in generations it's going to be used on. The general wish is
that users nor off the shelf OS groups need to rebuild U-Boot for a
given board, and instead it just works. The number of new designs for
32bit parts is no where near the number of new designs for 64bit parts.
So what we're seeing in U-Boot now is people updating support on their
older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a
few problems that need resolving (devices for partitions and file
handles). Both of those features should first be added to U-Boot, so
EFI can then use that support. In general, EFI has tried to work
beside driver model, creating its own parallel tables, etc.
Could you, please, be a bit more specific. Please, indicate which data
structures you would like to integrate into the driver model.
As a starting point, all the struct efi_device_path* things should be
generated on the fly from DM, rather than existing in parallel.
The driver model does not describe all devices in the lifetime of an
UEFI application. Applications like iPXE create handles and install
there own device paths on them.
When a U-Boot device is probed a UEFI handle should be created and the
device path protocol has to be installed. I hope this is what you mean
by "on the fly".
Be aware that the device path protocol can be replaced by a UEFI
application by calling ReinstallProtocol() at any time. So to be UEFI
compliant you cannot create device paths upon access. Let's assume you
did not mean this by "on the fly".
After all device paths have to exist as data structures in parallel to
the currrent driver model. But we can change how we create them.
EDK II shows that a driver model completely based on UEFI protocols is
possible. As long as we don't follow that road we will have separate
APIs for the UEFI world and U-Boot's internal use and we will have to
keep track of objects that exist only in the one world or the other.
What we definitively need is a better integration between probing and
removing U-Boot devices and their representation in the UEFI world.
That is the crux of the problem. The approach taken by UEFI (of
duplicating everything) needs to change.
Another area that might deserve attention is memory allocation.
AllocatePool() consuming whole memory pages is quite a waste.
I have
tried to influence this at various points along the way, including at
the start and I'm happy to dig out those threads if it helps. But I
wasn't kidding. it really needs to be addressed. I would love to see
Linaro (for example) organise something here and take this on. I am
very happy to help.
The starting point would be comparing the DM and UEFI object models and
pointing out which objects can be mapped and which cannot.
In my book there are three categories:
- can
- cannot at present, but should be soon
- should not
'Cannot be mapped because not defined in the UEFI spec' is missing in
your scheme. E.g. there is a RNG protocol but no such thing as a RNG
device defined in the UEFI spec.
Best regards
Heinrich
