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