Hi Tom, On Wed, 23 Oct 2024 at 20:41, Tom Rini <[email protected]> wrote: > > On Tue, Oct 22, 2024 at 07:00:44PM +0200, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 22 Oct 2024 at 17:01, Tom Rini <[email protected]> wrote: > > > > > > On Tue, Oct 22, 2024 at 02:16:52PM +0200, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Sat, 19 Oct 2024 at 18:30, Tom Rini <[email protected]> wrote: > > > > > > > > > > On Sat, Oct 19, 2024 at 05:49:40AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Fri, 18 Oct 2024 at 15:30, Tom Rini <[email protected]> wrote: > > > > > > > > > > > > > > On Fri, Oct 18, 2024 at 12:48:31PM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Fri, 18 Oct 2024 at 12:04, Tom Rini <[email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > 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 <[email protected]> > > > > > > > > > > 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 > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 18. Oktober 2024 01:24:02 MESZ schrieb Simon Glass > > > > > > > > > > > > > <[email protected]>: > > > > > > > > > > > > > >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. > > > > > > > > > > > > > > > > In what way are we re-inventing that? bootstd supports lots of > > > > > > > > different ways of booting, not just EFI. > > > > > > > > > > > > > > At the high level, bootflow scan is re-implementing "bootefi > > > > > > > bootmgr". > > > > > > > but handling non-EFI payloads. > > > > > > > > > > > > bootstd is about replacing the distro scripts, not bootmgr. > > > > > > > > > > And the distro scripts are functionally replaced by "bootefi bootmgr", > > > > > outside of bootstd. > > > > > > > > But that doesn't support anything other than EFI apps, so isn't useful > > > > for when EFI is not wanted. > > > > > > Yes, the distro scripts wanted to move more firmly / quickly in this > > > direction. For all of the reasons they've elaborated before. > > > > OK, well good luck to them, I suppose. > > > > > > > > > > > > > Also I hope that one day EFI > > > > > > > > will be implemented more as part of U-Boot than as a bolt-on, > > > > > > > > so will > > > > > > > > make use of bootflows, etc. > > > > > > > > > > > > > > And stuff like that is why I said what I said in here first. To > > > > > > > me it > > > > > > > sounds like you keep implying it's a hack that's not well > > > > > > > integrated. > > > > > > > When it's honestly at this point gotten more traction than FIT > > > > > > > images > > > > > > > have I think (as much as I wish FIT images had "won", it's like > > > > > > > VHS vs > > > > > > > Betamax, to bring in another technology metaphor). > > > > > > > > > > > > The 'hack' I was referring to is efi_set_bootdev(), not EFI_LOADER > > > > > > as a whole! > > > > > > > > > > I wasn't clear enough, sorry. I didn't mean just in this series where > > > > > you referred to storing the needed property as a hack but rather > > > > > "bolt-on" in what I quoted and "tidy up this" and "tidy up that". I'm > > > > > just saying what impression your words leave with me, and quite > > > > > possibly > > > > > others. > > > > > > > > OK I will try to be more gentle with my language. > > > > > > Thanks. > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > You want me to ignore the type that I know (kernel, ramdisk, > > > > > > > > logo, > > > > > > > > etc.) and infer the type from a filename? Why? > > > > > > > > > > > > > > No, I want you to save and display the filename. That's probably > > > > > > > much > > > > > > > more useful when debugging than "kernel". If you actually know > > > > > > > some > > > > > > > other type information (ie extlinux.conf says ...) then yes, it > > > > > > > too can > > > > > > > be stored as that's useful too. > > > > > > > > > > > > The filename is already saved in bootflow->filename, and now it is > > > > > > in > > > > > > struct bootflow_img. > > > > > > > > > > OK. But that's not generic enough. > > > > > > > > How about we see how things work out here rather than giving up at the > > > > start? It is pretty clear in my head, so far. > > > > > > I'd really rather not since it looks like it's starting in the wrong > > > direction. I really do not understand why when we load the file / do the > > > network request / read the flash area / etc is the wrong place to start > > > recording the information about what we load. > > > > It isn't that it is the wrong place, it's just that we know more when > > a bootmeth is in place. Are you thinking about the distro scripts or > > people's custom scripts, or something else? > [snip] > > > Yes, perhaps some series that shows what works / doesn't work and how it > > > works would be helpful. I'd really like to see where you're starting > > > your abstractions from. > > > > OK I'll send a version with an add-on patch for the 'load' command, > > with the concept of an ad-hoc bootflow. > > I want to combine these two (and I hope not drop any important context), > to reply. A challenge is that for EFI, we need to know where we loaded > something from. You hope that EFI_LOADER will make use of bootmeths at > some future point, but that's not on your TODO list? What I'm saying is > that in for example fs_read(), we have the common point between > bootmeth, EFI_LOADER and "load" and already need to be doing sanity > checks and can record what information we have now. Can bootmeth add to > it? Sure. But I still don't see why this is the wrong place to start. > And there are analogous points for network, flash, etc.
There is already a bootmeth_efi which uses EFI_LOADER But the point here is something different. I am not suggesting use of a bootmeth, but use of a bootflow. My idea is to use an ad-hoc bootflow which collects things not attached to an existing bootflow. I'll get some time to send the series again, with a few more patches at the end, to show the approach. But this series is the bones of it. Regards, Simon
