Re: [PATCH 1/1] drivers: add memory disk support
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 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! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] drivers: add memory disk support
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 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. "load a firmware blob" requires a block device or a network file system. If you put U-Boot's payload into the U-Boot blob, you need neither a separate block device nor a network file system. Packaging into U-Boot makes most sense where follow-up binaries are tightly integrated: * adding a custom graphical boot manager as EFI application * adding iPXE * delivering device-trees Best regards Heinrich
Re: [PATCH 1/1] drivers: add memory disk support
On 4/19/22 23:54, Simon Glass wrote: > Hi Heinrich, > > On Tue, 19 Apr 2022 at 15:14, 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 >> --- >> MAINTAINERS | 6 ++ >> common/board_r.c | 4 + >> drivers/Kconfig | 2 + >> drivers/Makefile | 1 + >> drivers/block/blk-uclass.c | 2 + >> drivers/memdisk/Kconfig | 13 >> drivers/memdisk/Makefile | 11 +++ >> drivers/memdisk/memdisk-uclass.c | 22 ++ >> drivers/memdisk/memdisk.c| 128 +++ >> drivers/memdisk/memdisk_file.S | 17 >> include/asm-generic/sections.h | 2 + >> include/blk.h| 1 + >> include/dm/uclass-id.h | 1 + >> include/memdisk.h| 28 +++ >> 14 files changed, 238 insertions(+) >> create mode 100644 drivers/memdisk/Kconfig >> create mode 100644 drivers/memdisk/Makefile >> create mode 100644 drivers/memdisk/memdisk-uclass.c >> create mode 100644 drivers/memdisk/memdisk.c >> create mode 100644 drivers/memdisk/memdisk_file.S >> create mode 100644 include/memdisk.h > > Can this use binman to create the image and find the memdisk? binman requires board specific layout information. I cannot see how binman would help for a Kconfig option that can be switched on and off for any board. binman may provide addresses in the control device-tree which later could be relocated. But this seems to result in a larger image size. Best regards Heinrich > > Regards, > Simon
Re: [PATCH 1/1] drivers: add memory disk support
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 > > > > 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
Re: [PATCH 1/1] drivers: add memory disk support
On Wed, Apr 20, 2022 at 12:20:43AM +0200, Heinrich Schuchardt wrote: > On 4/19/22 23:54, Simon Glass wrote: > > Hi Heinrich, > > > > On Tue, 19 Apr 2022 at 15:14, 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 > >> --- > >> MAINTAINERS | 6 ++ > >> common/board_r.c | 4 + > >> drivers/Kconfig | 2 + > >> drivers/Makefile | 1 + > >> drivers/block/blk-uclass.c | 2 + > >> drivers/memdisk/Kconfig | 13 > >> drivers/memdisk/Makefile | 11 +++ > >> drivers/memdisk/memdisk-uclass.c | 22 ++ > >> drivers/memdisk/memdisk.c| 128 +++ > >> drivers/memdisk/memdisk_file.S | 17 > >> include/asm-generic/sections.h | 2 + > >> include/blk.h| 1 + > >> include/dm/uclass-id.h | 1 + > >> include/memdisk.h| 28 +++ > >> 14 files changed, 238 insertions(+) > >> create mode 100644 drivers/memdisk/Kconfig > >> create mode 100644 drivers/memdisk/Makefile > >> create mode 100644 drivers/memdisk/memdisk-uclass.c > >> create mode 100644 drivers/memdisk/memdisk.c > >> create mode 100644 drivers/memdisk/memdisk_file.S > >> create mode 100644 include/memdisk.h > > > > Can this use binman to create the image and find the memdisk? > > binman requires board specific layout information. I cannot see how binman > would help for a Kconfig option that can be switched on and off for any > board. > > binman may provide addresses in the control device-tree which later could be > relocated. But this seems to result in a larger image size. This is something analogous to the initrd/initramfs framework within the Linux kernel, yes? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] drivers: add memory disk support
On 4/20/22 01:01, Tom Rini wrote: On Wed, Apr 20, 2022 at 12:20:43AM +0200, Heinrich Schuchardt wrote: On 4/19/22 23:54, Simon Glass wrote: Hi Heinrich, On Tue, 19 Apr 2022 at 15:14, 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 --- MAINTAINERS | 6 ++ common/board_r.c | 4 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/block/blk-uclass.c | 2 + drivers/memdisk/Kconfig | 13 drivers/memdisk/Makefile | 11 +++ drivers/memdisk/memdisk-uclass.c | 22 ++ drivers/memdisk/memdisk.c| 128 +++ drivers/memdisk/memdisk_file.S | 17 include/asm-generic/sections.h | 2 + include/blk.h| 1 + include/dm/uclass-id.h | 1 + include/memdisk.h| 28 +++ 14 files changed, 238 insertions(+) create mode 100644 drivers/memdisk/Kconfig create mode 100644 drivers/memdisk/Makefile create mode 100644 drivers/memdisk/memdisk-uclass.c create mode 100644 drivers/memdisk/memdisk.c create mode 100644 drivers/memdisk/memdisk_file.S create mode 100644 include/memdisk.h Can this use binman to create the image and find the memdisk? binman requires board specific layout information. I cannot see how binman would help for a Kconfig option that can be switched on and off for any board. binman may provide addresses in the control device-tree which later could be relocated. But this seems to result in a larger image size. This is something analogous to the initrd/initramfs framework within the Linux kernel, yes? Yes, it is like appending an initrd to a kernel. Best regards Heinrich
Re: [PATCH 1/1] drivers: add memory disk support
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 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.
Re: [PATCH 1/1] drivers: add memory disk support
On Wed, Apr 20, 2022 at 08:48:28AM +0200, Heinrich Schuchardt wrote: > > > On 4/20/22 01:01, Tom Rini wrote: > > On Wed, Apr 20, 2022 at 12:20:43AM +0200, Heinrich Schuchardt wrote: > > > On 4/19/22 23:54, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Tue, 19 Apr 2022 at 15:14, 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 > > > > > --- > > > > >MAINTAINERS | 6 ++ > > > > >common/board_r.c | 4 + > > > > >drivers/Kconfig | 2 + > > > > >drivers/Makefile | 1 + > > > > >drivers/block/blk-uclass.c | 2 + > > > > >drivers/memdisk/Kconfig | 13 > > > > >drivers/memdisk/Makefile | 11 +++ > > > > >drivers/memdisk/memdisk-uclass.c | 22 ++ > > > > >drivers/memdisk/memdisk.c| 128 > > > > > +++ > > > > >drivers/memdisk/memdisk_file.S | 17 > > > > >include/asm-generic/sections.h | 2 + > > > > >include/blk.h| 1 + > > > > >include/dm/uclass-id.h | 1 + > > > > >include/memdisk.h| 28 +++ > > > > >14 files changed, 238 insertions(+) > > > > >create mode 100644 drivers/memdisk/Kconfig > > > > >create mode 100644 drivers/memdisk/Makefile > > > > >create mode 100644 drivers/memdisk/memdisk-uclass.c > > > > >create mode 100644 drivers/memdisk/memdisk.c > > > > >create mode 100644 drivers/memdisk/memdisk_file.S > > > > >create mode 100644 include/memdisk.h > > > > > > > > Can this use binman to create the image and find the memdisk? > > > > > > binman requires board specific layout information. I cannot see how binman > > > would help for a Kconfig option that can be switched on and off for any > > > board. > > > > > > binman may provide addresses in the control device-tree which later could > > > be > > > relocated. But this seems to result in a larger image size. > > > > This is something analogous to the initrd/initramfs framework within the > > Linux kernel, yes? > > Yes, it is like appending an initrd to a kernel. I'm not super comfortable with that concept, and want to see the use case spelled out a lot more. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] drivers: add memory disk support
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 > > > > > > > > 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 signature.asc Description: PGP signature
