On 6/29/21 2:56 PM, AKASHI Takahiro wrote:
On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote:
Hi Tom,

On Mon, 28 Jun 2021 at 11:27, Tom Rini <tr...@konsulko.com> wrote:

On Mon, Jun 28, 2021 at 10:26:35AM -0600, 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.

The question of "how great would it be and how many problems would it
have solved if FIT images had become popular" is one for another time.
It will always have its use cases and users but never the broad adoption
many of us felt it should have.  Bringing it up in this context won't
change that.

I see Peter's reply below so will make time to dig into this and
understand the problems with FIT better. I feel that EFI comes with
all sorts of problems so I'm far from convinced, at this point. Sorry.

It seems to me that we are discussing three different things:
- the code size increase by enabling UEFI interfaces
- how the UEFI interface be implemented on U-Boot
- The primary (or default/standard) boot mechanism in the future

I don't think they are totally independent, but we'd better
distinguish them some how in the following discussions.


I'm saying this because I think there are some important technical
questions within U-Boot to resolve because the EFI loader part of U-Boot
is critical to our long term future.  And DM is an important part of our
internal design and we're (probably later than I should have) pulling
out the parts that haven't been updated so that we can deliver on some
of the overall promise of DM better, too.

Yes, migration has certainly been slow. As you know I mostly stopped
pushing it a few years back when I saw all the reluctance. I'm very
pleased you are taking that on and I think it will help a lot.

I posted this patch[1] two years ago and I thought that we had had
some sort of consensus that UEFI interfaces be integrated more elegantly
with DM in the future.

So I was a bit surprised with Heinrich's recent patch.

In [1], I was trying to define all the UEFI handles, including some
protocols?, as DM objects.
I thought that it was the best way for unifying the two worlds even if
there are no corresponding *notions* in the existing DM objects.

[1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html

-Takahiro Akashi

You wrote yourself: "bootefi doesn't work with this patch set yet".

Your series completely disregarded UEFI and DM logic, e.g. you defined
DM devices per protocol.

You tried to integrate UEFI and DM world at an inappropriate level:
Instead of changing DM block device uclass you touched individual
drivers like USB and SCSI completely disregarding all other block device
classes.

Best regards

Heinrich



If what you say comes to pass, it is even more important that EFI is
more integrated, rather than being a bolt on. Thanks largely to
Heinrich, the tests are in quite good shape, so refactoring should be
feasible.

Regards,
Simon

Reply via email to