Hi Tom,
On Fri, 18 Oct 2024 at 12:04, Tom Rini trini@konsulko.com 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 trini@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@gmx.de wrote:
Am 18. Oktober 2024 01:24:02 MESZ schrieb Simon Glass sjg@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.
In what way are we re-inventing that? bootstd supports lots of different ways of booting, not just EFI. 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.
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?
For EFI there is only an EFI application. It will always just be a PE file. We don't really know what it is, as someone pointed out earlier. Maybe one day we will check to see if it is a UKI and pull things out of it. But then, it would be component parts (kernel, ramdisk, etc.) so I would want to add them as images.
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".
For that case (at the cmdline), bootstd is not currently running. Are you suggesting that bootstd could pick up these things and record them? If so, then yes, definitely, I want to do that. This series is the starting point for that. If you are suggesting something else, then I think I have lost you at this point.
Regards, Simon