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