Re: [PATCH v2 1/8] hw/sd/sdcard: Fix size check for backing block image

[Jan Kiszka <jan.kiszka@siemens.com>]

On 02.09.25 19:07, Warner Losh wrote:
> 
> 
> On Tue, Sep 2, 2025 at 10:49 AM Jan Lübbe <jlu@pengutronix.de
> <mailto:jlu@pengutronix.de>> wrote:
> 
>     On Tue, 2025-09-02 at 18:39 +0200, Jan Kiszka wrote:
>     > > > I expect us to be safe and able to deal with non-pow2 regions
>     if we use
>     > > > QEMUSGList from the "system/dma.h" API. But this is a rework
>     nobody had
>     > > > time to do so far.
>     > >
>     > > We have to tell two things apart: partitions sizes on the one
>     side and
>     > > backing storage sizes. The partitions sizes are (to my reading)
>     clearly
>     > > defined in the spec, and the user partition (alone!) has to be
>     power of
>     > > 2. The boot and RPMB partitions are multiples of 128K. The sum
>     of them
>     > > all is nowhere limited to power of 2 or even only multiples of 128K.
>     > >
>     >
>     > Re-reading the part of the device capacity, the rules are more
>     complex:
>     >  - power of two up to 2 GB
>     >  - multiple of 512 bytes beyond that
>     >
>     > So that power-of-two enforcement was and still is likely too strict.
> 
> 
> It is. Version 0 (and MMC) cards had the capacity encoded like so:
>                 m = mmc_get_bits(raw_csd, 128, 62, 12);
>                 e = mmc_get_bits(raw_csd, 128, 47, 3);
>                 csd->capacity = ((1 + m) << (e + 2)) * csd->read_bl_len;
> so any card less than 2GB (well, technically 4GB, but 4GB version 0
> cards were
> rare and broke some stacks... I have one and I love it on my embedded
> ARM board
> that can't do version 1 cards). Version 1 cards encoded it like:
>                 csd->capacity = ((uint64_t)mmc_get_bits(raw_csd, 128,
> 48, 22) +
>                     1) * 512 * 1024;
> So it's a multiple of 512k. These are also called 'high capacity' cards.
> 
> Version 4 introduces an extended CSD, which had a pure sector count in
> the EXT CSD. I think this
> is only for MMC cards. And also the partition information.
>  
> 
>     > But I still see no indication, neither in the existing eMMC code
>     of QEMU
>     > nor the spec, that the boot and RPMB partition sizes are included
>     in that.
> 
>     Correct. Non-power-of-two sizes are very common for real eMMCs.
>     Taking a random
>     one from our lab:
>     [    1.220588] mmcblk1: mmc1:0001 S0J56X 14.8 GiB
>     [    1.228055]  mmcblk1: p1 p2 p3 p4
>     [    1.230375] mmcblk1boot0: mmc1:0001 S0J56X 31.5 MiB
>     [    1.233651] mmcblk1boot1: mmc1:0001 S0J56X 31.5 MiB
>     [    1.236682] mmcblk1rpmb: mmc1:0001 S0J56X 4.00 MiB, chardev (244:0)
> 
>     For eMMCs using MLC NAND, you can also configure part of the user
>     data area to
>     be pSLC (pseudo single level cell), which changes the available
>     capacity (after
>     a required power cycle).
> 
> 
> Yes. Extended partitions are a feature of version 4 cards, so don't have
> power-of-2 limits since they are a pure sector count in the ext_csd.
> 

JESD84-B51A (eMMC 5.1A):

"The C_SIZE parameter is used to compute the device capacity for devices
up to 2 GB of density. See 7.4.52, SEC_COUNT [215:212] , for details on
calculating densities greater than 2 GB."

So I would now continue to enforce power-of-2 for 2G (including) cards,
and relax to multiples of 512 for larger ones.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center