Re: backing storage for eMMC boot partitions

[Cédric Le Goater]

Hello,

[ ... ]

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

Yes. Changes are required in the sdhci model and in the boards using it.

> I've not really understood how to assemble more complex setups using
> qemu's commandline when the board already creates some of the devices.

Yes. That's a "problem" to fix for emmc/sd devices. They should only
be created when defaults_enabled(), just like the flash devices.

> Perhaps Cédric can explain how the different boot options are
> configured for aspeed?

See https://qemu.readthedocs.io/en/v9.1.0/system/arm/aspeed.html#boot-options
and the avocado/functional tests for examples.

The eMMC case is missing from the docs. Here is a proposal :

  https://lore.kernel.org/qemu-devel/20241118090648.187720-1-clg@redhat.com/

Thanks,

C.


> 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-jlu@pengutronix.de/T/
> [2] 
> https://qemu-project.gitlab.io/qemu/system/devices/nvme.html#additional-namespaces