Raspberry Pi Compute Module

[Martin Sperl]

> On 28.08.2015, at 11:14, Martin Sperl <martin at sperl.org> wrote:
> 
> 
>> On 27.08.2015, at 20:09, Martin Sperl <martin at sperl.org> wrote:
>> 
>> 
>> 
>>> On 27.08.2015, at 20:04, Martin Sperl <martin at sperl.org> wrote:
>>> 
>>> 
>>> 
>>>> On 27.08.2015, at 18:11, Stephen Warren <swarren at wwwdotorg.org> 
>>>>> Compiling the kernel with mmc as module plus mmc-debug enabled gives the
>>>>> below:
>>>>> after loading the driver:
>>>> ...
>>>>> [   69.432782] mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21
>>>>> width 0 timing 0
>>>> 
>>>> ... lot of working commands ...
>>>> 
>>>>> [   69.499732] mmc0: clock 25000000Hz busmode 2 powermode 2 cs 0 Vdd 21
>>>>> width 0 timing 0
>>>> 
>>>> (up until now, the clock has always be 400KHz, not it's 25MHz)
>>>> 
>>>>> [   69.499854] mmc0: starting CMD6 arg 03a10101 flags 0000049d
>>>>> [   69.499924] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00038000
>>>>> [   69.499982] mmc0: req failed (CMD6): -110, retrying...
>>>>> [   69.500041] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00038000
>>>>> [   69.500091] mmc0: req failed (CMD6): -110, retrying...
>>>>> [   69.500146] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00038000
>>>>> [   69.500188] mmc0: req failed (CMD6): -110, retrying...
>>>>> [   69.500251] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00038000
>>>>> [   69.500300] mmc0: req done (CMD6): -110: 00000000 00000000 00000000
>>>>> 00000000
>>>>> [   69.500345] mmc0: error -110 whilst initialising MMC card
>>>> 
>>>> My guess it that the clock rate change caused this, not the CMD6 itself?
>>> 
>>> I saw a patch for one device that required more delay (in the order of 100us) between cmd13 and cmd6 - can't pinpoint it right now...
>>> 
>>> But then logging would add some delays, but maybe not enough...
>>> 
>>> Maybe changing clock to 400khz would allow access to the device - even if it is slow...
>>> 
>>> Can we configure that with the device tree, just to see if it makes a difference?
>>> 
>> See here: https://lkml.org/lkml/2014/9/9/382
>> for one device that required it…
> 
> I tried to add a delay in that location mentioned in the above patch, but it does not help!
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 0e9ae1c..2a6a912 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -530,6 +530,8 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8
>        if (!use_busy_signal)
>                goto out;
> 
> +       msleep(1);
> +
>        /*
>         * CRC errors shall only be ignored in cases were CMD13 is used to poll
>         * to detect busy completion.
> 
> 
> Also note that I have tried to force a slow transfer speed via the device-tree,
> but it did not help either - it still uses 25MHz...
> 
> Here the device-tree for sdhci - taken after all the modifications:
>                sdhci at 7e300000 {
>                        reg = <0x7e300000 0x100>;
>                        interrupts = <0x2 0x1e>;
> 
>                        compatible = "brcm,bcm2835-sdhci";
>                        bus-width = <0x4>;
>                        clocks = <0xc>;
>                        status = "okay”;
> 			/* local modifications after it did not work */
>                        max-frequency = <0x61a80>; /* 400000 */
>                        mmc-hs200-1_8v;
>                        mmc-hs400-1_8v;
>                        non-removable;
>                };


So I have now instrumented (and almost destroyed) one CM so that I can get
the signals to emmc into my logic-analyzer.
(removing all the custom settings and switching to bus-width = 1)

Sampling 3 lines at 500MHz I see the following sequence:
CMD: 0xE9 @ 1MHz
CMD: 0xD1 @ 1MHz
CMD: 0xFE @ 1MHz (with some data getting transferred on D0)
CMD: 0xFE @ 1MHz (with some data getting transferred on D0)

then we got a clock switch to about 62.5MHz
(measuring 16 clocks gives me 0.26us, so 61.5MHz)

CMD: 0xFA @ 62.5MHz

So it looks as if the clock is wrong - maybe we are using the wrong clock
resulting in the wrong divider?

The mmc-clock is set as 100MHz in the device-tree, which with a divider 
of 4 would give 25MHz. But if we assume a divider of 4 and 62.5MHz this
would give us a clock of 250MHz.

Checking the foundation device-trees, they have also 250MHz configured for
the mmc clock - even on a model 2...

Switching the clock to 250MHz in the device-tree changes the behavior,
and - with some errors due to my incompetent soldering - I can now detect
the eMMC and mount the partitions on the compute module.

I can now also confirm that the eMMC clock line shows now 25MHz!

I have ordered a replacement, but it takes some time to get it delivered,
so can please someone owning a Compute Module check that this fixes the
issue?

Note that I guess that because of this we are really overclocking the
SD cards on the normal RPIs as well, which results in more errors than
we see with the foundation kernels.

Another note: u-boot (at least the version I am using) is leaving the
eMMC clock running - I wonder if this is intended...

Thanks,
	Martin