* [PATCH 1/1] drivers: add memory disk support
@ 2022-04-19 21:16 Heinrich Schuchardt
2022-04-19 21:26 ` Tom Rini
0 siblings, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2022-04-19 21:16 UTC (permalink / raw)
To: Tom Rini; +Cc: Simon Glass, u-boot, Heinrich Schuchardt
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>
---
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
diff --git a/MAINTAINERS b/MAINTAINERS
index 34446127d4..be71f8d9b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -930,6 +930,12 @@ T: git git://github.com/ARM-software/u-boot.git
F: drivers/video/mali_dp.c
F: drivers/i2c/i2c-versatile.c
+MEMDISK
+M: Heinrich Schuchardt <xypron.glpk@gmx.de>
+S: Supported
+F: drivers/memdisk/
+F: include/memdisk.h
+
MICROBLAZE
M: Michal Simek <monstr@monstr.eu>
S: Maintained
diff --git a/common/board_r.c b/common/board_r.c
index 8dc87ed2be..f416dbd17e 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -37,6 +37,7 @@
#include <irq_func.h>
#include <malloc.h>
#include <mapmem.h>
+#include <memdisk.h>
#include <miiphy.h>
#include <mmc.h>
#include <mux.h>
@@ -700,6 +701,9 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_CMD_ONENAND
initr_onenand,
#endif
+#ifdef CONFIG_MEMDISK
+ initr_memdisk,
+#endif
#ifdef CONFIG_MMC
initr_mmc,
#endif
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..bf475c25e7 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -56,6 +56,8 @@ source "drivers/led/Kconfig"
source "drivers/mailbox/Kconfig"
+source "drivers/memdisk/Kconfig"
+
source "drivers/memory/Kconfig"
source "drivers/misc/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 4e7cf28440..3c2906b9c5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_TPL_)FIRMWARE) +=firmware/
obj-$(CONFIG_$(SPL_TPL_)I2C) += i2c/
obj-$(CONFIG_$(SPL_TPL_)INPUT) += input/
obj-$(CONFIG_$(SPL_TPL_)LED) += led/
+obj-$(CONFIG_$(SPL_TPL_)MEMDISK) += memdisk/
obj-$(CONFIG_$(SPL_TPL_)MMC) += mmc/
obj-y += mtd/
obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux/
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index f1e4a85646..4beec38f71 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -23,6 +23,7 @@ static const char *if_typename_str[IF_TYPE_COUNT] = {
[IF_TYPE_ATAPI] = "atapi",
[IF_TYPE_USB] = "usb",
[IF_TYPE_DOC] = "doc",
+ [IF_TYPE_MEMDISK] = "mem",
[IF_TYPE_MMC] = "mmc",
[IF_TYPE_SD] = "sd",
[IF_TYPE_SATA] = "sata",
@@ -40,6 +41,7 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {
[IF_TYPE_ATAPI] = UCLASS_INVALID,
[IF_TYPE_USB] = UCLASS_MASS_STORAGE,
[IF_TYPE_DOC] = UCLASS_INVALID,
+ [IF_TYPE_MEMDISK] = UCLASS_MEMDISK,
[IF_TYPE_MMC] = UCLASS_MMC,
[IF_TYPE_SD] = UCLASS_INVALID,
[IF_TYPE_SATA] = UCLASS_AHCI,
diff --git a/drivers/memdisk/Kconfig b/drivers/memdisk/Kconfig
new file mode 100644
index 0000000000..03f646539c
--- /dev/null
+++ b/drivers/memdisk/Kconfig
@@ -0,0 +1,13 @@
+config MEMDISK
+ bool "Support embedded memory disk"
+ select HAVE_BLOCK_DEVICE
+ help
+ This option allows to embed a memory disk.
+
+config MEMDISK_FILE
+ string "Memory disk file"
+ depends on MEMDISK
+ default "memdisk.img"
+ help
+ File to be embedded as memory disk.
+ It can be accessed as block device 'mem 0'.
diff --git a/drivers/memdisk/Makefile b/drivers/memdisk/Makefile
new file mode 100644
index 0000000000..09d6de22d2
--- /dev/null
+++ b/drivers/memdisk/Makefile
@@ -0,0 +1,11 @@
+ifeq ($(CONFIG_MEMDISK),y)
+
+obj-y += \
+ memdisk.o \
+ memdisk-uclass.o \
+ memdisk_file.o
+
+MEMDISK_FILE := $(subst $\",,$(CONFIG_MEMDISK_FILE))
+$(obj)/memdisk_file.o: $(srctree)/$(MEMDISK_FILE)
+
+endif
diff --git a/drivers/memdisk/memdisk-uclass.c b/drivers/memdisk/memdisk-uclass.c
new file mode 100644
index 0000000000..b7b96f91a4
--- /dev/null
+++ b/drivers/memdisk/memdisk-uclass.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Embedded disk image
+ *
+ * Copyright (c) 2022, Heinrich Schuchardt <xypron.glpk@gmx.de>
+ */
+
+#define LOG_CATEGORY UCLASS_MEMDISK
+
+#include <common.h>
+#include <dm.h>
+#include <memdisk.h>
+
+UCLASS_DRIVER(memdsk) = {
+ .id = UCLASS_MEMDISK,
+ .name = "memdsk",
+};
+
+U_BOOT_DRIVER(memdsk) = {
+ .name = "memdsk",
+ .id = UCLASS_MEMDISK,
+};
diff --git a/drivers/memdisk/memdisk.c b/drivers/memdisk/memdisk.c
new file mode 100644
index 0000000000..2c5521a3b6
--- /dev/null
+++ b/drivers/memdisk/memdisk.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Memory disk image
+ *
+ * Copyright (c) 2022, Heinrich Schuchardt <xypron.glpk@gmx.de>
+ */
+
+#include <common.h>
+#include <blk.h>
+#include <dm.h>
+#include <dm/device-internal.h>
+#include <dm/lists.h>
+#include <malloc.h>
+#include <memdisk.h>
+#include <asm/sections.h>
+
+#define LOG_BLK_SIZE 9
+#define BLK_SIZE (1 << LOG_BLK_SIZE)
+
+/**
+ * initr_memdisk() - Initialize embedded memory disk
+ */
+int initr_memdisk(void)
+{
+ memdisk_create(__memdisk_file_begin,
+ __memdisk_file_end - __memdisk_file_begin);
+
+ return 0;
+}
+
+/**
+ * mem_bl_read() - read from block device
+ *
+ * @dev: device
+ * @blknr: first block to be read
+ * @blkcnt: number of blocks to read
+ * @buffer: output buffer
+ * Return: number of blocks transferred
+ */
+static ulong mem_bl_read(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+ void *buffer)
+{
+ struct memdisk_plat *plat = dev_get_plat(dev);
+ char *start = plat->start;
+
+ if (blknr + blkcnt > ((lbaint_t)plat->size >> LOG_BLK_SIZE))
+ return 0;
+ start += blknr << LOG_BLK_SIZE;
+ memcpy(buffer, start, blkcnt << LOG_BLK_SIZE);
+
+ return blkcnt;
+}
+
+/**
+ * memdisk_create() - create memory disk
+ *
+ * The block device will be read-only.
+ * Write support will require security checks using lmb.
+ *
+ * @start: start address
+ * @size size
+ * Return: 0 on success
+ */
+int memdisk_create(void *start, size_t size)
+{
+ struct udevice *dev, *parent = NULL;
+ struct memdisk_plat *plat;
+ char dev_name[20], *strblk, *strdsk;
+ int devnum;
+ int ret;
+
+ devnum = blk_next_free_devnum(IF_TYPE_MEMDISK);
+ snprintf(dev_name, sizeof(dev_name), "memdsk%d", devnum);
+ strdsk = strdup(dev_name);
+ if (!strdsk)
+ return -ENOMEM;
+ /*
+ * This dummy device is only needed due to the broken
+ * blk_get_devnum_by_typename() function which looks at the
+ * parent's uclass instead of the interface type. See
+ * https://lore.kernel.org/all/20211023140647.7661-1-heinrich.schuchardt@canonical.com/
+ */
+ ret = device_bind_driver(gd->dm_root, "memdsk", strdsk, &parent);
+ if (ret) {
+ free(strdsk);
+ return ret;
+ }
+
+ snprintf(dev_name, sizeof(dev_name), "memblk%d", devnum);
+ strblk = strdup(dev_name);
+ if (!strblk) {
+ ret = -ENOMEM;
+ goto err;
+ }
+ ret = blk_create_device(parent, "memblk", strblk,
+ IF_TYPE_MEMDISK, -1, BLK_SIZE,
+ size / BLK_SIZE, &dev);
+ if (ret)
+ goto err;
+
+ plat = dev_get_plat(dev);
+ plat->start = start;
+ plat->size = size;
+
+ ret = blk_probe_or_unbind(dev);
+ if (!ret)
+ return 0;
+
+err:
+ if (parent)
+ device_remove(parent, DM_REMOVE_NORMAL);
+
+ return ret;
+}
+
+/* Block device driver operators */
+static const struct blk_ops mem_blk_ops = {
+ .read = mem_bl_read,
+};
+
+/* Identify as block device driver */
+U_BOOT_DRIVER(memblk) = {
+ .name = "memblk",
+ .id = UCLASS_BLK,
+ .ops = &mem_blk_ops,
+ .plat_auto = sizeof(struct memdisk_plat),
+
+};
diff --git a/drivers/memdisk/memdisk_file.S b/drivers/memdisk/memdisk_file.S
new file mode 100644
index 0000000000..b535ea313e
--- /dev/null
+++ b/drivers/memdisk/memdisk_file.S
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Embedded disk image
+ *
+ * Copyright (c) 2022, Heinrich Schuchardt <xypron.glpk@gmx.de>
+ */
+
+#include <config.h>
+
+.section .rodata.memdisk.init,"a"
+.balign 16
+.global __memdisk_file_begin
+__memdisk_file_begin:
+.incbin CONFIG_MEMDISK_FILE
+.global __memdisk_file_end
+__memdisk_file_end:
+.balign 16
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 267f1db73f..e3aa823870 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -27,6 +27,8 @@ extern char __efi_helloworld_begin[];
extern char __efi_helloworld_end[];
extern char __efi_var_file_begin[];
extern char __efi_var_file_end[];
+extern char __memdisk_file_begin[];
+extern char __memdisk_file_end[];
/* Private data used by of-platdata devices/uclasses */
extern char __priv_data_start[], __priv_data_end[];
diff --git a/include/blk.h b/include/blk.h
index dbe9ae219d..c616ad2e29 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -29,6 +29,7 @@ enum if_type {
IF_TYPE_ATAPI,
IF_TYPE_USB,
IF_TYPE_DOC,
+ IF_TYPE_MEMDISK,
IF_TYPE_MMC,
IF_TYPE_SD,
IF_TYPE_SATA,
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 0e26e1d138..7ef49ec829 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -69,6 +69,7 @@ enum uclass_id {
UCLASS_LED, /* Light-emitting diode (LED) */
UCLASS_LPC, /* x86 'low pin count' interface */
UCLASS_MAILBOX, /* Mailbox controller */
+ UCLASS_MEMDISK, /* Memory disk */
UCLASS_MASS_STORAGE, /* Mass storage device */
UCLASS_MDIO, /* MDIO bus */
UCLASS_MDIO_MUX, /* MDIO MUX/switch */
diff --git a/include/memdisk.h b/include/memdisk.h
new file mode 100644
index 0000000000..a36ffa77d0
--- /dev/null
+++ b/include/memdisk.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Embedded disk image
+ *
+ * Copyright (c) 2022, Heinrich Schuchardt <xypron.glpk@gmx.de>
+ */
+
+/**
+ * initr_memdisk() - Initialize embedded memory disk
+ */
+int initr_memdisk(void);
+
+/**
+ * memdisk_create() - create memory disk
+ *
+ * The block device will be read-only.
+ * Write support will require security checks using lmb.
+ *
+ * @start: start address
+ * @size size
+ * Return: 0 on success
+ */
+int memdisk_create(void *start, size_t size);
+
+struct memdisk_plat {
+ char *start;
+ size_t size;
+};
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 21:16 [PATCH 1/1] drivers: add memory disk support Heinrich Schuchardt
@ 2022-04-19 21:26 ` Tom Rini
2022-04-19 21:55 ` Heinrich Schuchardt
0 siblings, 1 reply; 10+ messages in thread
From: Tom Rini @ 2022-04-19 21:26 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: Simon Glass, u-boot
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
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!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 21:26 ` Tom Rini
@ 2022-04-19 21:55 ` Heinrich Schuchardt
2022-04-19 22:20 ` Heinrich Schuchardt
2022-04-19 22:59 ` Tom Rini
0 siblings, 2 replies; 10+ messages in thread
From: Heinrich Schuchardt @ 2022-04-19 21:55 UTC (permalink / raw)
To: Tom Rini; +Cc: Simon Glass, u-boot
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.
"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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 21:55 ` Heinrich Schuchardt
@ 2022-04-19 22:20 ` Heinrich Schuchardt
2022-04-19 23:01 ` Tom Rini
2022-04-19 22:59 ` Tom Rini
1 sibling, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2022-04-19 22:20 UTC (permalink / raw)
To: Simon Glass; +Cc: u-boot, Tom Rini
On 4/19/22 23:54, Simon Glass wrote:
> Hi Heinrich,
>
> On Tue, 19 Apr 2022 at 15:14, Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> 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>
>> ---
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 21:55 ` Heinrich Schuchardt
2022-04-19 22:20 ` Heinrich Schuchardt
@ 2022-04-19 22:59 ` Tom Rini
2022-04-20 6:58 ` Heinrich Schuchardt
1 sibling, 1 reply; 10+ messages in thread
From: Tom Rini @ 2022-04-19 22:59 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: Simon Glass, u-boot
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 22:20 ` Heinrich Schuchardt
@ 2022-04-19 23:01 ` Tom Rini
2022-04-20 6:48 ` Heinrich Schuchardt
0 siblings, 1 reply; 10+ messages in thread
From: Tom Rini @ 2022-04-19 23:01 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: Simon Glass, u-boot
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
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
> > <heinrich.schuchardt@canonical.com> 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>
> >> ---
> >> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 23:01 ` Tom Rini
@ 2022-04-20 6:48 ` Heinrich Schuchardt
2022-04-20 13:37 ` Tom Rini
0 siblings, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2022-04-20 6:48 UTC (permalink / raw)
To: Tom Rini; +Cc: Simon Glass, u-boot
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
>>> <heinrich.schuchardt@canonical.com> 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>
>>>> ---
>>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-19 22:59 ` Tom Rini
@ 2022-04-20 6:58 ` Heinrich Schuchardt
2022-04-20 13:45 ` Tom Rini
0 siblings, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2022-04-20 6:58 UTC (permalink / raw)
To: Tom Rini; +Cc: Simon Glass, u-boot
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.
>
>> "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.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-20 6:48 ` Heinrich Schuchardt
@ 2022-04-20 13:37 ` Tom Rini
0 siblings, 0 replies; 10+ messages in thread
From: Tom Rini @ 2022-04-20 13:37 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: Simon Glass, u-boot
[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]
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
> > > > <heinrich.schuchardt@canonical.com> 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>
> > > > > ---
> > > > > 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] drivers: add memory disk support
2022-04-20 6:58 ` Heinrich Schuchardt
@ 2022-04-20 13:45 ` Tom Rini
0 siblings, 0 replies; 10+ messages in thread
From: Tom Rini @ 2022-04-20 13:45 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: Simon Glass, u-boot
[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-04-20 13:46 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-19 21:16 [PATCH 1/1] drivers: add memory disk support Heinrich Schuchardt
2022-04-19 21:26 ` Tom Rini
2022-04-19 21:55 ` Heinrich Schuchardt
2022-04-19 22:20 ` Heinrich Schuchardt
2022-04-19 23:01 ` Tom Rini
2022-04-20 6:48 ` Heinrich Schuchardt
2022-04-20 13:37 ` Tom Rini
2022-04-19 22:59 ` Tom Rini
2022-04-20 6:58 ` Heinrich Schuchardt
2022-04-20 13:45 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.