BananPro WiFi Module (ap6181) Problems

[peter...@lemaker.com]

   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.

   

   Best Regards

---

Peter Chen

Innovations that enrich people's lives. 
LeMaker Team -- The Professional Makers for Hardware and Software Customization.

Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China 
Post Code: 518055

Email:
ap...@lemaker.org (Product Trials) 
educ...@lemaker.org (Education User Support) 
sup...@lemaker.org (Technical Support) 
pro...@lemaker.org (Product Distribution) 
bana...@lemaker.org (Other Enquiries)

 

 

 

http://www.lemaker.org/

[Hans de Goede]

Hi,

On 03-03-15 14:01, peter...@lemaker.com 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? And any luck in finding a
fix for it ?

Regards,

Hans

[Peter Mattern]

I had tried to address this some months ago which unfortunately didn't
yield any response
(https://groups.google.com/forum/#!topic/linux-sunxi/-GejF5r-HGg).

In addition to the findings described in that posting bandwidth seems to
matter as well. By limiting to about 200kB/s the problem was mitigated
and sometimes ceased completely.
Also, when many rather small files are transferred it starts later than
it does while transferring one large file.

What I said about testing still applies, too.

[peter...@lemaker.com]

 Hi, Hans

 Thanks for your reply so fast.

 If needed, i can help to reproduce this problem.

 

 Best Regards

---

Peter Chen

Innovations that enrich people's lives. 
LeMaker Team -- The Professional Makers for Hardware and Software Customization.

Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China 
Post Code: 518055 

Email:
ap...@lemaker.org (Product Trials) 
educ...@lemaker.org (Education User Support) 
sup...@lemaker.org (Technical Support) 
pro...@lemaker.org (Product Distribution) 
bana...@lemaker.org (Other Enquiries)

 

 

 

http://www.lemaker.org/

--

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 linux-sunxi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

[Arend van Spriel]

[Arend van Spriel]

On 03/03/15 18:39, Arend van Spriel wrote:

Hit the send button before typing any response. let me retry ;-p

[Arend van Spriel]

On 03/03/15 14:33, Hans de Goede wrote:

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.

>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.

Regards,
Arend

[Hans de Goede]

Hi,

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

[bina...@gmail.com]

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!

[Arend van Spriel]

On 04/20/15 07:36, bina...@gmail.com wrote:
> 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!

Apart from reproducing the issue I did not have much time to spent on
the issue. I am wondering whether it could be a "card busy" issue. The
sunxi mmc driver seems to be able to detect that. If this would be the
case a request should be hold off. I will see if I can try a patch for that.

Regards,
Arend

[Peter Mattern]

Running mainline kernel 4.0.3 (Arch Linux ARM) on a Cubietruck I
recently stumbled upon some systemd journal messages during boot that
seemed possibly related and hence worth posting to me:

> sunxi-mmc 1c12000.mmc: No vqmmc regulator found
> sunxi-mmc 1c12000.mmc: base:0xf011e000 irq:27
> sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !!
> sr_init: No PMIC hook to init smartreflex
> mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
> mmc1: new high speed SDIO card at address 0001
> sr_init: platform driver register failed for SR
> Unable to find PPMU node

> usbcore: registered new interface driver brcmfmac
> eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
> brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 \
14:50:00 version 5.90.195.89.6 FWID 01
> brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
> brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code

Regarding those letter messages the only reason to post is the fact that
the last three lines were marked red / like warnings (that ISO3166 thing
actually isn't something I'd consider related to the problem discussed
here).

[sigint]

<binaryni@...> writes:

>
> 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!

Workaround is there. We can't port whole ap6210 driver because it use
deprecated stuff, but we can use ap6210 compatibility tips. For example we
can use old sunxi sw_mci_check_r1_ready() routine in bcmsdh.c like it ap6210
dose. This trick synchronize mmc commands flow and hardware busy status.

[sigint]

..something like this:
(v4.0.5. mainline)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 459ed1b..82f41e3 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1082,6 +1082,23 @@ static struct platform_driver sunxi_mmc_driver = {
};
module_platform_driver(sunxi_mmc_driver);

+int sw_mci_check_r1_ready(struct mmc_host* mmc, unsigned ms)
+{
+ struct sunxi_mmc_host *smc_host = mmc_priv(mmc);
+ unsigned expire = jiffies + msecs_to_jiffies(ms);
+ do {
+ if (!(mmc_readl(smc_host, REG_STAS) & SDXC_CARD_DATA_BUSY))
+ break;
+ } while (jiffies < expire);
+
+ if ((mmc_readl(smc_host, REG_STAS) & SDXC_CARD_DATA_BUSY)) {
+ dev_err(mmc_dev(mmc), "wait r1 rdy %d ms timeout\n", ms);
+ return -1;
+ } else
+ return 0;
+}
+EXPORT_SYMBOL_GPL(sw_mci_check_r1_ready);
+
MODULE_DESCRIPTION("Allwinner's SD/MMC Card Controller Driver");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("David Lanzend�rfer <david.lan...@o2s.ch>");
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 7944224..ff63927 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -58,6 +58,8 @@
#define BRCMF_DEFAULT_TXGLOM_SIZE 32 /* max tx frames in glom chain */
#define BRCMF_DEFAULT_RXGLOM_SIZE 32 /* max rx frames in glom chain */

+extern int sw_mci_check_r1_ready(struct mmc_host* mmc, unsigned ms);
+
static int brcmf_sdiod_txglomsz = BRCMF_DEFAULT_TXGLOM_SIZE;
module_param_named(txglomsz, brcmf_sdiod_txglomsz, int, 0);
MODULE_PARM_DESC(txglomsz, "maximum tx packet chain size [SDIO]");
@@ -266,6 +268,10 @@ static int brcmf_sdiod_request_data(struct
brcmf_sdio_dev *sdiodev, u8 fn,
brcmf_dbg(SDIO, "failed to %s data F%d@0x%05x, err: %d\n",
write ? "write" : "read", fn, addr, ret);

+ //AW judge sdio read write timeout, 1s
+ if (sw_mci_check_r1_ready(sdiodev->func[fn]->card->host, 1000) != 0)
+ brcmf_err("sw_mci_check_r1_ready data timeout.\n");
+
return ret;
}

@@ -322,6 +328,11 @@ static int brcmf_sdiod_regrw_helper(struct
brcmf_sdio_dev *sdiodev, u32 addr,
brcmf_dbg(SDIO, "failed to %s data F%d@0x%05x, err: %d\n",
write ? "write" : "read", func, addr, ret);
}
+
+ //AW judge sdio read write timeout, 1s
+ if (sw_mci_check_r1_ready(sdiodev->func[func]->card->host, 1000) != 0)
+ brcmf_err("sw_mci_check_r1_ready data timeout.\n");
+
return ret;
}

