On Tue, 2024-10-29 at 07:40 -0700, Guenter Roeck wrote:
> On 10/28/24 01:41, Jan Lübbe wrote:
> > On Sun, 2024-10-27 at 20:32 -0700, Guenter Roeck wrote:
> > > On 10/27/24 15:26, Cédric Le Goater wrote:
> > > > On 10/27/24 23:11, Guenter Roeck wrote:
> > > > > On 10/27/24 14:13, Cédric Le Goater wrote:
> > > > > > On 10/26/24 17:32, Guenter Roeck wrote:
> > > > > > > On 10/26/24 03:02, Cédric Le Goater wrote:
> > > > > > > [ ... ]
> > > > > > >
> > > > > > > >
> > > > > > > Works for me, though, and it is much better than mandating the
> > > > > > > existence
> > > > > > > of boot partitions.
> > > > > >
> > > > > > Yes. However, if the emmc device was user creatable, we could use :
> > > > > >
> > > > > > -blockdev
> > > > > > node-name=emmc0,driver=file,filename=mmc-ast2600-evb-noboot.raw \
> > > > > > -device emmc,bus=sdhci-bus.2,drive=emmc0
> > > > > >
> > > > > > and with boot partitions:
> > > > > >
> > > > > > -M boot-emmc=true \
> > > > > > -blockdev
> > > > > > node-name=emmc0,driver=file,filename=mmc-ast2600-evb.raw \
> > > > > > -device
> > > > > > emmc,bus=sdhci-bus.2,drive=emmc0,boot-partition-size=1048576,boot-config=8
> > > > > >
> > > > > > The above would be my preferred approach if acceptable. The "sd-bus"
> > > > > > bus identifier should be changed in other machines tough.
> > > > >
> > > > > No real preference here, though my understanding is that emmc devices
> > > > > are by definition built-in, and that is what emmc_class_init() says
> > > > > as well.
> > > > > Also, there does not seem to be an sdhci-bus, only sd-bus, and that
> > > > > does
> > > > > not support any index values. That may be just my lack of knowledge,
> > > > > though.
> > > >
> > > > No, you are right. On a real ast2600-evb, the eMMC device is indeed
> > > > soldered on the board. But, for testing purposes, it is sometime
> > > > interesting to add some flexibility in the machine definition and
> > > > in the modeling too. This avoids "hard-coding" default devices in
> > > > the machines and lets the user define its own variant models using
> > > > the QEMU command line.
> > >
> > > I would agree, but I had a number of my patches rejected because while
> > > they would be useful for testing they would not accurately reflect the
> > > hardware. So nowadays I gave up even trying to upstream such changes.
> >
> > My patch to make eMMCs user creatable [1] was applied to target-
> > arm.next by Peter Maydell [2] last week.
> >
>
> That works for me with
>
> drivecmd="-drive file=${ROOTFS},format=raw,if=none,id=d0"
> drivecmd+=" -device emmc,drive=d0"
>
> but unless I am missing something
>
> drivecmd="-drive file=${ROOTFS},format=raw,if=none,id=d0"
> drivecmd+=" -device sd-card,drive=d0"
>
> also boots from the emmc controller. How do I provide the
> bus and bus index ? "bus=sdhci-bus.2" doesn't work for me.
> There is "sd-bus", but it does not have an index.
I've not really understood how to assemble more complex setups using
qemu's commandline when the board already creates some of the devices.
Perhaps Cédric can explain how the different boot options are
configured for aspeed?
I see three cases:
1. specify the blockdev driver and options in the simple case where the
board already creates the SD or eMMC device
2. specify some custom options for the eMMC
3. create a custom eMMC config on a generic machine via sdhci-pci
Case 1 is probably most common. The user has chosen a board and just
wants to boot a rootfs image and doesn't care about boot partitions or
anything else eMMC-specific.
Some users may want to emulate an eMMC with boot partitions, as that
allows them to emulate their physical boards more closely (case 2).
Note that eMMC boot partitions are usually *not* used for storing a
Linux kernel, but for the bootloader (including things like u-boot, TF-
A, OP-TEE, ...). The ROM-code on many SoCs supports loading directly
from eMMC boot partitions. One of the two boot partitions can be
activated with an atomic eMMC EXT CSD register write, allowing atomic
bootloader updates. I think this case was the motivation for Cédric's
eea55625df83 ("aspeed: Introduce a AspeedSoCClass 'boot_from_emmc'
handler").
These users are likely fine with assembling a backing file consisting
of e.g.
- bootloader image (boot0) @ offset 0MiB
- empty space for bootloader updates (boot1) @ offset 1MiB
- partitioned disk image (rootfs, ...) @ offset 2MiB
to get the same setup as their real hardware.
Case 3 is what I want to use the eMMC emulator for: Test eMMC-specific
functionality in Linux userspace, specifically the boot partition
update backend for RAUC, in a CI setup. To improve performance and
because we don't need to emulate any specific board for CI, we use an
x86 guest (q35). As it has PCIe, the easiest way to add the necessary
eMMC emulation is to use sdhci-pci. That was the motivation behind my
patch "hw/sd/sdcard: Allow user creation of eMMCs" [1].
For that case, having one backing file for boot partitions + main area
is fine as well.
If we wanted more flexibility via separate backing files per eMMC
partitions, it might work similar to NVMe Namespaces [2]. For me, that
seems like a lot of complexity a very niche case like eMMC boot
partitions.
Potential future features such as more eMMC data partitions, RPMB
support or separate backing files could be support in QEMU by new eMCC
device options or even additional devices (following the NVMe
approach), without breaking backwards compatibility.
So it seems to me, that Cédric's approach of enabling boot partitions
in hw/arm/aspeed.c only when configured to boot from them via the "hw-
strap1" property should solve cases 1 and 2 without introducing
backwards compatibility issues. Case 3 has explicit configuration (if a
boot partition is emulated), so shouldn't be a problem either.
Thanks,
Jan
[1]
https://lore.kernel.org/qemu-devel/20241015135649.4189256-1-...@pengutronix.de/T/
[2]
https://qemu-project.gitlab.io/qemu/system/devices/nvme.html#additional-namespaces
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
