[PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model

[Simon Glass]

Hi Tom,

On Wed, 9 Mar 2022 at 07:25, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Mar 08, 2022 at 08:10:38PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 8 Mar 2022 at 20:00, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Mar 08, 2022 at 07:32:59PM -0700, Simon Glass wrote:
> > > >  Hi Tom,
> > > >
> > > > On Tue, 8 Mar 2022 at 17:13, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote:
> > > > > > Hi Soeren,
> > > > > >
> > > > > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch <smoch at web.de> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 08.03.22 17:56, Simon Glass wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > > > > >>
> > > > > > > >> On 3/8/22 12:36, AKASHI Takahiro wrote:
> > > > > > > >>> With this patch set[1] applied, UEFI subsystem maintains a list of its
> > > > > > > >>> disk objects dynamically at runtime based on block device's probing.
> > > > > > > >>> (See "issues" below.)
> > > > > > > >>>
> > > > > > > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk
> > > > > > > >>
> > > > > > > >> This series together with Simon's series breaks multiple boards due to
> > > > > > > >> size constraints:
> > > > > > > >>
> > > > > > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197
> > > > > > > >>
> > > > > > > >> Please, investigate how to work around this issue.
> > > > > > > >
> > > > > > > > tbs2910 - perhaps we should just drop this board? It doesn't use
> > > > > > > > DM_SERIAL and still uses OF_EMBED
> > > > > > >
> > > > > > > Are we again at the same point? You are breaking working boards with
> > > > > > > (for these boards) useless additions, and all you come up with is
> > > > > > > "remove this board". Of course without adding the board maintainer.
> > > > > >
> > > > > > I'm just expressing reasonable frustration that this board uses
> > > > > > OF_EMBED and does not use DM_SERIAL, after all of this time. Why
> > > > > > should the rest of the U-Boot developers care more about this board
> > > > > > than the maintainer?
> > > > >
> > > > > Please keep in mind Simon that we've had zero releases with the
> > > > > DM_SERIAL migration warning being posted, v2022.04 will be the first
> > > > > one.
> > > >
> > > > Yes, understood :-) For OF_EMBED though...?
> > >
> > > No deadline and 50 boards.
> >
> > Er, there has been a build message about that since the beginning, so
> > people ignored it. Do we really need to make the build fail for these
> > sorts of things? Perhaps so, but it is a sad situation.
>
> Yes, in hind-sight, "don't do that" wasn't the right path.  It would be
> a good idea to start a different thread and see what / how the platforms
> can be migrated away.

I think there is a use case for it now - e.g. booting Apple M1 which
uses a separate bootloader. IMO a .img or .fit file would be better in
some cases but people seem to be allergic to implementing U-Boot
things in their code bases. We have the same requirement for the EFI
app since UEFI does not implement the U-Boot .img file.

So if we are going to support this, perhaps we should create a new
option for it. But honestly I am just too weary to consider yet
another migration. We need to finish some, e.g. Kconfig.

>
> > > > It was actually quite hard to add a migration message until we added
> > > > the CONFIG_SERIAL base thing and that was a pain to do.
> > > >
> > > > For those of us who take on larger refactors etc., we end up spending
> > > > a lot of our time on these few platforms. I'm not picking on tbs2910in
> > > > in particular.
> > >
> > > Well, the flip side of the problem here is that there's a number of
> > > platforms with real constraints to them and it keeps being "can we drop
> > > this yet?" without CC'ing the board maintainer on the series that once
> > > again pushes a given platform to the limit.  I would expect no size
> > > growth to tbs2910 for the topic of this series since it disables
> > > EFI_LOADER entirely, so why is it a problem?
> >
> > The partition changes are going to add some size anyway, I expect. I
> > have not actually analysed it though. Perhaps we can just disable a
> > filesystem?
>
> I was a bit too absolutist there, sorry.  Yes, a few hundreds of bytes
> here-and-there is probably a non issue.  But it shouldn't be kilobytes.
> It really shouldn't push things over the line.
>
> And on the tbs2910 side, Soeren, can you look at enabling LTO for this
> platform?  That would likely buy a good bit of space savings.  That
> might well be needed to do further DM migrations/etc.

Regards,
Simon