On Tue, Sep 2, 2025 at 11:22 AM Warner Losh <[email protected]> wrote:
> > > On Tue, Sep 2, 2025 at 11:18 AM Jan Kiszka <[email protected]> wrote: > >> On 02.09.25 19:07, Warner Losh wrote: >> > >> > >> > On Tue, Sep 2, 2025 at 10:49 AM Jan Lübbe <[email protected] >> > <mailto:[email protected]>> 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. Warner
