From: Jan Kiszka <jan.kiszka@siemens.com>
Enable user-instantiation so that PCI-attached eMMCs can be created for
virt machines, for QA purposes for the eMMC model itself and for complex
firmware/OS integrations using the upcoming RPMB partition support.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
hw/sd/sd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index d1e1bb4f0e..305ea251cb 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -2928,8 +2928,6 @@ static void emmc_class_init(ObjectClass *klass, const void *data)
dc->desc = "eMMC";
dc->realize = emmc_realize;
device_class_set_props(dc, emmc_properties);
- /* Reason: Soldered on board */
- dc->user_creatable = false;
sc->proto = &sd_proto_emmc;
--
2.51.0On Fri, 2025-10-17 at 14:03 +0200, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > Enable user-instantiation so that PCI-attached eMMCs can be created for > virt machines, for QA purposes for the eMMC model itself and for complex > firmware/OS integrations using the upcoming RPMB partition support. Perhaps reword to "Enable user-instantiation so that eMMCs can be created for PCI-attached SD/MMC host controllers (such as sdhci-pci) on virt machines, ..." to match the actual bus hierarchy? Jan > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > hw/sd/sd.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/hw/sd/sd.c b/hw/sd/sd.c > index d1e1bb4f0e..305ea251cb 100644 > --- a/hw/sd/sd.c > +++ b/hw/sd/sd.c > @@ -2928,8 +2928,6 @@ static void emmc_class_init(ObjectClass *klass, const void *data) > dc->desc = "eMMC"; > dc->realize = emmc_realize; > device_class_set_props(dc, emmc_properties); > - /* Reason: Soldered on board */ > - dc->user_creatable = false; > > sc->proto = &sd_proto_emmc; > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 30.10.25 17:50, Jan Lübbe wrote: > On Fri, 2025-10-17 at 14:03 +0200, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> Enable user-instantiation so that PCI-attached eMMCs can be created for >> virt machines, for QA purposes for the eMMC model itself and for complex >> firmware/OS integrations using the upcoming RPMB partition support. > > Perhaps reword to "Enable user-instantiation so that eMMCs can be created for > PCI-attached SD/MMC host controllers (such as sdhci-pci) on virt machines, ..." > to match the actual bus hierarchy? > Sounds better to me as well. Can update this patch if desired, but I don't want to repost everything just for that now. Or Philippe just folds this in while merging if that is all. Thanks, Jan -- Siemens AG, Foundational Technologies Linux Expert Center
On Fri, Oct 17, 2025 at 02:03:54PM +0200, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > Enable user-instantiation so that PCI-attached eMMCs can be created for > virt machines, for QA purposes for the eMMC model itself and for complex > firmware/OS integrations using the upcoming RPMB partition support. IIUC, the 'emmc' device wants an 'sd-bus' but this commit talks about it being PCI-attached ? Can you elaborate on / illustrate the usage example for an end user ? > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > hw/sd/sd.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/hw/sd/sd.c b/hw/sd/sd.c > index d1e1bb4f0e..305ea251cb 100644 > --- a/hw/sd/sd.c > +++ b/hw/sd/sd.c > @@ -2928,8 +2928,6 @@ static void emmc_class_init(ObjectClass *klass, const void *data) > dc->desc = "eMMC"; > dc->realize = emmc_realize; > device_class_set_props(dc, emmc_properties); > - /* Reason: Soldered on board */ > - dc->user_creatable = false; > > sc->proto = &sd_proto_emmc; > > -- > 2.51.0 > > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 27/10/25 12:55, Daniel P. Berrangé wrote: > On Fri, Oct 17, 2025 at 02:03:54PM +0200, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> Enable user-instantiation so that PCI-attached eMMCs can be created for >> virt machines, for QA purposes for the eMMC model itself and for complex >> firmware/OS integrations using the upcoming RPMB partition support. > > IIUC, the 'emmc' device wants an 'sd-bus' but this commit talks about > it being PCI-attached ? Sigh, it should not, but it got introduced this way and we didn't have time / energy / good reason to rework the code, which currently just works. SD / MMC cards -> plugged over external SD bus embedded MMC cards -> no SD bus, directly mmio-mapped. > > Can you elaborate on / illustrate the usage example for an end user ? Saving time by testing virtual hardware, without having to implement a real model. Personally I'm not in favor of modelling unspecified devices (IOW not following a spec). But I can understand QEMU usefulness with fast HW prototyping. > >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> hw/sd/sd.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/hw/sd/sd.c b/hw/sd/sd.c >> index d1e1bb4f0e..305ea251cb 100644 >> --- a/hw/sd/sd.c >> +++ b/hw/sd/sd.c >> @@ -2928,8 +2928,6 @@ static void emmc_class_init(ObjectClass *klass, const void *data) >> dc->desc = "eMMC"; >> dc->realize = emmc_realize; >> device_class_set_props(dc, emmc_properties); >> - /* Reason: Soldered on board */ >> - dc->user_creatable = false; >> >> sc->proto = &sd_proto_emmc; >> >> -- >> 2.51.0 >> >> > > With regards, > Daniel
On Mon, 2025-10-27 at 13:23 +0100, Philippe Mathieu-Daudé wrote: > On 27/10/25 12:55, Daniel P. Berrangé wrote: > > On Fri, Oct 17, 2025 at 02:03:54PM +0200, Jan Kiszka wrote: > > > From: Jan Kiszka <jan.kiszka@siemens.com> > > > > > > Enable user-instantiation so that PCI-attached eMMCs can be created for > > > virt machines, for QA purposes for the eMMC model itself and for complex > > > firmware/OS integrations using the upcoming RPMB partition support. > > > > IIUC, the 'emmc' device wants an 'sd-bus' but this commit talks about > > it being PCI-attached ? > > Sigh, it should not, but it got introduced this way and we didn't > have time / energy / good reason to rework the code, which currently > just works. > > SD / MMC cards -> plugged over external SD bus > > embedded MMC cards -> no SD bus, directly mmio-mapped. Hmm. This is not how I'd describe it and I've not seen directly MMIO mapped MMC cards. Both eMMCs and SD cards are separate/physical devices connected via an SD/MMC bus to a host controller. As both protocols are closely related, host controller usually implement both protocols and can detect which one to use at runtime. The host controller is connected to the CPU via a different bus, usually PCI(e) (e.g. in a notebook) or just MMIO mapped (e.g. in an ARM SoC). SDHCI is the most common interface spec for SD/MMC controlers. So, you need to create two device (eMMC + SDHCI) for this to work with a generic x86_64 VM: -drive if=none,id=emmc-drive,file=emmc.img,format=raw \ -device sdhci-pci \ -device emmc,id=emmc0,drive=emmc-drive,boot-partition-size=1048576 \ If you emulate a machine/SoC which already has an integrated SD/MMC host controler, you'd leave out the sdhci-pci device. Regards, Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Mon, Oct 27, 2025 at 01:23:56PM +0100, Philippe Mathieu-Daudé wrote: > On 27/10/25 12:55, Daniel P. Berrangé wrote: > > On Fri, Oct 17, 2025 at 02:03:54PM +0200, Jan Kiszka wrote: > > > From: Jan Kiszka <jan.kiszka@siemens.com> > > > > > > Enable user-instantiation so that PCI-attached eMMCs can be created for > > > virt machines, for QA purposes for the eMMC model itself and for complex > > > firmware/OS integrations using the upcoming RPMB partition support. > > > > IIUC, the 'emmc' device wants an 'sd-bus' but this commit talks about > > it being PCI-attached ? > > Sigh, it should not, but it got introduced this way and we didn't > have time / energy / good reason to rework the code, which currently > just works. > > SD / MMC cards -> plugged over external SD bus > > embedded MMC cards -> no SD bus, directly mmio-mapped. > > > > > Can you elaborate on / illustrate the usage example for an end user ? > > Saving time by testing virtual hardware, without having to implement a > real model. Ok, more specifically, what are the suggested QEMU command line args to make use of this with PCI ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 27/10/25 13:35, Daniel P. Berrangé wrote: > On Mon, Oct 27, 2025 at 01:23:56PM +0100, Philippe Mathieu-Daudé wrote: >> On 27/10/25 12:55, Daniel P. Berrangé wrote: >>> On Fri, Oct 17, 2025 at 02:03:54PM +0200, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> >>>> Enable user-instantiation so that PCI-attached eMMCs can be created for >>>> virt machines, for QA purposes for the eMMC model itself and for complex >>>> firmware/OS integrations using the upcoming RPMB partition support. >>> >>> IIUC, the 'emmc' device wants an 'sd-bus' but this commit talks about >>> it being PCI-attached ? >> >> Sigh, it should not, but it got introduced this way and we didn't >> have time / energy / good reason to rework the code, which currently >> just works. >> >> SD / MMC cards -> plugged over external SD bus >> >> embedded MMC cards -> no SD bus, directly mmio-mapped. >> >>> >>> Can you elaborate on / illustrate the usage example for an end user ? >> >> Saving time by testing virtual hardware, without having to implement a >> real model. > > Ok, more specifically, what are the suggested QEMU command line > args to make use of this with PCI ? See patch #6 documentation: + -drive file=emmc.img,if=none,format=raw,id=emmc-img + -device sdhci-pci + -device emmc,drive=emmc-img,boot-partition-size=1048576,rpmb-partition-size=2097152
On Mon, 2025-10-27 at 13:44 +0100, Philippe Mathieu-Daudé wrote:
> On 27/10/25 13:35, Daniel P. Berrangé wrote:
> > On Mon, Oct 27, 2025 at 01:23:56PM +0100, Philippe Mathieu-Daudé wrote:
> > > On 27/10/25 12:55, Daniel P. Berrangé wrote:
> > > > On Fri, Oct 17, 2025 at 02:03:54PM +0200, Jan Kiszka wrote:
> > > > > From: Jan Kiszka <jan.kiszka@siemens.com>
> > > > >
> > > > > Enable user-instantiation so that PCI-attached eMMCs can be created for
> > > > > virt machines, for QA purposes for the eMMC model itself and for complex
> > > > > firmware/OS integrations using the upcoming RPMB partition support.
> > > >
> > > > IIUC, the 'emmc' device wants an 'sd-bus' but this commit talks about
> > > > it being PCI-attached ?
> > >
> > > Sigh, it should not, but it got introduced this way and we didn't
> > > have time / energy / good reason to rework the code, which currently
> > > just works.
> > >
> > > SD / MMC cards -> plugged over external SD bus
> > >
> > > embedded MMC cards -> no SD bus, directly mmio-mapped.
> > >
> > > >
> > > > Can you elaborate on / illustrate the usage example for an end user ?
> > >
> > > Saving time by testing virtual hardware, without having to implement a
> > > real model.
> >
> > Ok, more specifically, what are the suggested QEMU command line
> > args to make use of this with PCI ?
>
> See patch #6 documentation:
>
> + -drive file=emmc.img,if=none,format=raw,id=emmc-img
> + -device sdhci-pci
> + -device
> emmc,drive=emmc-img,boot-partition-size=1048576,rpmb-partition-size=2097152
For example, our current use for an earlier variant of this can be seen here:
https://github.com/rauc/rauc/blob/master/qemu-test#L79
if "$QEMU_BIN" -device help | grep -q 'name "emmc"'; then
echo "found emmc support, enabling"
truncate -s 64M qemu-test-emmc.img
QEMU_ARGS="$QEMU_ARGS -drive if=none,id=emmc-drive,file=qemu-test-emmc.img,format=raw"
QEMU_ARGS="$QEMU_ARGS -device sdhci-pci"
QEMU_ARGS="$QEMU_ARGS -device emmc,id=emmc0,drive=emmc-drive,boot-partition-size=1048576"
fi
We enable this only if our patched version of qemu [1] is found. For ARM
bootloader (OP-TEE and barebox) development and regression testing, we'd use
this as well (with the RPMB emulation). Avoiding the need for a custom QEMU
build would help a lot. :)
Best regards,
Jan
[1] https://github.com/qemu/qemu/compare/master...jluebbe:qemu:user-emmc#diff-e90f7f7336bf488567604b94aa0a3f5d272e392bca2e1e5c33c65f094c18466d
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
© 2016 - 2025 Red Hat, Inc.