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. > "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. > * adding iPXE Rather than fetching this from the network, to continue to fetch and load applications from the network? > * adding a custom graphical boot manager as EFI application Why can't this be loaded from the disk? What I would like to see is the proof of concept / design that makes use of this, that can't make use of the existing facilities we have for doing similar concepts already. Or that aren't something that should be done within U-Boot, if necessary. -- Tom
signature.asc
Description: PGP signature