On Tue, Sep 2, 2025 at 11:59 AM Philippe Mathieu-Daudé <phi...@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.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. > > 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
