[PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

Hi Dragan,

On 11/6/25 12:31, Dragan Simic wrote:
> 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.

I have no objection to specifying no-mmc (and removing 
cap-mmc-highspeed). We have a USB eMMC/UFS Module Reader, which is much 
faster than an eMMC to uSD reader :)

> 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. :)

Good luck with your ever-growing TODO list!

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

>>> 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.
> 
>