Re: SDIO "SD2" vs. SD-card "SD3" interface on BayTrail

[Adrian Hunter <adrian.hunter@intel.com>]

On 07/10/17 11:25, Stefan Roese wrote:
> Hi,
> 
> On 31.08.2017 14:41, Adrian Hunter wrote:
>> On 31/08/17 12:38, Stefan Roese wrote:
>>> Hi Andy, Hi Adrian,
>>>
>>> On 04.07.2017 15:53, Andy Shevchenko wrote:
>>>> On Tue, 2017-07-04 at 14:53 +0200, Stefan Roese wrote:
>>>>> Hi,
>>>>>
>>>>> we are currently investigating, if its possible to connect a SDIO
>>>>> device (WLAN module) to the SD-card interface "SD3" of the BayTrail
>>>>> SoC instead of the SDIO interface "SD2". The BayTrail manual states,
>>>>> that the SDIO interface is capable of connecting SDIO devices. Is
>>>>> this also possible for the SD-card interface "SD3", even if its not
>>>>> explicitly mentioned in the manual? If not, why is this not possible?
>>>>>
>>>>> Any insight on this would be really helpful.
>>>>
>>>> Hmm... I have no documentation for SD/SDIO/eMMC for BayTrail except the
>>>> public one. Internally I found some charts that shows similarities
>>>> between two. So, taking that into consideration I would suggest to try
>>>> it out on real hardware (MinnowBoard MAX, for example), only impediment
>>>> I can see is the absence of support in the drivers in Linux OS. If you
>>>> need it only in U-Boot, you perhaps may fix it easily.
>>>>
>>>> P.S. Adrian on vacation.
>>>
>>> I hope your vacation was great!
>>>
>>> Sorry for getting back to this, but I would really like to get some
>>> more feedback on this. Perhaps Adrian has some additional comments
>>> about the SDIO usage of the SD interface (SD3 - PCI Device ID 0x0f16)
>>> on BayTrail.
>>>
>>> I'm now running latest mainline Linux on this board and am trying to
>>> get the Linux MMC / SDIO subsystem to just detect a device on this
>>> SD PCI interface. For this I have added quite a bit of debug code to
>>> the MMC / SDIO code to see, if any device is detected on the SDIO
>>> port. But all command queries return timeout as far as I can tell.
>>
>> I would usually interpret that to mean the SDIO card is not turned on.
>>
>>> Adrian, do you have some additional information, if this mode of
>>> operation is possible at all on this SD-card interface, even if
>>> its not explicitly mentioned in the BayTrail datasheet?
>>
>> I have used removable SDIO cards in SD slots before.  It should work.
> 
> A quick update with another question below:
> 
> After getting back to this issue, I now have the SD-card detection
> working, if I boot into Linux using U-Boot as bootloader on this
> BayTrail based board. But when I boot via original BIOS, the card
> detection fails. While debugging, I found that one register differs
> in both setups:
> 
> U-Boot:
> [    2.374751] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [    2.374761] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x0000b502
> [    2.374768] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
> [    2.374774] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
> [    2.374781] mmc0: sdhci: Present:   0x1fff0000 | Host ctl: 0x00000000
> [    2.374787] mmc0: sdhci: Power:     0x00000000 | Blk gap:  0x00000000
> [    2.374793] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000000
> [    2.374799] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
> [    2.374806] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
> [    2.374812] mmc0: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000000
> [    2.374819] mmc0: sdhci: Caps:      0x076864b2 | Caps_1:   0x00000000
> [    2.374825] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
> [    2.374831] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
> [    2.374837] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
> [    2.374842] mmc0: sdhci: Host ctl2: 0x00000000
> [    2.374849] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
> [    2.374853] mmc0: sdhci: ============================================
> 
> BIOS:
> [    3.435179] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [    3.435485] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x0000b502
> [    3.435756] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
> [    3.436066] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
> [    3.436338] mmc0: sdhci: Present:   0x01ff0000 | Host ctl: 0x00000000
> [    3.436603] mmc0: sdhci: Power:     0x00000000 | Blk gap:  0x00000000
> [    3.436868] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000000
> [    3.437166] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
> [    3.437437] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
> [    3.437704] mmc0: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000000
> [    3.437969] mmc0: sdhci: Caps:      0x076864b2 | Caps_1:   0x00000000
> [    3.438266] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
> [    3.438537] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
> [    3.438802] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
> [    3.439135] mmc0: sdhci: Host ctl2: 0x00000000
> [    3.439334] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
> [    3.439598] mmc0: sdhci: ============================================
> 
> As you can see, the "present" register (SDHCI_PRESENT_STATE at 0x24) is
> different. Its read-only - do you have any idea, why this register is
> set to the non-default value of 0x01ff0000 in the BIOS case?
> 
> BTW: Its set to the default value of 0x1fff0000 for the eMMC controller
> in the BIOS case as well. So only the SD controller has this different

Those pins are DAT[7:4] line signal level.  SD has only 4 lines so the
values perhaps change depending on what the setup has been done for the pin
controller.