On 02.09.25 19:48, Warner Losh wrote: > > > On Tue, Sep 2, 2025 at 11:37 AM Jan Kiszka <jan.kis...@siemens.com > <mailto: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> > > <mailto: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> > > <mailto: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>> > > > <mailto: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
< 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. > Argh, then we need to take the card type into account as well. Need to rework my patch... Jan -- Siemens AG, Foundational Technologies Linux Expert Center
