On Tue, Sep 2, 2025 at 11:59 AM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

On 2/9/25 19:53, Jan Kiszka wrote:
> On 02.09.25 19:48, Warner Losh wrote:
>>
>>
>> On Tue, Sep 2, 2025 at 11:37 AM Jan Kiszka <jan.kiszka@siemens.com
>> <mailto:jan.kiszka@siemens.com>> wrote:
>>
>> On 02.09.25 19:30, Warner Losh wrote:
>> >
>> >
>> > On Tue, Sep 2, 2025 at 11:22 AM Warner Losh <imp@bsdimp.com
>> <mailto:imp@bsdimp.com>
>> > <mailto:imp@bsdimp.com <mailto:imp@bsdimp.com>>> wrote:
>> >
>> >
>> >
>> > On Tue, Sep 2, 2025 at 11:18 AM Jan Kiszka
>> <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
>> > <mailto:jan.kiszka@siemens.com
>> <mailto:jan.kiszka@siemens.com>>> wrote:
>> >
>> > 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>
>> > <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>>
>> > > <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>
>> <mailto: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.
>> >
>> >
>> > It's a multiple of 512k unless the card has a ext_csd, in
>> which case
>> > it's a multiple of 512.
>> >
>> >
>> > More completely, this is from MMC 4.0 and newer. Extended Capacity SD
>> > cards report this in units of 512k bytes for all cards > 2GiB.
>> >
>>
>> I'm not sure which spec version you are referring to, but JESD84-A441
>> and JESD84-B51A mention nothing about 512K, rather "Device density =
>> SEC_COUNT x 512B". And these are the specs we very likely need to follow
>> here.
>>
>>
>> You are right that this is in the MMC spec. However, the SD spec is
>> controlling for SD cards.
>>
>> SD Specifications Part 1 Physical Layer Simplified Specification Version
>> 9.10
>> December 1, 2023
>>
>> Section 5.3 describes the CSD. Version 1.0 (which I'd called version 0
>> in an earlier email because of its encoding) is the 2GB rule. Version
>
> < 2G or <= 2G? For eMMC, it is <=.
>
>> 2.0 and 3.0 encode it as 512k count (from 5.3.3):
>>
>> C_SIZE
>> This field is expanded to 28 bits and can indicate up to 128 TBytes.
>>
>> This parameter is used to calculate the user data area capacity in the
>> SD memory card (note that size of the protected area is zero for SDUC
>> card). The user data area capacity is calculated from C_SIZE as follows:
>>
>> memory capacity = (C_SIZE+1) * 512KByte
>>
>> The Minimum user area size of SDUC Card is 4,294,968,320 sectors
>> (2TB+0.5MB).
>> The Minimum value of C_SIZE for SDUC in CSD Version 3.0 is 0400000h
>> (4194304). The Maximum user area size of SDUC Card is 274,877,906,944
>> sectors (128TB).
>> The Maximum value of C_SIZE for SDUC in CSD Version 3.0 is FFFFFFFh
>> (268435455).
>>
>> So SD cards are yet again gratuitously different than MMC cards.

FTR so far QEMU only models SD spec v2.00 and v3.01, and eMMC spec 4.3.

IIRC (I can't find the old copies of the spec I used), the SD Spec 2.0 introduced the 512k thing with its new CSD for cards larger than 2GiB. I had to retrofit my stack, which I'd written to the SD 1.0 spec for it. Later versions (I'm not sure which ones) expanded the field size to what I aquoted. eMMC introduced EXT_CSD in version 4.0, which has the 512 byte restriction and also partitions (since MMC didn't introduce a new CSD like SD did). The successor eMMC spec is what Jan was quoting.

Warner