MXC MMC driver and SDIO peripherals

MXC MMC driver and SDIO peripherals

[Daniel Mack]

Hi,

we're having trouble getting SDIO connected harware to fly on MX31 based
designs. In particular, a SD8686 chip supported by the libertas_sdio
driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
that option selected, however, the behaviour is a little different, and
I can at least see the following messages on a recent 2.6.32-rc5 based
MX31 tree.

Is there any common pitfall for such setups? I did more or less the same
thing on PXAs (same WLAN chip, same kind of interface, same firmware),
and haven't seen any such effects, so I suspect the MXC specific parts
to be the reason for that. Any ideas?

Thanks,
Daniel


[    1.450000] mmc0: new SDIO card at address 0001
...
# modprobe libertas_sdio
[   15.180000] libertas_sdio: Libertas SDIO driver
[   15.180000] libertas_sdio: Copyright Pierre Ossman
[   15.190000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
[   15.320000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
[   15.840000] libertas: 00:19:88:03:13:5a, fw 8.73.7p3, cap 0x00000393
[   16.870000] libertas: problem fetching packet from firmware
[   18.840000] libertas: command 0x001e timed out
[   18.840000] libertas: requeueing command 0x001e due to timeout (#1)
[   18.870000] libertas: Received result 0 to command 1e after 1 retries
[   18.910000] libertas: wlan0: Marvell WLAN 802.11 adapter

# ifconfig wlan0 up
[  216.760000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  217.800000] libertas: problem fetching packet from firmware
[  219.770000] libertas: command 0x0010 timed out
[  219.770000] libertas: requeueing command 0x0010 due to timeout (#1)
[  219.800000] libertas: Received result 0 to command 10 after 1 retries

# iwlist wlan0 scan
[  244.260000] libertas: problem fetching packet from firmware
[  247.800000] libertas: command 0x0006 timed out
[  247.800000] libertas: requeueing command 0x0006 due to timeout (#1)
[  248.260000] libertas: Received result 0 to command 6 after 1 retries
[  249.920000] libertas: problem fetching packet from firmware
[  253.560000] libertas: command 0x0006 timed out
[  253.560000] libertas: requeueing command 0x0006 due to timeout (#1)
[  254.920000] libertas: problem fetching packet from firmware
wlan0     Failed to read scan data : Resource temporarily unavailable

MXC MMC driver and SDIO peripherals

[Daniel Mack]

Hi,

we're having trouble getting SDIO connected harware to fly on MX31 based
designs. In particular, a SD8686 chip supported by the libertas_sdio
driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
that option selected, however, the behaviour is a little different, and
I can at least see the following messages on a recent 2.6.32-rc5 based
MX31 tree.

Is there any common pitfall for such setups? I did more or less the same
thing on PXAs (same WLAN chip, same kind of interface, same firmware),
and haven't seen any such effects, so I suspect the MXC specific parts
to be the reason for that. Any ideas?

Thanks,
Daniel


[    1.450000] mmc0: new SDIO card at address 0001
...
# modprobe libertas_sdio
[   15.180000] libertas_sdio: Libertas SDIO driver
[   15.180000] libertas_sdio: Copyright Pierre Ossman
[   15.190000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
[   15.320000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
[   15.840000] libertas: 00:19:88:03:13:5a, fw 8.73.7p3, cap 0x00000393
[   16.870000] libertas: problem fetching packet from firmware
[   18.840000] libertas: command 0x001e timed out
[   18.840000] libertas: requeueing command 0x001e due to timeout (#1)
[   18.870000] libertas: Received result 0 to command 1e after 1 retries
[   18.910000] libertas: wlan0: Marvell WLAN 802.11 adapter

# ifconfig wlan0 up
[  216.760000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  217.800000] libertas: problem fetching packet from firmware
[  219.770000] libertas: command 0x0010 timed out
[  219.770000] libertas: requeueing command 0x0010 due to timeout (#1)
[  219.800000] libertas: Received result 0 to command 10 after 1 retries

# iwlist wlan0 scan
[  244.260000] libertas: problem fetching packet from firmware
[  247.800000] libertas: command 0x0006 timed out
[  247.800000] libertas: requeueing command 0x0006 due to timeout (#1)
[  248.260000] libertas: Received result 0 to command 6 after 1 retries
[  249.920000] libertas: problem fetching packet from firmware
[  253.560000] libertas: command 0x0006 timed out
[  253.560000] libertas: requeueing command 0x0006 due to timeout (#1)
[  254.920000] libertas: problem fetching packet from firmware
wlan0     Failed to read scan data : Resource temporarily unavailable

Re: MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> Hi,
> 
> we're having trouble getting SDIO connected harware to fly on MX31 based
> designs. In particular, a SD8686 chip supported by the libertas_sdio
> driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> that option selected, however, the behaviour is a little different, and
> I can at least see the following messages on a recent 2.6.32-rc5 based
> MX31 tree.
> 
> Is there any common pitfall for such setups? I did more or less the same
> thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> and haven't seen any such effects, so I suspect the MXC specific parts
> to be the reason for that. Any ideas?

Any idea what quirks your SDHC is using if any?  Does it require PIO or
can it do DMA?  Does it have any transfer restrictions on block size or
bit-width?  What is the debug output of the MMC stack when loading the
module for your SDHC?

Dan

> Thanks,
> Daniel
> 
> 
> [    1.450000] mmc0: new SDIO card at address 0001
> ...
> # modprobe libertas_sdio
> [   15.180000] libertas_sdio: Libertas SDIO driver
> [   15.180000] libertas_sdio: Copyright Pierre Ossman
> [   15.190000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
> [   15.320000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
> [   15.840000] libertas: 00:19:88:03:13:5a, fw 8.73.7p3, cap 0x00000393
> [   16.870000] libertas: problem fetching packet from firmware
> [   18.840000] libertas: command 0x001e timed out
> [   18.840000] libertas: requeueing command 0x001e due to timeout (#1)
> [   18.870000] libertas: Received result 0 to command 1e after 1 retries
> [   18.910000] libertas: wlan0: Marvell WLAN 802.11 adapter
> 
> # ifconfig wlan0 up
> [  216.760000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [  217.800000] libertas: problem fetching packet from firmware
> [  219.770000] libertas: command 0x0010 timed out
> [  219.770000] libertas: requeueing command 0x0010 due to timeout (#1)
> [  219.800000] libertas: Received result 0 to command 10 after 1 retries
> 
> # iwlist wlan0 scan
> [  244.260000] libertas: problem fetching packet from firmware
> [  247.800000] libertas: command 0x0006 timed out
> [  247.800000] libertas: requeueing command 0x0006 due to timeout (#1)
> [  248.260000] libertas: Received result 0 to command 6 after 1 retries
> [  249.920000] libertas: problem fetching packet from firmware
> [  253.560000] libertas: command 0x0006 timed out
> [  253.560000] libertas: requeueing command 0x0006 due to timeout (#1)
> [  254.920000] libertas: problem fetching packet from firmware
> wlan0     Failed to read scan data : Resource temporarily unavailable
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> Hi,
> 
> we're having trouble getting SDIO connected harware to fly on MX31 based
> designs. In particular, a SD8686 chip supported by the libertas_sdio
> driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> that option selected, however, the behaviour is a little different, and
> I can at least see the following messages on a recent 2.6.32-rc5 based
> MX31 tree.
> 
> Is there any common pitfall for such setups? I did more or less the same
> thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> and haven't seen any such effects, so I suspect the MXC specific parts
> to be the reason for that. Any ideas?

Any idea what quirks your SDHC is using if any?  Does it require PIO or
can it do DMA?  Does it have any transfer restrictions on block size or
bit-width?  What is the debug output of the MMC stack when loading the
module for your SDHC?

Dan

> Thanks,
> Daniel
> 
> 
> [    1.450000] mmc0: new SDIO card at address 0001
> ...
> # modprobe libertas_sdio
> [   15.180000] libertas_sdio: Libertas SDIO driver
> [   15.180000] libertas_sdio: Copyright Pierre Ossman
> [   15.190000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
> [   15.320000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
> [   15.840000] libertas: 00:19:88:03:13:5a, fw 8.73.7p3, cap 0x00000393
> [   16.870000] libertas: problem fetching packet from firmware
> [   18.840000] libertas: command 0x001e timed out
> [   18.840000] libertas: requeueing command 0x001e due to timeout (#1)
> [   18.870000] libertas: Received result 0 to command 1e after 1 retries
> [   18.910000] libertas: wlan0: Marvell WLAN 802.11 adapter
> 
> # ifconfig wlan0 up
> [  216.760000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [  217.800000] libertas: problem fetching packet from firmware
> [  219.770000] libertas: command 0x0010 timed out
> [  219.770000] libertas: requeueing command 0x0010 due to timeout (#1)
> [  219.800000] libertas: Received result 0 to command 10 after 1 retries
> 
> # iwlist wlan0 scan
> [  244.260000] libertas: problem fetching packet from firmware
> [  247.800000] libertas: command 0x0006 timed out
> [  247.800000] libertas: requeueing command 0x0006 due to timeout (#1)
> [  248.260000] libertas: Received result 0 to command 6 after 1 retries
> [  249.920000] libertas: problem fetching packet from firmware
> [  253.560000] libertas: command 0x0006 timed out
> [  253.560000] libertas: requeueing command 0x0006 due to timeout (#1)
> [  254.920000] libertas: problem fetching packet from firmware
> wlan0     Failed to read scan data : Resource temporarily unavailable
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

Re: MXC MMC driver and SDIO peripherals

[Daniel Mack]

Hi Dan,

On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > Hi,
> > 
> > we're having trouble getting SDIO connected harware to fly on MX31 based
> > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > that option selected, however, the behaviour is a little different, and
> > I can at least see the following messages on a recent 2.6.32-rc5 based
> > MX31 tree.
> > 
> > Is there any common pitfall for such setups? I did more or less the same
> > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > and haven't seen any such effects, so I suspect the MXC specific parts
> > to be the reason for that. Any ideas?
> 
> Any idea what quirks your SDHC is using if any?  Does it require PIO or
> can it do DMA? 

In mainline kernels, DMA is limited to the MX2 SoC family. The MX3 that
I'm using is excluded from that feature, but I'mm not aware of the
reason for that.

> Does it have any transfer restrictions on block size or
> bit-width? 

I didn't really debug it yet, but from what I see in the sources, the
maximum block size is 2048. The hardware is connected via the 4-wire
interface (+clk, +cmd). The system I tried that on has a MMC slot where
I can plug in either the WLAN eval kit or a memory card, and the latter
works just fine, which tells me that at least the pin config and the
hardware can't be entirely wrong.

> What is the debug output of the MMC stack when loading the
> module for your SDHC?

Exactly one line ;)

[    1.340000] i.MX SDHC driver


Daniel

MXC MMC driver and SDIO peripherals

[Daniel Mack]

Hi Dan,

On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > Hi,
> > 
> > we're having trouble getting SDIO connected harware to fly on MX31 based
> > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > that option selected, however, the behaviour is a little different, and
> > I can at least see the following messages on a recent 2.6.32-rc5 based
> > MX31 tree.
> > 
> > Is there any common pitfall for such setups? I did more or less the same
> > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > and haven't seen any such effects, so I suspect the MXC specific parts
> > to be the reason for that. Any ideas?
> 
> Any idea what quirks your SDHC is using if any?  Does it require PIO or
> can it do DMA? 

In mainline kernels, DMA is limited to the MX2 SoC family. The MX3 that
I'm using is excluded from that feature, but I'mm not aware of the
reason for that.

> Does it have any transfer restrictions on block size or
> bit-width? 

I didn't really debug it yet, but from what I see in the sources, the
maximum block size is 2048. The hardware is connected via the 4-wire
interface (+clk, +cmd). The system I tried that on has a MMC slot where
I can plug in either the WLAN eval kit or a memory card, and the latter
works just fine, which tells me that at least the pin config and the
hardware can't be entirely wrong.

> What is the debug output of the MMC stack when loading the
> module for your SDHC?

Exactly one line ;)

[    1.340000] i.MX SDHC driver


Daniel

Re: MXC MMC driver and SDIO peripherals

[Sascha Hauer]

On Wed, Oct 21, 2009 at 10:51:56PM +0200, Daniel Mack wrote:
> Hi Dan,
> 
> On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > we're having trouble getting SDIO connected harware to fly on MX31 based
> > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > that option selected, however, the behaviour is a little different, and
> > > I can at least see the following messages on a recent 2.6.32-rc5 based
> > > MX31 tree.
> > > 
> > > Is there any common pitfall for such setups? I did more or less the same
> > > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > > and haven't seen any such effects, so I suspect the MXC specific parts
> > > to be the reason for that. Any ideas?
> > 
> > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > can it do DMA? 
> 
> In mainline kernels, DMA is limited to the MX2 SoC family. The MX3 that
> I'm using is excluded from that feature, but I'mm not aware of the
> reason for that.

The reason is that the i.MX31/35/25 have a so called Smart DMA engine
(SDMA). So far nobody has been smart enough to clean the Freescale code
up for mainline. The original DMA engine this driver works with is
equipped with the i.MX1/21/27 processors.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

MXC MMC driver and SDIO peripherals

[Sascha Hauer]

On Wed, Oct 21, 2009 at 10:51:56PM +0200, Daniel Mack wrote:
> Hi Dan,
> 
> On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > we're having trouble getting SDIO connected harware to fly on MX31 based
> > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > that option selected, however, the behaviour is a little different, and
> > > I can at least see the following messages on a recent 2.6.32-rc5 based
> > > MX31 tree.
> > > 
> > > Is there any common pitfall for such setups? I did more or less the same
> > > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > > and haven't seen any such effects, so I suspect the MXC specific parts
> > > to be the reason for that. Any ideas?
> > 
> > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > can it do DMA? 
> 
> In mainline kernels, DMA is limited to the MX2 SoC family. The MX3 that
> I'm using is excluded from that feature, but I'mm not aware of the
> reason for that.

The reason is that the i.MX31/35/25 have a so called Smart DMA engine
(SDMA). So far nobody has been smart enough to clean the Freescale code
up for mainline. The original DMA engine this driver works with is
equipped with the i.MX1/21/27 processors.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

MXC MMC driver and SDIO peripherals

[tommy tommy]

hi,sir!

1:your memory card test is fine,it can indicate sdhc data communicate ok
with sdio dma!
2:just use scope to test and know its clock,wifi clock is very strict,if
clock is lower ,will
get some issue.if sdio clock bigger than 25M or very slower,will get some
issue!
3:no relation with your MCU DMA,just SDIO DMA!

2009/10/22 Sascha Hauer <s.hauer@pengutronix.de>

> On Wed, Oct 21, 2009 at 10:51:56PM +0200, Daniel Mack wrote:
> > Hi Dan,
> >
> > On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > > Hi,
> > > >
> > > > we're having trouble getting SDIO connected harware to fly on MX31
> based
> > > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > > that option selected, however, the behaviour is a little different,
> and
> > > > I can at least see the following messages on a recent 2.6.32-rc5
> based
> > > > MX31 tree.
> > > >
> > > > Is there any common pitfall for such setups? I did more or less the
> same
> > > > thing on PXAs (same WLAN chip, same kind of interface, same
> firmware),
> > > > and haven't seen any such effects, so I suspect the MXC specific
> parts
> > > > to be the reason for that. Any ideas?
> > >
> > > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > > can it do DMA?
> >
> > In mainline kernels, DMA is limited to the MX2 SoC family. The MX3 that
> > I'm using is excluded from that feature, but I'mm not aware of the
> > reason for that.
>
> The reason is that the i.MX31/35/25 have a so called Smart DMA engine
> (SDMA). So far nobody has been smart enough to clean the Freescale code
> up for mainline. The original DMA engine this driver works with is
> equipped with the i.MX1/21/27 processors.
>
> Sascha
>
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091022/b1da27d9/attachment.htm>

Re: MXC MMC driver and SDIO peripherals

[Matt Hsu]

>
> I didn't really debug it yet, but from what I see in the sources, the
> maximum block size is 2048. The hardware is connected via the 4-wire
>   
Hi Daniel,

Did you try to run the driver with 1-Bit mode?

Maybe you can try to have debug routine to report the IRQ status for 
this sdhc controller.
Then you could know what's wrong with firmware downloading or command 
issuing.
Since the card detection looks fine according to your message.

If it tells you the DATA CRC error, then you can try to operate the SDIO 
in 1-Bit mode.
If it tells you the CMD CRC error, probably the strength of SDIO_CLK is 
not enough, you
need to have either internal pull-up or external resistor.

Cheers,
Matt
> interface (+clk, +cmd). The system I tried that on has a MMC slot where
> I can plug in either the WLAN eval kit or a memory card, and the latter
> works just fine, which tells me that at least the pin config and the
> hardware can't be entirely wrong.
>
>   
>> What is the debug output of the MMC stack when loading the
>> module for your SDHC?
>>     
>
> Exactly one line ;)
>
> [    1.340000] i.MX SDHC driver
>
>
> Daniel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>   

MXC MMC driver and SDIO peripherals

[Matt Hsu]

>
> I didn't really debug it yet, but from what I see in the sources, the
> maximum block size is 2048. The hardware is connected via the 4-wire
>   
Hi Daniel,

Did you try to run the driver with 1-Bit mode?

Maybe you can try to have debug routine to report the IRQ status for 
this sdhc controller.
Then you could know what's wrong with firmware downloading or command 
issuing.
Since the card detection looks fine according to your message.

If it tells you the DATA CRC error, then you can try to operate the SDIO 
in 1-Bit mode.
If it tells you the CMD CRC error, probably the strength of SDIO_CLK is 
not enough, you
need to have either internal pull-up or external resistor.

Cheers,
Matt
> interface (+clk, +cmd). The system I tried that on has a MMC slot where
> I can plug in either the WLAN eval kit or a memory card, and the latter
> works just fine, which tells me that at least the pin config and the
> hardware can't be entirely wrong.
>
>   
>> What is the debug output of the MMC stack when loading the
>> module for your SDHC?
>>     
>
> Exactly one line ;)
>
> [    1.340000] i.MX SDHC driver
>
>
> Daniel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>   

Re: MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > Hi,
> > 
> > we're having trouble getting SDIO connected harware to fly on MX31 based
> > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > that option selected, however, the behaviour is a little different, and
> > I can at least see the following messages on a recent 2.6.32-rc5 based
> > MX31 tree.
> > 
> > Is there any common pitfall for such setups? I did more or less the same
> > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > and haven't seen any such effects, so I suspect the MXC specific parts
> > to be the reason for that. Any ideas?
> 
> Any idea what quirks your SDHC is using if any?  Does it require PIO or
> can it do DMA?  Does it have any transfer restrictions on block size or
> bit-width?  What is the debug output of the MMC stack when loading the
> module for your SDHC?

I did some more research on this and it turns out that the problem is
related to multi block transfers. At least, this is when it first
occurs.

The libertas SDIO driver downloads two firmwares to the device, one
'helper' and one 'real' firmware The first one only uses chunks of 64
bytes each and that seems to work fine. The real firmware, however,
loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
of 32 bytes. And this is where the MXC host controller bails out with a
CRC error. Unfortunately, it does not give any more detailed information
about what exactly went wrong.

The effect might be related to an errata entry[1], which is what I'm
currently investigating. To do so, I would like to limit the the
communication to singe-block transfers, just to exclude all other
possible (electrical, clock speed, ...) issues. I did that by setting
mmc->max_blk_count to 1 in the the host controller, but then again,
the libertas driver and/or the firmware doesn't like that and dies in
if_sdio_pro_real() with

  firmware wants 17 bytes
  firmware helper signalled error

Any idea how to get that working with only single block small transfers?

Btw - there's a number of things missing for SDIO in the MXC MMC driver
which I implemented/fixed. I'll send patches as soon as I have more
confidence about the whole setup.


Thanks,
Daniel


[1] Errata IDs TLSbo91748 and TLSbo78667 from
    http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1

MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > Hi,
> > 
> > we're having trouble getting SDIO connected harware to fly on MX31 based
> > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > that option selected, however, the behaviour is a little different, and
> > I can at least see the following messages on a recent 2.6.32-rc5 based
> > MX31 tree.
> > 
> > Is there any common pitfall for such setups? I did more or less the same
> > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > and haven't seen any such effects, so I suspect the MXC specific parts
> > to be the reason for that. Any ideas?
> 
> Any idea what quirks your SDHC is using if any?  Does it require PIO or
> can it do DMA?  Does it have any transfer restrictions on block size or
> bit-width?  What is the debug output of the MMC stack when loading the
> module for your SDHC?

I did some more research on this and it turns out that the problem is
related to multi block transfers. At least, this is when it first
occurs.

The libertas SDIO driver downloads two firmwares to the device, one
'helper' and one 'real' firmware The first one only uses chunks of 64
bytes each and that seems to work fine. The real firmware, however,
loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
of 32 bytes. And this is where the MXC host controller bails out with a
CRC error. Unfortunately, it does not give any more detailed information
about what exactly went wrong.

The effect might be related to an errata entry[1], which is what I'm
currently investigating. To do so, I would like to limit the the
communication to singe-block transfers, just to exclude all other
possible (electrical, clock speed, ...) issues. I did that by setting
mmc->max_blk_count to 1 in the the host controller, but then again,
the libertas driver and/or the firmware doesn't like that and dies in
if_sdio_pro_real() with

  firmware wants 17 bytes
  firmware helper signalled error

Any idea how to get that working with only single block small transfers?

Btw - there's a number of things missing for SDIO in the MXC MMC driver
which I implemented/fixed. I'll send patches as soon as I have more
confidence about the whole setup.


Thanks,
Daniel


[1] Errata IDs TLSbo91748 and TLSbo78667 from
    http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1

Re: MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > we're having trouble getting SDIO connected harware to fly on MX31 based
> > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > that option selected, however, the behaviour is a little different, and
> > > I can at least see the following messages on a recent 2.6.32-rc5 based
> > > MX31 tree.
> > > 
> > > Is there any common pitfall for such setups? I did more or less the same
> > > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > > and haven't seen any such effects, so I suspect the MXC specific parts
> > > to be the reason for that. Any ideas?
> > 
> > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > can it do DMA?  Does it have any transfer restrictions on block size or
> > bit-width?  What is the debug output of the MMC stack when loading the
> > module for your SDHC?
> 
> I did some more research on this and it turns out that the problem is
> related to multi block transfers. At least, this is when it first
> occurs.
> 
> The libertas SDIO driver downloads two firmwares to the device, one
> 'helper' and one 'real' firmware The first one only uses chunks of 64
> bytes each and that seems to work fine. The real firmware, however,
> loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> of 32 bytes. And this is where the MXC host controller bails out with a
> CRC error. Unfortunately, it does not give any more detailed information
> about what exactly went wrong.
> 
> The effect might be related to an errata entry[1], which is what I'm
> currently investigating. To do so, I would like to limit the the
> communication to singe-block transfers, just to exclude all other
> possible (electrical, clock speed, ...) issues. I did that by setting
> mmc->max_blk_count to 1 in the the host controller, but then again,
> the libertas driver and/or the firmware doesn't like that and dies in
> if_sdio_pro_real() with
> 
>   firmware wants 17 bytes
>   firmware helper signalled error
> 
> Any idea how to get that working with only single block small transfers?

All the Marvell documentation (v5 at least) refers to 512-byte transfers
of the second-stage firmware in 32-byte blocks:

Section 2.2.1.1 of the v5 spec states:

"
2) If the length requested by helper is larger than 512 bytes, it is cut
into multiple pieces for CMD53 write. The current download length is set
to 512 bytes (16 blocks x 32 bytes per block) in each iteration of CMD53
write.
3) Host starts the download of 16 blocks of firmware (512 bytes)
4) Host copies the payload to the buffer.
5) Host writes 16 blocks of the firmware image data using CMD 53.
6) Repeat Steps 3 through 5 until the firmware image data specified by
the helper (Step 2) for this iteration is downloaded completely.
"

The helper firmware may well expect all 16 blocks.  But try adjusting
"chunk_size" in if_sdio.c::if_sdio_prog_real() down to one block (ie, 32
not 512) and see if the helper pukes.  The code looks like it can handle
chunk_size changes just fine.

If it does, and we after we further test that with other v8 and v9
firmware, then maybe we can print out a big fat warning about SDHC
suckage before trying a single-block fallback.

Dan

> Btw - there's a number of things missing for SDIO in the MXC MMC driver
> which I implemented/fixed. I'll send patches as soon as I have more
> confidence about the whole setup.
> 
> 
> Thanks,
> Daniel
> 
> 
> [1] Errata IDs TLSbo91748 and TLSbo78667 from
>     http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > we're having trouble getting SDIO connected harware to fly on MX31 based
> > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > that option selected, however, the behaviour is a little different, and
> > > I can at least see the following messages on a recent 2.6.32-rc5 based
> > > MX31 tree.
> > > 
> > > Is there any common pitfall for such setups? I did more or less the same
> > > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > > and haven't seen any such effects, so I suspect the MXC specific parts
> > > to be the reason for that. Any ideas?
> > 
> > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > can it do DMA?  Does it have any transfer restrictions on block size or
> > bit-width?  What is the debug output of the MMC stack when loading the
> > module for your SDHC?
> 
> I did some more research on this and it turns out that the problem is
> related to multi block transfers. At least, this is when it first
> occurs.
> 
> The libertas SDIO driver downloads two firmwares to the device, one
> 'helper' and one 'real' firmware The first one only uses chunks of 64
> bytes each and that seems to work fine. The real firmware, however,
> loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> of 32 bytes. And this is where the MXC host controller bails out with a
> CRC error. Unfortunately, it does not give any more detailed information
> about what exactly went wrong.
> 
> The effect might be related to an errata entry[1], which is what I'm
> currently investigating. To do so, I would like to limit the the
> communication to singe-block transfers, just to exclude all other
> possible (electrical, clock speed, ...) issues. I did that by setting
> mmc->max_blk_count to 1 in the the host controller, but then again,
> the libertas driver and/or the firmware doesn't like that and dies in
> if_sdio_pro_real() with
> 
>   firmware wants 17 bytes
>   firmware helper signalled error
> 
> Any idea how to get that working with only single block small transfers?

All the Marvell documentation (v5 at least) refers to 512-byte transfers
of the second-stage firmware in 32-byte blocks:

Section 2.2.1.1 of the v5 spec states:

"
2) If the length requested by helper is larger than 512 bytes, it is cut
into multiple pieces for CMD53 write. The current download length is set
to 512 bytes (16 blocks x 32 bytes per block) in each iteration of CMD53
write.
3) Host starts the download of 16 blocks of firmware (512 bytes)
4) Host copies the payload to the buffer.
5) Host writes 16 blocks of the firmware image data using CMD 53.
6) Repeat Steps 3 through 5 until the firmware image data specified by
the helper (Step 2) for this iteration is downloaded completely.
"

The helper firmware may well expect all 16 blocks.  But try adjusting
"chunk_size" in if_sdio.c::if_sdio_prog_real() down to one block (ie, 32
not 512) and see if the helper pukes.  The code looks like it can handle
chunk_size changes just fine.

If it does, and we after we further test that with other v8 and v9
firmware, then maybe we can print out a big fat warning about SDHC
suckage before trying a single-block fallback.

Dan

> Btw - there's a number of things missing for SDIO in the MXC MMC driver
> which I implemented/fixed. I'll send patches as soon as I have more
> confidence about the whole setup.
> 
> 
> Thanks,
> Daniel
> 
> 
> [1] Errata IDs TLSbo91748 and TLSbo78667 from
>     http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

Re: MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > we're having trouble getting SDIO connected harware to fly on MX31 based
> > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > that option selected, however, the behaviour is a little different, and
> > > I can at least see the following messages on a recent 2.6.32-rc5 based
> > > MX31 tree.
> > > 
> > > Is there any common pitfall for such setups? I did more or less the same
> > > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > > and haven't seen any such effects, so I suspect the MXC specific parts
> > > to be the reason for that. Any ideas?
> > 
> > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > can it do DMA?  Does it have any transfer restrictions on block size or
> > bit-width?  What is the debug output of the MMC stack when loading the
> > module for your SDHC?
> 
> I did some more research on this and it turns out that the problem is
> related to multi block transfers. At least, this is when it first
> occurs.
> 
> The libertas SDIO driver downloads two firmwares to the device, one
> 'helper' and one 'real' firmware The first one only uses chunks of 64
> bytes each and that seems to work fine. The real firmware, however,
> loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> of 32 bytes. And this is where the MXC host controller bails out with a
> CRC error. Unfortunately, it does not give any more detailed information
> about what exactly went wrong.
> 
> The effect might be related to an errata entry[1], which is what I'm
> currently investigating. To do so, I would like to limit the the
> communication to singe-block transfers, just to exclude all other
> possible (electrical, clock speed, ...) issues. I did that by setting
> mmc->max_blk_count to 1 in the the host controller, but then again,
> the libertas driver and/or the firmware doesn't like that and dies in
> if_sdio_pro_real() with
> 
>   firmware wants 17 bytes
>   firmware helper signalled error
> 
> Any idea how to get that working with only single block small transfers?

Just a note; single-block transfers will probably kill your wifi
performance, especially if the errata are true.  When the libertas
driver sends network data packets it sends them with

		ret = sdio_writesb(card->func, card->ioport,
				packet->buffer, packet->nb);

so if your packet is normal ethernet 1500 bytes, breaking that up in to
47 single block transfers of 32-bytes each is going to be slow...

Dan

> Btw - there's a number of things missing for SDIO in the MXC MMC driver
> which I implemented/fixed. I'll send patches as soon as I have more
> confidence about the whole setup.
> 
> 
> Thanks,
> Daniel
> 
> 
> [1] Errata IDs TLSbo91748 and TLSbo78667 from
>     http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> On Wed, Oct 21, 2009 at 01:15:19PM -0700, Dan Williams wrote:
> > On Wed, 2009-10-21 at 21:20 +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > we're having trouble getting SDIO connected harware to fly on MX31 based
> > > designs. In particular, a SD8686 chip supported by the libertas_sdio
> > > driver will hang forever when built without CONFIG_MMC_DEBUG=y. With
> > > that option selected, however, the behaviour is a little different, and
> > > I can at least see the following messages on a recent 2.6.32-rc5 based
> > > MX31 tree.
> > > 
> > > Is there any common pitfall for such setups? I did more or less the same
> > > thing on PXAs (same WLAN chip, same kind of interface, same firmware),
> > > and haven't seen any such effects, so I suspect the MXC specific parts
> > > to be the reason for that. Any ideas?
> > 
> > Any idea what quirks your SDHC is using if any?  Does it require PIO or
> > can it do DMA?  Does it have any transfer restrictions on block size or
> > bit-width?  What is the debug output of the MMC stack when loading the
> > module for your SDHC?
> 
> I did some more research on this and it turns out that the problem is
> related to multi block transfers. At least, this is when it first
> occurs.
> 
> The libertas SDIO driver downloads two firmwares to the device, one
> 'helper' and one 'real' firmware The first one only uses chunks of 64
> bytes each and that seems to work fine. The real firmware, however,
> loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> of 32 bytes. And this is where the MXC host controller bails out with a
> CRC error. Unfortunately, it does not give any more detailed information
> about what exactly went wrong.
> 
> The effect might be related to an errata entry[1], which is what I'm
> currently investigating. To do so, I would like to limit the the
> communication to singe-block transfers, just to exclude all other
> possible (electrical, clock speed, ...) issues. I did that by setting
> mmc->max_blk_count to 1 in the the host controller, but then again,
> the libertas driver and/or the firmware doesn't like that and dies in
> if_sdio_pro_real() with
> 
>   firmware wants 17 bytes
>   firmware helper signalled error
> 
> Any idea how to get that working with only single block small transfers?

Just a note; single-block transfers will probably kill your wifi
performance, especially if the errata are true.  When the libertas
driver sends network data packets it sends them with

		ret = sdio_writesb(card->func, card->ioport,
				packet->buffer, packet->nb);

so if your packet is normal ethernet 1500 bytes, breaking that up in to
47 single block transfers of 32-bytes each is going to be slow...

Dan

> Btw - there's a number of things missing for SDIO in the MXC MMC driver
> which I implemented/fixed. I'll send patches as soon as I have more
> confidence about the whole setup.
> 
> 
> Thanks,
> Daniel
> 
> 
> [1] Errata IDs TLSbo91748 and TLSbo78667 from
>     http://www.freescale.com/files/32bit/doc/errata/MCIMX31CE.pdf?fpsp=1
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

Re: MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> > 
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> > 
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> > 
> >   firmware wants 17 bytes
> >   firmware helper signalled error
> > 
> > Any idea how to get that working with only single block small transfers?
> 
> All the Marvell documentation (v5 at least) refers to 512-byte transfers
> of the second-stage firmware in 32-byte blocks:
> 
> Section 2.2.1.1 of the v5 spec states:
> 
> "
> 2) If the length requested by helper is larger than 512 bytes, it is cut
> into multiple pieces for CMD53 write. The current download length is set
> to 512 bytes (16 blocks x 32 bytes per block) in each iteration of CMD53
> write.
> 3) Host starts the download of 16 blocks of firmware (512 bytes)
> 4) Host copies the payload to the buffer.
> 5) Host writes 16 blocks of the firmware image data using CMD 53.
> 6) Repeat Steps 3 through 5 until the firmware image data specified by
> the helper (Step 2) for this iteration is downloaded completely.
> "
> 
> The helper firmware may well expect all 16 blocks.  But try adjusting
> "chunk_size" in if_sdio.c::if_sdio_prog_real() down to one block (ie, 32
> not 512) and see if the helper pukes.  The code looks like it can handle
> chunk_size changes just fine.

The code can, yes. But it seems the helper can't. I think I tried this
earlier. Here's the output:

[    5.620000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
[    5.700000] libertas sdio: waiting for helper to boot...
[    5.710000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
[    5.770000] libertas sdio: firmware wants 16 bytes
[    5.780000] libertas sdio: sending 16 bytes (32 bytes) chunk
[    5.790000] libertas sdio: firmware wants 512 bytes
[    5.790000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.800000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.820000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.850000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.870000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.890000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.900000] libertas sdio: firmware wants 17 bytes
[    5.900000] libertas sdio: firmware helper signalled error
[    5.910000] libertas: failed to load firmware
[    5.910000] libertas_sdio: probe of mmc0:0001:1 failed with error -5

Maybe I need to tweak the core to send 512 bytes in one block instead of
multiple ones?

Just to exclude other issues - seeing the driver coming that far tells
that electrical issues can't be the reason, right? Or is there anything
else that changes after the helper is downloaded successfully? Does the
hardware change anything on the hardware link layer at this point?

Daniel

MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> > 
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> > 
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> > 
> >   firmware wants 17 bytes
> >   firmware helper signalled error
> > 
> > Any idea how to get that working with only single block small transfers?
> 
> All the Marvell documentation (v5 at least) refers to 512-byte transfers
> of the second-stage firmware in 32-byte blocks:
> 
> Section 2.2.1.1 of the v5 spec states:
> 
> "
> 2) If the length requested by helper is larger than 512 bytes, it is cut
> into multiple pieces for CMD53 write. The current download length is set
> to 512 bytes (16 blocks x 32 bytes per block) in each iteration of CMD53
> write.
> 3) Host starts the download of 16 blocks of firmware (512 bytes)
> 4) Host copies the payload to the buffer.
> 5) Host writes 16 blocks of the firmware image data using CMD 53.
> 6) Repeat Steps 3 through 5 until the firmware image data specified by
> the helper (Step 2) for this iteration is downloaded completely.
> "
> 
> The helper firmware may well expect all 16 blocks.  But try adjusting
> "chunk_size" in if_sdio.c::if_sdio_prog_real() down to one block (ie, 32
> not 512) and see if the helper pukes.  The code looks like it can handle
> chunk_size changes just fine.

The code can, yes. But it seems the helper can't. I think I tried this
earlier. Here's the output:

[    5.620000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
[    5.700000] libertas sdio: waiting for helper to boot...
[    5.710000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
[    5.770000] libertas sdio: firmware wants 16 bytes
[    5.780000] libertas sdio: sending 16 bytes (32 bytes) chunk
[    5.790000] libertas sdio: firmware wants 512 bytes
[    5.790000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.800000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.820000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.850000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.870000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.890000] libertas sdio: sending 32 bytes (32 bytes) chunk
[    5.900000] libertas sdio: firmware wants 17 bytes
[    5.900000] libertas sdio: firmware helper signalled error
[    5.910000] libertas: failed to load firmware
[    5.910000] libertas_sdio: probe of mmc0:0001:1 failed with error -5

Maybe I need to tweak the core to send 512 bytes in one block instead of
multiple ones?

Just to exclude other issues - seeing the driver coming that far tells
that electrical issues can't be the reason, right? Or is there anything
else that changes after the helper is downloaded successfully? Does the
hardware change anything on the hardware link layer at this point?

Daniel

Re: MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 28, 2009 at 10:11:04AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> > 
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> > 
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> > 
> >   firmware wants 17 bytes
> >   firmware helper signalled error
> > 
> > Any idea how to get that working with only single block small transfers?
> 
> Just a note; single-block transfers will probably kill your wifi
> performance, especially if the errata are true.  When the libertas
> driver sends network data packets it sends them with
> 
> 		ret = sdio_writesb(card->func, card->ioport,
> 				packet->buffer, packet->nb);
> 
> so if your packet is normal ethernet 1500 bytes, breaking that up in to
> 47 single block transfers of 32-bytes each is going to be slow...

Yep, I know. Thats's a disaster, especially without DMA enabled (which
is currently the case).

But I'd like to see it working somehow first and then see whether that's
really the issue :)

Daniel

MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 28, 2009 at 10:11:04AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> > 
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> > 
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> > 
> >   firmware wants 17 bytes
> >   firmware helper signalled error
> > 
> > Any idea how to get that working with only single block small transfers?
> 
> Just a note; single-block transfers will probably kill your wifi
> performance, especially if the errata are true.  When the libertas
> driver sends network data packets it sends them with
> 
> 		ret = sdio_writesb(card->func, card->ioport,
> 				packet->buffer, packet->nb);
> 
> so if your packet is normal ethernet 1500 bytes, breaking that up in to
> 47 single block transfers of 32-bytes each is going to be slow...

Yep, I know. Thats's a disaster, especially without DMA enabled (which
is currently the case).

But I'd like to see it working somehow first and then see whether that's
really the issue :)

Daniel

Re: MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-28 at 18:19 +0100, Daniel Mack wrote:
> On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> > On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > > I did some more research on this and it turns out that the problem is
> > > related to multi block transfers. At least, this is when it first
> > > occurs.
> > > 
> > > The libertas SDIO driver downloads two firmwares to the device, one
> > > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > > bytes each and that seems to work fine. The real firmware, however,
> > > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > > of 32 bytes. And this is where the MXC host controller bails out with a
> > > CRC error. Unfortunately, it does not give any more detailed information
> > > about what exactly went wrong.
> > > 
> > > The effect might be related to an errata entry[1], which is what I'm
> > > currently investigating. To do so, I would like to limit the the
> > > communication to singe-block transfers, just to exclude all other
> > > possible (electrical, clock speed, ...) issues. I did that by setting
> > > mmc->max_blk_count to 1 in the the host controller, but then again,
> > > the libertas driver and/or the firmware doesn't like that and dies in
> > > if_sdio_pro_real() with
> > > 
> > >   firmware wants 17 bytes
> > >   firmware helper signalled error
> > > 
> > > Any idea how to get that working with only single block small transfers?
> > 
> > All the Marvell documentation (v5 at least) refers to 512-byte transfers
> > of the second-stage firmware in 32-byte blocks:
> > 
> > Section 2.2.1.1 of the v5 spec states:
> > 
> > "
> > 2) If the length requested by helper is larger than 512 bytes, it is cut
> > into multiple pieces for CMD53 write. The current download length is set
> > to 512 bytes (16 blocks x 32 bytes per block) in each iteration of CMD53
> > write.
> > 3) Host starts the download of 16 blocks of firmware (512 bytes)
> > 4) Host copies the payload to the buffer.
> > 5) Host writes 16 blocks of the firmware image data using CMD 53.
> > 6) Repeat Steps 3 through 5 until the firmware image data specified by
> > the helper (Step 2) for this iteration is downloaded completely.
> > "
> > 
> > The helper firmware may well expect all 16 blocks.  But try adjusting
> > "chunk_size" in if_sdio.c::if_sdio_prog_real() down to one block (ie, 32
> > not 512) and see if the helper pukes.  The code looks like it can handle
> > chunk_size changes just fine.
> 
> The code can, yes. But it seems the helper can't. I think I tried this
> earlier. Here's the output:
> 
> [    5.620000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
> [    5.700000] libertas sdio: waiting for helper to boot...
> [    5.710000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
> [    5.770000] libertas sdio: firmware wants 16 bytes
> [    5.780000] libertas sdio: sending 16 bytes (32 bytes) chunk
> [    5.790000] libertas sdio: firmware wants 512 bytes
> [    5.790000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.800000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.820000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.850000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.870000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.890000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.900000] libertas sdio: firmware wants 17 bytes
> [    5.900000] libertas sdio: firmware helper signalled error
> [    5.910000] libertas: failed to load firmware
> [    5.910000] libertas_sdio: probe of mmc0:0001:1 failed with error -5
> 
> Maybe I need to tweak the core to send 512 bytes in one block instead of
> multiple ones?

Maybe?  But I bet the helper would fail on that too, since it's
expecting 32 byte blocks.

> Just to exclude other issues - seeing the driver coming that far tells
> that electrical issues can't be the reason, right? Or is there anything
> else that changes after the helper is downloaded successfully? Does the
> hardware change anything on the hardware link layer at this point?

I can't think of a reason why it would be electrical, but we can't
exclude that completely of course.  The helper is simply a small program
that knows how to buffer a larger firmware and load that firmware at a
given address in memory on the Libertas.  I don't believe it has
anything to do with the SDIO bits of the chip, but I don't know for sure
since I don't have the code for it.

I think this just boils down to a pretty badly implemented SDHC :(

Dan

MXC MMC driver and SDIO peripherals

[Dan Williams]

On Wed, 2009-10-28 at 18:19 +0100, Daniel Mack wrote:
> On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> > On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > > I did some more research on this and it turns out that the problem is
> > > related to multi block transfers. At least, this is when it first
> > > occurs.
> > > 
> > > The libertas SDIO driver downloads two firmwares to the device, one
> > > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > > bytes each and that seems to work fine. The real firmware, however,
> > > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > > of 32 bytes. And this is where the MXC host controller bails out with a
> > > CRC error. Unfortunately, it does not give any more detailed information
> > > about what exactly went wrong.
> > > 
> > > The effect might be related to an errata entry[1], which is what I'm
> > > currently investigating. To do so, I would like to limit the the
> > > communication to singe-block transfers, just to exclude all other
> > > possible (electrical, clock speed, ...) issues. I did that by setting
> > > mmc->max_blk_count to 1 in the the host controller, but then again,
> > > the libertas driver and/or the firmware doesn't like that and dies in
> > > if_sdio_pro_real() with
> > > 
> > >   firmware wants 17 bytes
> > >   firmware helper signalled error
> > > 
> > > Any idea how to get that working with only single block small transfers?
> > 
> > All the Marvell documentation (v5 at least) refers to 512-byte transfers
> > of the second-stage firmware in 32-byte blocks:
> > 
> > Section 2.2.1.1 of the v5 spec states:
> > 
> > "
> > 2) If the length requested by helper is larger than 512 bytes, it is cut
> > into multiple pieces for CMD53 write. The current download length is set
> > to 512 bytes (16 blocks x 32 bytes per block) in each iteration of CMD53
> > write.
> > 3) Host starts the download of 16 blocks of firmware (512 bytes)
> > 4) Host copies the payload to the buffer.
> > 5) Host writes 16 blocks of the firmware image data using CMD 53.
> > 6) Repeat Steps 3 through 5 until the firmware image data specified by
> > the helper (Step 2) for this iteration is downloaded completely.
> > "
> > 
> > The helper firmware may well expect all 16 blocks.  But try adjusting
> > "chunk_size" in if_sdio.c::if_sdio_prog_real() down to one block (ie, 32
> > not 512) and see if the helper pukes.  The code looks like it can handle
> > chunk_size changes just fine.
> 
> The code can, yes. But it seems the helper can't. I think I tried this
> earlier. Here's the output:
> 
> [    5.620000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
> [    5.700000] libertas sdio: waiting for helper to boot...
> [    5.710000] libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
> [    5.770000] libertas sdio: firmware wants 16 bytes
> [    5.780000] libertas sdio: sending 16 bytes (32 bytes) chunk
> [    5.790000] libertas sdio: firmware wants 512 bytes
> [    5.790000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.800000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.810000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.820000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.830000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.840000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.850000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.860000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.870000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.880000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.890000] libertas sdio: sending 32 bytes (32 bytes) chunk
> [    5.900000] libertas sdio: firmware wants 17 bytes
> [    5.900000] libertas sdio: firmware helper signalled error
> [    5.910000] libertas: failed to load firmware
> [    5.910000] libertas_sdio: probe of mmc0:0001:1 failed with error -5
> 
> Maybe I need to tweak the core to send 512 bytes in one block instead of
> multiple ones?

Maybe?  But I bet the helper would fail on that too, since it's
expecting 32 byte blocks.

> Just to exclude other issues - seeing the driver coming that far tells
> that electrical issues can't be the reason, right? Or is there anything
> else that changes after the helper is downloaded successfully? Does the
> hardware change anything on the hardware link layer at this point?

I can't think of a reason why it would be electrical, but we can't
exclude that completely of course.  The helper is simply a small program
that knows how to buffer a larger firmware and load that firmware at a
given address in memory on the Libertas.  I don't believe it has
anything to do with the SDIO bits of the chip, but I don't know for sure
since I don't have the code for it.

I think this just boils down to a pretty badly implemented SDHC :(

Dan

Re: MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> > 
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> > 
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> > 
> >   firmware wants 17 bytes
> >   firmware helper signalled error

A number of bytes requested has bit 1 set indicates an error, according
to the code if_sdio_prog_real(). Is there any more information in such
cases? An error code that tells us about the real reason maybe?

> All the Marvell documentation (v5 at least) refers to 512-byte transfers
> of the second-stage firmware in 32-byte blocks:
> 
> Section 2.2.1.1 of the v5 spec states:

What documentation is that? Is it publically available?

Thanks,
Daniel

MXC MMC driver and SDIO peripherals

[Daniel Mack]

On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > I did some more research on this and it turns out that the problem is
> > related to multi block transfers. At least, this is when it first
> > occurs.
> > 
> > The libertas SDIO driver downloads two firmwares to the device, one
> > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > bytes each and that seems to work fine. The real firmware, however,
> > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > of 32 bytes. And this is where the MXC host controller bails out with a
> > CRC error. Unfortunately, it does not give any more detailed information
> > about what exactly went wrong.
> > 
> > The effect might be related to an errata entry[1], which is what I'm
> > currently investigating. To do so, I would like to limit the the
> > communication to singe-block transfers, just to exclude all other
> > possible (electrical, clock speed, ...) issues. I did that by setting
> > mmc->max_blk_count to 1 in the the host controller, but then again,
> > the libertas driver and/or the firmware doesn't like that and dies in
> > if_sdio_pro_real() with
> > 
> >   firmware wants 17 bytes
> >   firmware helper signalled error

A number of bytes requested has bit 1 set indicates an error, according
to the code if_sdio_prog_real(). Is there any more information in such
cases? An error code that tells us about the real reason maybe?

> All the Marvell documentation (v5 at least) refers to 512-byte transfers
> of the second-stage firmware in 32-byte blocks:
> 
> Section 2.2.1.1 of the v5 spec states:

What documentation is that? Is it publically available?

Thanks,
Daniel

Re: MXC MMC driver and SDIO peripherals

[Dan Williams]

On Thu, 2009-10-29 at 11:27 +0100, Daniel Mack wrote:
> On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> > On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > > I did some more research on this and it turns out that the problem is
> > > related to multi block transfers. At least, this is when it first
> > > occurs.
> > > 
> > > The libertas SDIO driver downloads two firmwares to the device, one
> > > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > > bytes each and that seems to work fine. The real firmware, however,
> > > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > > of 32 bytes. And this is where the MXC host controller bails out with a
> > > CRC error. Unfortunately, it does not give any more detailed information
> > > about what exactly went wrong.
> > > 
> > > The effect might be related to an errata entry[1], which is what I'm
> > > currently investigating. To do so, I would like to limit the the
> > > communication to singe-block transfers, just to exclude all other
> > > possible (electrical, clock speed, ...) issues. I did that by setting
> > > mmc->max_blk_count to 1 in the the host controller, but then again,
> > > the libertas driver and/or the firmware doesn't like that and dies in
> > > if_sdio_pro_real() with
> > > 
> > >   firmware wants 17 bytes
> > >   firmware helper signalled error
> 
> A number of bytes requested has bit 1 set indicates an error, according
> to the code if_sdio_prog_real(). Is there any more information in such
> cases? An error code that tells us about the real reason maybe?

Not that I know of; the helper is pretty simple.  The v9 SD8686 vendor
driver assumes that any helper error is a CRC error, and retries that
block a few times before failing.  But the helper asking for 17 bytes
seems a bit suspicious.  Are you sure there aren't any TX/RX issues with
your SDHC and the connections to the card?

> > All the Marvell documentation (v5 at least) refers to 512-byte transfers
> > of the second-stage firmware in 32-byte blocks:
> > 
> > Section 2.2.1.1 of the v5 spec states:
> 
> What documentation is that? Is it publically available?

http://wiki.laptop.org/images/f/f3/Firmware-Spec-v5.1-MV-S103752-00.pdf

Dan

MXC MMC driver and SDIO peripherals

[Dan Williams]

On Thu, 2009-10-29 at 11:27 +0100, Daniel Mack wrote:
> On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> > On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > > I did some more research on this and it turns out that the problem is
> > > related to multi block transfers. At least, this is when it first
> > > occurs.
> > > 
> > > The libertas SDIO driver downloads two firmwares to the device, one
> > > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > > bytes each and that seems to work fine. The real firmware, however,
> > > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > > of 32 bytes. And this is where the MXC host controller bails out with a
> > > CRC error. Unfortunately, it does not give any more detailed information
> > > about what exactly went wrong.
> > > 
> > > The effect might be related to an errata entry[1], which is what I'm
> > > currently investigating. To do so, I would like to limit the the
> > > communication to singe-block transfers, just to exclude all other
> > > possible (electrical, clock speed, ...) issues. I did that by setting
> > > mmc->max_blk_count to 1 in the the host controller, but then again,
> > > the libertas driver and/or the firmware doesn't like that and dies in
> > > if_sdio_pro_real() with
> > > 
> > >   firmware wants 17 bytes
> > >   firmware helper signalled error
> 
> A number of bytes requested has bit 1 set indicates an error, according
> to the code if_sdio_prog_real(). Is there any more information in such
> cases? An error code that tells us about the real reason maybe?

Not that I know of; the helper is pretty simple.  The v9 SD8686 vendor
driver assumes that any helper error is a CRC error, and retries that
block a few times before failing.  But the helper asking for 17 bytes
seems a bit suspicious.  Are you sure there aren't any TX/RX issues with
your SDHC and the connections to the card?

> > All the Marvell documentation (v5 at least) refers to 512-byte transfers
> > of the second-stage firmware in 32-byte blocks:
> > 
> > Section 2.2.1.1 of the v5 spec states:
> 
> What documentation is that? Is it publically available?

http://wiki.laptop.org/images/f/f3/Firmware-Spec-v5.1-MV-S103752-00.pdf

Dan