On 02.09.25 18:47, Jan Lübbe 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. >> >> 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). >
Then let's fix the entry check - the code setting up registers to report sizes was reflecting that already. Patch on top, right? Staging is not rebased for updated patches, is it? Jan -- Siemens AG, Foundational Technologies Linux Expert Center
