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

Heinrich Schuchardt heinrich.schuchardt at canonical.com
Wed Apr 20 08:58:25 CEST 2022



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.

> 
>> "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.

> 
>> * 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.

> 
>> * 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.

Best regards

Heinrich

> 
> 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.
> 


More information about the U-Boot mailing list