@@ -461,6 +472,11 @@ static int brcmf_sdiod_buffrw(struct brcmf_sdio_dev
*sdiodev, uint fn,
req_sz);
if (err == -ENOMEDIUM)
brcmf_sdiod_nomedium_state(sdiodev);
+
+ //AW judge sdio read write timeout, 1s
+ if (sw_mci_check_r1_ready(sdiodev->func[fn]->card->host, 1000) != 0)
+ brcmf_err("sw_mci_check_r1_ready data timeout.\n");
+
return err;
}

[Sławomir Paszko]

I tried to implement sigint patch in freescale imx6 4.1 kernel(http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/, branch imx_4.1.15_1.0.0_ga), but it's not working. I have added these same changes in bcmsdh.c and i've made my sw_mci_check_r1_ready() function in sdhci.c based on

static int sdhci_card_busy(struct mmc_host *mmc)
{
    struct sdhci_host *host = mmc_priv(mmc);
    u32 present_state;

    sdhci_runtime_pm_get(host);
    /* Check whether DAT[3:0] is 0000 */
    present_state = sdhci_readl(host, SDHCI_PRESENT_STATE);
    sdhci_runtime_pm_put(host);

    return !(present_state & SDHCI_DATA_LVL_MASK);
}

Unfortunately this doesn't helped. Is there any official solution? Maybe you can give me some advice how to implement this in 4.1 freescale kernel.

[Sławomir Paszko]

I have merged 4.6 mainline drivers/wireless/broadcom and drivers/mmc into imx6 4.1 kernel and this was a partial solution for my problem. Key part was newer sdhci driver(drivers/mmc/host). Before merge, RXHEADER FAILED caused a break and reset of connection. It was a ~18s break of no transfer. Now errors occur but they don't stop connection and transmission continues.

[Ftts Ftts]

try this code.

drivers\net\wireless\broadcom\brcm80211\brcmfmac\bcmsdh.c

static int brcmf_sdiod_buffrw(struct brcmf_sdio_dev *sdiodev, uint fn,

    bool write, u32 addr, struct sk_buff *pkt)

{

unsigned int req_sz;

int err;

/* Single skb use the standard mmc interface */

req_sz = pkt->len + 3;

req_sz &= (uint)~3;

       //check if device is busy.

if (sw_mci_check_r1_ready(sdiodev->func[fn]->card->host, 1000) != 0)

brcmf_err("sw_mci_check_r1_ready data timeout.\n");

if (write)

err = sdio_memcpy_toio(sdiodev->func[fn], addr,

      ((u8 *)(pkt->data)), req_sz);

else if (fn == 1)

err = sdio_memcpy_fromio(sdiodev->func[fn], ((u8 *)(pkt->data)),

addr, req_sz);

else

/* function 2 read is FIFO operation */

err = sdio_readsb(sdiodev->func[fn], ((u8 *)(pkt->data)), addr,

 req_sz);

if (err == -ENOMEDIUM)

brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);

return err;

}

在 2016年9月16日星期五 UTC+8下午4:25:51，Sławomir Paszko写道：