On Wed, Apr 20, 2022 at 08:58:25AM +0200, Heinrich Schuchardt wrote: > > > On 4/20/22 00:59, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 11:55:00PM +0200, Heinrich Schuchardt wrote: > > > On 4/19/22 23:26, Tom Rini wrote: > > > > On Tue, Apr 19, 2022 at 11:16:41PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > In some scenarios it is desirable to package U-Boot with other files > > > > > into > > > > > a single blob. This patch allows to embed a memory disk into the > > > > > U-Boot > > > > > binary. This memory disk can be accessed like any other block > > > > > device as 'mem 0'. > > > > > > > > > > Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com> > > > > > > > > What's the use case for this, which isn't covered by some combination of > > > > U-Boot being in a FIT image and the "load a firmware blob" that we have > > > > today? Thanks! > > > > > > "U-Boot being in a FIT image" requires a loader that understands FIT. > > > > Fortunately, that's U-Boot. > > U-Boot can load FIT images. But other firmware cannot load a U-Boot which is > inside a FIT image.
That's not how this works? Please look at the platforms today which make use of U-Boot and a FIT image for U-Boot. > > > "load a firmware blob" requires a block device or a network file system. > > > > No, we have various cases where we bundle inside of the image various > > black boxes, in various ways. > > > > > If you put U-Boot's payload into the U-Boot blob, you need neither a > > > separate block device nor a network file system. > > > > What is the use case for this? > > > > > Packaging into U-Boot makes most sense where follow-up binaries are > > > tightly > > > integrated: > > [re-ordering this list, sorry] > > > * delivering device-trees > > > > Yes, we can do that today, select the right one at run time, and even > > pass that along to EFI via the appropriate config table entry. > > If you want add an arbitrary device-tree that you want to pass to Linux you > ave to patch a lot of code. U-Boot passes the running device tree via EFI to the next stage out of the box right now. We can be given a device tree to use by a prior stage, or we can use one of N that we were bundled with, right now. > > > * adding iPXE > > > > Rather than fetching this from the network, to continue to fetch and > > load applications from the network? > > U-Boot only offers insecure and unreliable protocols like tftp and NFS. Then we should verify the payload we download before using it. We support that already. > > > * adding a custom graphical boot manager as EFI application > > > > Why can't this be loaded from the disk? > > Disks drives are often loaded by other entities then firmware. The whole > point of the patch is providing files without relying on a disk. I'm not sure I get why, however. We get tons of feedback along the lines of "U-Boot is TOO BIG" and "I don't want to have to package U-Boot for my distro, I want it to be on there and just work". This feels like taking both things in the other direction, without a clear use case for who is going to use it, for what, and why what we have today is insufficient. -- Tom
signature.asc
Description: PGP signature
