On Tue, Sep 2, 2025 at 11:37 AM Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 02.09.25 19:30, Warner Losh wrote: > > > > > > On Tue, Sep 2, 2025 at 11:22 AM Warner Losh <i...@bsdimp.com > > <mailto:i...@bsdimp.com>> wrote: > > > > > > > > On Tue, Sep 2, 2025 at 11:18 AM Jan Kiszka <jan.kis...@siemens.com > > <mailto:jan.kis...@siemens.com>> wrote: > > > > On 02.09.25 19:07, Warner Losh wrote: > > > > > > > > > On Tue, Sep 2, 2025 at 10:49 AM Jan Lübbe <j...@pengutronix.de > > <mailto:j...@pengutronix.de> > > > <mailto:j...@pengutronix.de <mailto:j...@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 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. Warner
