[PATCH 1/1] drivers: add memory disk support

[Tom Rini]

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.schuchardt at 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
-------------- 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/20220420/dcfc354b/attachment.sig>