Re: [PATCH v6 3/3] arm64:?==?utf-8?q? dts: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

Hello Naoki,

On Thursday, November 06, 2025 00:38 CET, FUKAUMI Naoki <naoki at radxa.com> wrote:
> On 11/6/25 03:27, Jimmy Hon wrote:
> > On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki at radxa.com> wrote:
> >>
> >> The Radxa CM5 IO Board is an application board for the Radxa CM5.
> >>
> >> Specification:
> > 
> >> - 1x microSD card slot
> > 
> > [ snip ]
> > 
> >> +
> >> +&sdmmc {
> >> +       bus-width = <4>;
> >> +       cap-mmc-highspeed;
> >> +       cap-sd-highspeed;
> >> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> >> +       disable-wp;
> >> +       no-sdio;
> >> +       pinctrl-names = "default";
> >> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
> >> +       sd-uhs-sdr104;
> >> +       vmmc-supply = <&vcc_3v3_s3>;
> >> +       vqmmc-supply = <&vccio_sd_s0>;
> >> +       status = "okay";
> >> +};
> > 
> > When used as a TF slot, shouldn't there be a "no-mmc" also?
> 
> We have "eMMC to uSD."
>   https://radxa.com/products/accessories/emmc-to-usd
> 
> [  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 
> 52000000Hz, actual 49500000HZ div = 0)
> [  202.178477] mmc1: new high speed MMC card at address 0001
> [  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
> [  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
> [  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
> [  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)
> 
> (I'm not sure why it says "Not work with the SD slot on the board." I 
> will check.)

Thanks for bringing this up, I've always wondered how are such
simple eMMC-to-microSD adapters supposed to work, so this was
a good opportunity to research that a bit further.

In a few words, they're not supposed to work in true microSD card
slots, and they seem to rely on USB card readers that support
multiple card interface standards, but not more than a single card
at once, by wiring their single interface lines in parallel to the
different types of card slots that they provide.

To explain it a bit further, an eMMC chip supports different data
bus widths and a backward-compatible MMC card mode, but they have
very little knowledge about the SD specification, despite being
somewhat similar; the exception is the simplified eMMC boot mode.
This is explained further in the JEDEC JESD84-B51 standard, which
is available freely from the JEDEC website after registration.

This is also confirmed by the kernel messages quoted above, which
show that the eMMC chip is detected as an MMC card this way.

With all that in mind, we should specify "no-mmc" here, because
we're describing a microSD slot, instead of describing some hybrid
MMC/microSD slot.  That also explains why the adapter sold by Radxa
is described as not to be used with microSD card slots on SBCs.  I'd
also like to hear is this adapter/eMMC chip combo recognized by the
kernel when "no-mmc" is specified; it should fail.

Actually, not specifying "no-mmc" here may result in some unforeseen
issues with some (or perhaps many?) microSD cards, because the MMC
drivers will treat them as MMC-capable devices and try to initialize
them as such, which may cause all kinds of issues.  In fact, I'm not
really sure that the MMC drivers are actually implemented in a way
that avoids all possible issues with the storage controllers that
are capable of both SD and MMC modes when neither of "no-sd" and
"no-mmc" is specified in their DT nodes.

Furthermore, it seems that specifying "cap-mmc-highspeed" together
with "no-emmc" is actually redundant, which would make sense, but
further research of the MMC drivers is needed.  I've added that to
my ever-growing TODO list. :)

> > That's how the Rock 5A, 5B, and 5C were defined.
> 
> I have submitted a patch without "no-mmc" before. I intend to send one 
> again when I have the chance.