This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/BEAGLEBOARD-X15: AM57xx SDIO issues on MMC1

Part Number: BEAGLEBOARD-X15
Other Parts Discussed in Thread: AM5729, SYSCONFIG, AM5728

Tool/software: Linux

Hi TI,

SDIO device interrupts seem to be lost with the AM57xx MMC1 block (wired to uSD socket on the BeagleBoard-X15). Could you please confirm this? Are you aware of any workarounds? Would it be possible to support SDIO on MMC1?

Thank you for your help, it is very much appreciated.

  • Hello,

    I am wondering if you could please share what you are trying to connect to MMC1 and how you were able to detect the interrupt status. On the beaglex15 board, mmc1 is connected to SD card and the card detect pin is used as a gpio.

    am57xx-beagle-x15-common.dtsi
    
    &mmc1 {
            status = "okay";
    
            pinctrl-names = "default";
            pinctrl-0 = <&mmc1_pins_default>;
    
            bus-width = <4>;
            cd-gpios = <&gpio6 27 GPIO_ACTIVE_LOW>; /* gpio 219 */
    };

     

    Regards,
    Krunal

  • Hi Krunal,

    I'm trying to connect a multi-radio device via SDIO. There is no problem with card detect, I'm using a uSD adapter, which triggers it on insertion. My device is recognized correctly:

    clock: 192000000 Hz
    vdd: 21 (3.3 ~ 3.4 V)
    bus mode: 2 (push-pull)
    chip select: 0 (don't care)
    power mode: 2 (on)
    bus width: 2 (4 bits)
    timing spec: 6 (sd uhs SDR104)
    signal voltage: 1 (1.80 V)
    driver type: 0 (driver type B)

    However, radio device FW command for SDIO function initialization times out in the driver. I think interrupts from my device are not received by the host. Clocking down or using different SDIO devices with slower data rates does not help.

    So, I was looking around and found that SDIO support is only mentioned in the datasheet (http://www.ti.com/lit/ds/symlink/am5729.pdf) for MMC3/MMC4. At the maximum rate of SDR50, so probably at most at 100 MHz... This restriction is also confirmed in dra74x-mmc-iodelay.dtsi in my kernel (4.14.79). But even if MMC3 worked (MMC4 seems to be not available on BBX15) the slower data rate would be sub optimal for our use case.

    Are you aware of any workaround to use UHS-I SDIO devices with the AM5729 with any of the SD/MMC blocks?

    By the way, MMC1 does seem to work with one UHS-I SD card at SDR104 that I tried but again that's not what I need. :(

    Kind regards,

    Tamas

  • Hello Tamas,

    I am wondering if you could please share the rate optimal for your system. 

    Regards,
    Krunal

  • Hi Krunal,

    The maximum SD clock of 192 MHz would be optimal. I enabled cap-sdio-irq for mmc1 in the device tree, to no avail:

    [   57.410190] ti-iodelay 4844a000.padconf: Set reg 0x620 Delay(a: 600 g: 400), Elements(C=1 F=9)0x29029
    [   57.419492] ti-iodelay 4844a000.padconf: Set reg 0x628 Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.428545] ti-iodelay 4844a000.padconf: Set reg 0x62c Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.437545] ti-iodelay 4844a000.padconf: Set reg 0x634 Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.446541] ti-iodelay 4844a000.padconf: Set reg 0x638 Delay(a: 30 g: 0), Elements(C=0 F=0)0x29000
    [   57.455618] ti-iodelay 4844a000.padconf: Set reg 0x640 Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.464618] ti-iodelay 4844a000.padconf: Set reg 0x644 Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.473610] ti-iodelay 4844a000.padconf: Set reg 0x64c Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.482598] ti-iodelay 4844a000.padconf: Set reg 0x650 Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.491585] ti-iodelay 4844a000.padconf: Set reg 0x658 Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.500505] ti-iodelay 4844a000.padconf: Set reg 0x65c Delay(a: 0 g: 0), Elements(C=0 F=0)0x29000
    [   57.549858] mmc0: new ultra high speed SDR104 SDIO card at address 0001
    [   76.516822] cfg80211: Loading compiled-in X.509 certificates for regulatory database
    [   76.569443] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
    [   76.576527] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
    [   76.585276] cfg80211: failed to load regulatory.db
    [   77.738531] random: crng init done
    [   77.741953] random: 2 urandom warning(s) missed due to ratelimiting
    [   78.030907] mwifiex_sdio mmc0:0001:1: info: FW download over, size 616840 bytes
    [   78.631535] mwifiex_sdio mmc0:0001:1: WLAN FW is active
    [   88.811202] mwifiex_sdio mmc0:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0xa9, act = 0x0
    [   88.820045] mwifiex_sdio mmc0:0001:1: num_data_h2c_failure = 0
    [   88.825907] mwifiex_sdio mmc0:0001:1: num_cmd_h2c_failure = 0
    [   88.831681] mwifiex_sdio mmc0:0001:1: is_cmd_timedout = 1
    [   88.837104] mwifiex_sdio mmc0:0001:1: num_tx_timeout = 0
    [   88.842440] mwifiex_sdio mmc0:0001:1: last_cmd_index = 1
    [   88.847778] mwifiex_sdio mmc0:0001:1: last_cmd_id: 00 00 a9 00 00 00 00 00 00 00
    [   88.855207] mwifiex_sdio mmc0:0001:1: last_cmd_act: 00 00 00 00 00 00 00 00 00 00
    [   88.862723] mwifiex_sdio mmc0:0001:1: last_cmd_resp_index = 0
    [   88.868499] mwifiex_sdio mmc0:0001:1: last_cmd_resp_id: 00 00 00 00 00 00 00 00 00 00
    [   88.876365] mwifiex_sdio mmc0:0001:1: last_event_index = 0
    [   88.881877] mwifiex_sdio mmc0:0001:1: last_event: 00 00 00 00 00 00 00 00 00 00
    [   88.889219] mwifiex_sdio mmc0:0001:1: data_sent=1 cmd_sent=1
    [   88.894901] mwifiex_sdio mmc0:0001:1: ps_mode=0 ps_state=0

    root@am57xx-evm:~# cat /sys/kernel/debug/mmc0/ios
    clock:          150000000 Hz
    vdd:            21 (3.3 ~ 3.4 V)
    bus mode:       2 (push-pull)
    chip select:    0 (don't care)
    power mode:     2 (on)
    bus width:      2 (4 bits)
    timing spec:    6 (sd uhs SDR104)
    signal voltage: 1 (1.80 V)
    driver type:    0 (driver type B)

    root@am57xx-evm:~# uname -a
    Linux am57xx-evm 4.19.38-g4dae378bbe #1 SMP PREEMPT Wed Jul 31 15:16:52 UTC 2019 armv7l GNU/Linux

    Thanks for looking into this.

    Kind regards,
    Tamas

  • Hi Krunal,

    I've noticed that MMC1_CLK is only active during CIS read and FW download. It's turned off otherwise.
    Is there a way to keep MMC1_CLK on?

    Kind regards,
    Tamas

  • It seems that the SDHCI platform driver only controls MMCHS_CON[CTPL] and MMCHS_CON[CLKEXTFREE] to maintain card clock out of transfer transaction when SDIO IRQ is to be enabled. But to no avail. This happens to be the case with both MMC1 and MMC3.

    Following the AM572x TRM, when I also involve MMCHS_SYSCTL[CEN], MMCHS_SYSCONFIG[AUTOIDLE] and MMCHS_SYSCONFIG[CLOCKACTIVITY] I still get the same. SD clock is off outside of transactions. Is this a limitation of the AM5729 or my BeagleBoard X15? I do not have other TI SoC to test this with.

  • Hello,

    Based on the data manual, MMC1 interface is compliant with the SD Standard v3.01 and it supports the following SD Card applications:

    • Default speed, 4-bit data, SDR, half-cycle

    • High speed, 4-bit data, SDR, half-cycle

    • SDR12, 4-bit data, half-cycle

    • SDR25, 4-bit data, half-cycle

    • UHS-I SDR50, 4-bit data, half-cycle

    • UHS-I SDR104, 4-bit data, half-cycle

    • UHS-I DDR50, 4-bit data

    Table 7-100 in the AM5728 data manual in section 7.23.1.6 UHS-I SDR104, 4-bit data, half-cycle, it states that the maximum clock rate is 192MHz.  Therefore, assuming you are using the UHS-I SDR104, 4-bit data, half-cycle mode, then 192MHz is supported.

    Regards,
    Krunal