ks7010 firmware upload fail

Hi,

I am attempting to test the ks7010 SIDO Wi-Fi driver (drivers/staging/ks7010/).

Currently probing the driver fails because of a firmware upload error.

I am seeking ideas on where to continue troubleshooting this issue.

Test setup:
- Spectec SDW-823 WIFI card (micro SD).
- Raspberry Pi B 1 (kernel 4.9.29) breakout board connected via GPIO pins.
- Driver code from current mainline (commit 453e102db531ac1ffa55f3e03c4907c063125859)
  (with additional debugging output calls).

Debugging thus far:

- define DEBUG in ks7010 and mmc makefiles (core, card, host).

kernel messages from time of fail:

[ 3746.903972] mmc1: starting CMD53 arg 94002004 flags 000001b5
[ 3746.903985] mmc1:     blksz 4 blocks 1 flags 00000100 tsac 1000 ms nsac 0
[ 3746.904077] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 3746.904090] mmc1:     4 bytes transferred: 0
[ 3746.904114] mmc1: starting CMD53 arg 94000804 flags 000001b5
[ 3746.904126] mmc1:     blksz 4 blocks 1 flags 00000100 tsac 1000 ms nsac 0
[ 3746.904180] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 3746.904189] mmc1:     4 bytes transferred: 0
[ 3746.912784] ks7010_upload_firmware: updated index to: 6000000
[ 3746.912816] mmc1: starting CMD53 arg 9e000080 flags 000001b5
[ 3746.912831] mmc1:     blksz 512 blocks 128 flags 00000100 tsac 1000 ms nsac 0
[ 3746.916336] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 3746.916353] mmc1:     65536 bytes transferred: 0
[ 3746.916420] ks7010_upload_firmware: wrote to address 10000 (DATA_WINDOW) 65536 bytes
[ 3746.916429] ks7010_sdio_data_compare: read 65536 bytes from address 10000
[ 3746.916436] debug messages from mmc/core are enabled
[ 3746.916459] mmc1: starting CMD53 arg 1e000080 flags 000001b5
[ 3746.916472] mmc1:     blksz 512 blocks 128 flags 00000200 tsac 1000 ms nsac 0
[ 3746.916575] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 3746.916588] mmc1:     0 bytes transferred: -84
[ 3746.920029] ks7010_sdio_read: sdio_memcpy_fromio() failed: -84
[ 3746.920100] ks7010: ERROR firmware load failed: 9

Briefly, firmware is uploaded to the card in chunks. Each chunk is
read back from the card to verify the transfer.

CMD53 can be seen to succeed when writing the first chunk to the
card. ks7010_sdio_data_compare() is then called which calls
ks7010_sdio_read() to read back the data written to the card. It is
this call that fails.

(CMD52 appears to be successful as well as CMD53 write).

All function calls (including memory addresses on the card, and kernel
buffer addresses) appear to be correct.

Removing the call to ks7010_sdio_data_compare() leads to an MMC read
error for each successive read (via CMD53) by the driver.

My question is should I be digging further into the MMC code or be doing
something else with the driver code?

Any suggestions, no matter how simple, most appreciated. This is my
first time digging into MMC and my first time really trying to trouble
shoot a kernel issue.

thanks,
Tobin.

Tobin,

My question is should I be digging further into the MMC code or be doing
something else with the driver code?

So, you haven't found any branch that worked? No plain v4.9 or the
gen3-sdio branch from my tree?

Regards,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170605/1bd08c03/attachment.bin 

On Mon, Jun 05, 2017 at 09:22:12AM +0200, Wolfram Sang wrote:

Tobin,

quoted

My question is should I be digging further into the MMC code or be doing
something else with the driver code?

So, you haven't found any branch that worked? No plain v4.9 or the
gen3-sdio branch from my tree?

I have not tried cloning your tree. I am using the Rasperry Pi kernel
source

https://github.com/raspberrypi/linux

which is v4.9.29

I checked out the last commit you made to the mainline then cross
compiled the driver from within the Rpi tree, copied the module over
to the Pi and insmod'd it.

To debug I was making code changes on my desktop, re cross compiling
the module and scp'ing it over (then rmmod'ing and insmod'ing the new module).

I'll try using a vanilla 4.9 kernel, and if that fails I'll try cloning your tree.

Thanks for getting back to me.

Will report my progress.

thanks,
Tobin.

On Mon, Jun 05, 2017 at 08:24:44PM +1000, Tobin C. Harding wrote:

On Mon, Jun 05, 2017 at 09:22:12AM +0200, Wolfram Sang wrote:

quoted

Tobin,

quoted

My question is should I be digging further into the MMC code or be doing
something else with the driver code?

So, you haven't found any branch that worked? No plain v4.9 or the
gen3-sdio branch from my tree?

I have not tried cloning your tree. I am using the Rasperry Pi kernel
source

https://github.com/raspberrypi/linux

which is v4.9.29

Hi Tobin,

Here are some instructions on how to compile an upstream kernel for a
Raspberry Pi: http://elinux.org/RPi_Upstream_Kernel_Compilation.
It describes setting up u-boot as the boot loader instead of the
boot loader that the Raspberry Pi kernel uses. One gotcha to be aware of
is that the config.txt file on the sd card won't be used.

Brian

On Mon, Jun 05, 2017 at 08:07:40PM -0400, Brian Masney wrote:

On Mon, Jun 05, 2017 at 08:24:44PM +1000, Tobin C. Harding wrote:

quoted

On Mon, Jun 05, 2017 at 09:22:12AM +0200, Wolfram Sang wrote:

quoted

Tobin,

quoted

My question is should I be digging further into the MMC code or be doing
something else with the driver code?

So, you haven't found any branch that worked? No plain v4.9 or the
gen3-sdio branch from my tree?

I have not tried cloning your tree. I am using the Rasperry Pi kernel
source

https://github.com/raspberrypi/linux

which is v4.9.29

Hi Tobin,

Here are some instructions on how to compile an upstream kernel for a
Raspberry Pi: http://elinux.org/RPi_Upstream_Kernel_Compilation.
It describes setting up u-boot as the boot loader instead of the
boot loader that the Raspberry Pi kernel uses. One gotcha to be aware of
is that the config.txt file on the sd card won't be used.

Thanks Brian.