[Letux-kernel] X1600 / LX16 support - here: adding MMC

H. Nikolaus Schaller hns at goldelico.com
Thu Feb 8 16:29:06 CET 2024



> Am 08.02.2024 um 14:06 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Wed, 7 Feb 2024 21:32:56 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>>> Am 07.02.2024 um 21:26 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> On Wed, 7 Feb 2024 20:43:50 +0100
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>>>> Am 07.02.2024 um 20:21 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>>> 
>>>>> On Wed, 7 Feb 2024 17:05:25 +0100
>>>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:    
>>>>>> IMHO, this are all secondary messages after the SD card isn't found.
>>>>>> 
>>>>> no rootwait? Is it simply just not waiting for the root device?    
>>>> 
>>>> Indeed there is none in the kernel command line as I had saved after fixing the U-Boot issue:
>>>> 
>>> Well, I added it and got now:  
>> 
>> Should we add this to U-Boot or better to CONFIG_CMDLINE?
>> 
> well, we have it in CONFIG_CMDLINE on other devices I think.

Ok, so let's add it there.

> Basically you need is more often if somehow async probe and enumerations
> are used. 
> Nowadays it is often practically implemented in initramfs/initrd.
> 
> Maybe we should use one to have more debug capabilities (kprobes,epbf,etc.)
> see
> 
> https://fosdem.org/2024/events/attachments/fosdem-2024-3222-linux-matchmaking-helping-devices-and-drivers-find-each-other/slides/22695/linux-matchmaking_Kb0f8OH.pdf
> 
> Keyword tracing.

Interesting stuff. Well, there would be kdb for ages but I never got it working :)
Then we could set a breakpoint at mmc_probe and look what happens.

An even more ancient technology is to insert printk() :)

So at the moment I am trying to better understand the logs...

Inserting some µSD in the second slot makes no clear difference.

Interestingly (strangely?) there is both:

[    0.000203] mmc0: error -145 whilst initialising SD card
[    0.000203] mmc0: error -145 whilst initialising MMC card

So why is it alternatingly trying to initialize MMC and SD card mode?
Is this expected behavior?
 
Yes... :

There is probing for SDIO, SD, MMC depending on capabilities in mmc_rescan_try_freq()
https://elixir.bootlin.com/linux/v6.8-rc3/source/drivers/mmc/core/core.c#L2054

Next question :)

mmc_attach_sdio() tries to set the voltage.
This triggers "card claims to support voltages below defined range"

Apparently because some of the lower 7 bits of OCR are set.
But it is just a warning and driver continues. Anyways it is an
important hint for us.

OCR should have been read by: mmc_send_io_op_cond()
A prinkt shows the value of ocr:

[    0.000201] Waiting for root device /dev/mmcblk0p2...
[    0.000201] mmc_select_voltage: ocr=00ff8000
[    0.000201] mmc_attach_sdio
[    0.000201] mmc_select_voltage: ocr=00000000
[    0.000201] jz4740-mmc 13460000.mmc: no support for card's volts
[    0.000201] mmc1: error -22 whilst initialising SDIO card
[    0.000201] mmc_attach_mmc
[    0.000201] mmc0: host does not support reading read-only switch, assuming write-enable
[    0.000201] mmc0: error -145 whilst initialising SD card
[    0.000201] mmc_attach_mmc
[    0.000201] mmc_select_voltage: ocr=ffffffff
[    0.000201] jz4740-mmc 13450000.mmc: card claims to support voltages below defined range
[    0.000201] mmc0: error -145 whilst initialising MMC card
[    0.000201] mmc_attach_sdio
[    0.000201] mmc_select_voltage: ocr=00ff8000
[    0.000201] mmc0: host does not support reading read-only switch, assuming write-enable
[    0.000201] mmc0: error -145 whilst initialising SD card
[    0.000201] mmc_attach_mmc
[    0.000201] mmc_select_voltage: ocr=ffffffff

So this means sometimes reasonable values for "ocr", sometimes not.

If I compare with http://problemkaputt.de/gbatek-dsi-sd-mmc-protocol-ocr-register-32bit-operation-conditions-register.htm
they say that it is typically 007f8000h or similar.

In other cases we get 0x00000000 or 0xffffffff. Which may be related to reading in
the wrong mode or with wrong power applied.

So I pulled out my scope and looked at the pins. Fortunately
they are connected in parallel to the unused Flash chip, i.e. are
easy to be contacted.

The result is that I can see bursts on CLK and CMD and some bit patterns
on D0. Nothing on D1, D2, D3.

This means that reading the card in 1-bit MMC mode is partially
successful. Most likely this is used for reading the ORC. But 
the interface never switches to 4 bit mode.

What could be is that the clock is too fast for the card.

So I tried to identify the clock rate on CLK:
seems to be 3,5 MHz (which is likely the startup speed and switched
after identifying the speed grade of the card) and should be very ok.

But the CMD signal isn't clean. Has a lot of noise. As if two
line drivers are working against each other. Or if the driver is turned
off every now and then. Or some issue with pull-up/down?

Reasons for our issues could be:
1. clocks
2. DMA (if DMA used for single byte reads like the OCR?)
3. pinctrl (pullup/down?)
4. subtle msc controller differences to ingenic,jz4780-mmc (it was a pure assumption that they are the same based on same I/O address 0x13450000/0x13460000 and we have not yet checked)
5. something else (but what?)

BR,
Nikolaus



More information about the Letux-kernel mailing list