Hi, I wonder if there is any progress on this? Or is there a workaround? I just installed debian jessie on a Banana Pro and hit this same problem. Can the ap6210 driver still be used with the 3.16 kernel that comes with jessie? Thanks!
On Wednesday, March 4, 2015 at 12:35:53 AM UTC-8, Hans de Goede wrote: > Hi, > > On 03-03-15 20:12, Arend van Spriel wrote: > > On 03/03/15 14:33, Hans de Goede wrote: > >> Hi, > >> > >> On 03-03-15 14:01, [email protected] wrote: > >>> > >>> Hello everyone > >>> I try to compile with the newest kernel from the website at > >>> https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-next . and the > >>> kernel can work normally on the BananaPro board. > >>> Meanwhile, I use the brcmfmac to driver the ap6181(wifi module as same > >>> as ap6210) in the linux-3.19, and the WiFi can work normally, but > >>> there is something wrong when i use the scp to copy. > >>> The error message as follows: > >>> [ 108.934478] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD SBE !! > >>> [ 108.940736] sunxi-mmc 1c12000.mmc: data error, sending stop command > >>> [ 108.947833] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110 > >>> [ 108.954330] brcmfmac: brcmf_sdio_rxfail: abort command, terminate > >>> frame, send NAK > >>> [ 108.966952] brcmfmac: brcmf_sdiod_regrw_helper: failed to write data > >>> F1@0x0a040, err: -5 > >>> [ 108.975499] brcmfmac: brcmf_sdio_hdparse: seq 79: sequence number > >>> error, expect 80 > >>> [ 109.336188] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !! > >>> [ 109.342442] sunxi-mmc 1c12000.mmc: data error, sending stop command > >>> [ 109.703557] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !! > >>> [ 109.709843] sunxi-mmc 1c12000.mmc: data error, sending stop command > >>> [ 110.070986] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !! > >>> [ 110.077273] sunxi-mmc 1c12000.mmc: data error, sending stop command > >>> [ 110.083928] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data > >>> F1@0x0a020, err: -110 > >>> > >>> It seems like there is a problem with the brcmfmac or sdio driver in > >>> the linux-3.19. > >>> Looking forward to you reply. > >> > >> Yes this is a known problem with broadcom sdio wifi on sunxi devices and > >> upstream kernels. Arend van Spriel from broadcom is looking into this. > >> > >> Arend, any luck in reproducing this on your cubietruck? > > > > Whether it be coincidence or devils' play, but today I got the cubietruck > > up and running with fc21 3.18.7 kernel. I tried installing a kernel from > > our internal tree (3.19-rc?) but did not get it working. > > > > So I got back to 3.18.7 fc21 kernel and build our latest brcmfmac against > > it using a backports package. I started a ping when I left the office and > > had another look at home seeing the same RD DTO messages. So yes I have > > reproduced it, but did not capture a log. > > Good (that you've reproduced it) note that it is much easier to reproduce > by scp-ing a bunch of large(ish) files, then it usually triggers within > a minute. > > >> And any luck in > >> finding a > >> fix for it ? > > > > We recently did have an issue where the device indicates busy using data > > lines and host ignored that and started next cmd53 causing the device to > > end in a bad state. Not sure if sunxi-mmc has similar issue. Will need to > > investigate that further. > > This might very well be a sunxi-mmc bug, but on my cubioetruck if I first > boot into the linux which is on the onboard flash, and then insert a sdcard > with upstream kernel and reboot so that it boots from the sdcard the > problem is gone. And I've done a regdump comparing all settings on the > mmc controller side, I might have missed something but atm my first hunch > is that the kernel in the nand sets some bits in the wifi module which > stick over reboot and fix this. Could actually still be the same thing > you're talking about but that the wifi moudle behavior is somehow > changed to avoid that. > > Also note that the very first error is not a cmd 53 error, there first > is a single different command which fails (forgot which one sorry) and > then from there on a lot of cmd53 errors. The first failing command > also does not fail with a response time out, but with a start bit error. > > Regards, > > Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
