Re: [PATCH v2 1/8] hw/sd/sdcard: Fix size check for backing block image

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 9375 bytes --]

On Tue, Sep 2, 2025 at 11:59 AM Philippe Mathieu-Daudé <philmd@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.kiszka@siemens.com
> >> <mailto:jan.kiszka@siemens.com>> wrote:
> >>
> >>      On 02.09.25 19:30, Warner Losh wrote:
> >>      >
> >>      >
> >>      > On Tue, Sep 2, 2025 at 11:22 AM Warner Losh <imp@bsdimp.com
> >>      <mailto:imp@bsdimp.com>
> >>      > <mailto:imp@bsdimp.com <mailto:imp@bsdimp.com>>> wrote:
> >>      >
> >>      >
> >>      >
> >>      >     On Tue, Sep 2, 2025 at 11:18 AM Jan Kiszka
> >>      <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> >>      >     <mailto:jan.kiszka@siemens.com
> >>      <mailto:jan.kiszka@siemens.com>>> wrote:
> >>      >
> >>      >         On 02.09.25 19:07, Warner Losh wrote:
> >>      >         >
> >>      >         >
> >>      >         > On Tue, Sep 2, 2025 at 10:49 AM Jan Lübbe
> >>      <jlu@pengutronix.de <mailto:jlu@pengutronix.de>
> >>      >         <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>>
> >>      >         > <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>
> >>      <mailto:jlu@pengutronix.de <mailto:jlu@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

[-- Attachment #2: Type: text/html, Size: 14345 bytes --]