[PATCH 23/34] bootstd: Maintain a list of images

[Tom Rini]

On Fri, Oct 18, 2024 at 11:20:52AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 18 Oct 2024 at 10:33, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Oct 18, 2024 at 09:01:03AM -0600, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Thu, 17 Oct 2024 at 22:07, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > >
> > > >
> > > >
> > > > Am 18. Oktober 2024 01:24:02 MESZ schrieb Simon Glass <sjg at chromium.org>:
> > > > >We want to keep track of images which are loaded, or those which could
> > > > >perhaps be loaded. This will make it easier to manage memory allocation,
> > > > >as well as permit removal of the EFI set_efi_bootdev() hack.
> > >
> > > I'll change this 'hack' to 'feature'.
> > >
> > > >
> > > > Please, keep in mind that files can be loaded manually, e.g. via the dhcp, the wget, and the loady commands. These are outside bootflows.
> > >
> > > Yes, this series is only going to help if bootstd is used. For ad-hoc
> > > use, EFI will need to rely on the above feature, at least until
> > > someone can think of another solution.
> >
> > Perhaps I need to try and be clearer here than I might have been in the
> > past. The consensus among off the shelf free software operating systems
> > is "just give me an EFI interface". This simplifies things on their end
> > if regardless of architecture it's the same interface. This means that
> > in U-Boot we need to treat EFI as one of the primary interfaces. Not a
> > novelty. Not a "some people might use". It is a frequent and commonly
> > used feature.
> 
> Yes, EFI is everywhere and growing. All the more reason to tidy up
> this piece. I would like to see bootmgr use this new API, for example.
> 
> But how does this comment affect this patch?

Because at the very high level, I wonder if I made a mistake a few years
back. As I understand it, the nominal case is "bootefi bootmgr". I was
saying at the time that perhaps bootstd can just fire that off, and move
on. Now it seems like we're going along the path of re-inventing that,
and not integrating well with it either.

So, to try and bring things back together. If U-Boot decides to load
$FOO from device $BAR, at that common point is where we need to:
- Is there an lmb for the location this is supposed to go to (for the if
  we know it, entire size)?
- Note down everything else we know, now.

This means that we can note down enough stuff so that EFI can construct
the path it needs. And if we're being told a filesystem, that filename
is good enough for the IH_TYPE thing you're wanting, or at least a good
chunk of it I hope.

It also means that since it's at the most common point, it doesn't
matter if we were in an EFI application, a boot script, a bootmeth or
someone at the cmdline doing "load mmc 0:1 /boot/Image $kernel_addr_r".

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241018/eedfc62d/attachment.sig>