BananaPro WiFi Armbian 5 kernel tracebacks

[BenCranston]

Greetings all!  

I'm working to get my BananaPro (LeMaker board) up and running with Armbian 5  (Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.raw) just downloaded to a fresh SD card.  The radio is discovered and appears to be at least tolerated by the drivers.  

 

I've modified and recompiled as directed, the boot.cmd as such to point to the bananapro.dtb file directly:

setenv bootargs "console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1"
#-----------------------------------------------------------------------------------------------------------------------
# Boot loader script to boot with different boot methods for old and new kernel
#-----------------------------------------------------------------------------------------------------------------------
if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next
then
# sunxi mainline kernel
#-----------------------------------------------------------------------------------------------------------------------
ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb  || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb 
ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage
env set fdt_high ffffffff
bootz 0x46000000 - 0x49000000
#-----------------------------------------------------------------------------------------------------------------------
else
# sunxi android kernel
#-----------------------------------------------------------------------------------------------------------------------
ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin
ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage
bootz 0x48000000
#-----------------------------------------------------------------------------------------------------------------------
fi
# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr 

Once I attempt to connect to my WPA2 network i get the following in dmesg:

[    7.814630] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
[  142.648468] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[  142.648496] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[  142.665845] ------------[ cut here ]------------
[  142.666002] WARNING: CPU: 0 PID: 1220 at net/wireless/sme.c:981 cfg80211_connect+0x420/0x450 [cfg80211]()
[  142.666013] Modules linked in: sun4i_codec snd_soc_core snd_pcm_dmaengine snd_pcm realtek input_leds snd_timer evdev snd nvmem_sunxi_sid dwmac_sunxi sun4i_ts nvmem_core soundcore sun4i_ss cpufreq_dt uio_pdrv_genirq uio thermal_sys bonding brcmfmac brcmutil cfg80211 rfkill fuse
[  142.666109] CPU: 0 PID: 1220 Comm: iwconfig Not tainted 4.4.3-sunxi #19
[  142.666118] Hardware name: Allwinner sun7i (A20) Family
[  142.666161] [<c00160b4>] (unwind_backtrace) from [<c0012ee4>] (show_stack+0x10/0x14)
[  142.666185] [<c0012ee4>] (show_stack) from [<c0397900>] (dump_stack+0x90/0xa4)
[  142.666205] [<c0397900>] (dump_stack) from [<c00246e0>] (warn_slowpath_common+0x80/0xb0)
[  142.666222] [<c00246e0>] (warn_slowpath_common) from [<c00247ac>] (warn_slowpath_null+0x1c/0x24)
[  142.666294] [<c00247ac>] (warn_slowpath_null) from [<bf046088>] (cfg80211_connect+0x420/0x450 [cfg80211])
[  142.666414] [<bf046088>] (cfg80211_connect [cfg80211]) from [<bf0498a8>] (cfg80211_mgd_wext_connect+0x104/0x15c [cfg80211])
[  142.666526] [<bf0498a8>] (cfg80211_mgd_wext_connect [cfg80211]) from [<bf0499b4>] (cfg80211_mgd_wext_siwfreq+0xb4/0x15c [cfg80211])
[  142.666636] [<bf0499b4>] (cfg80211_mgd_wext_siwfreq [cfg80211]) from [<bf049738>] (cfg80211_wext_siwfreq+0xb8/0x124 [cfg80211])
[  142.666705] [<bf049738>] (cfg80211_wext_siwfreq [cfg80211]) from [<c0680a08>] (ioctl_standard_call+0x58/0x470)
[  142.666727] [<c0680a08>] (ioctl_standard_call) from [<c068106c>] (wext_handle_ioctl+0x24c/0x268)
[  142.666746] [<c068106c>] (wext_handle_ioctl) from [<c0594530>] (dev_ioctl+0x568/0x8a4)
[  142.666766] [<c0594530>] (dev_ioctl) from [<c0115a58>] (do_vfs_ioctl+0x4ac/0x6e4)
[  142.666783] [<c0115a58>] (do_vfs_ioctl) from [<c0115cc4>] (SyS_ioctl+0x34/0x5c)
[  142.666801] [<c0115cc4>] (SyS_ioctl) from [<c000f2c0>] (ret_fast_syscall+0x0/0x3c)
[  142.666811] ---[ end trace 21ae0fb3e31b31da ]---
[  142.692833] ------------[ cut here ]------------
[  142.692995] WARNING: CPU: 0 PID: 1221 at net/wireless/sme.c:981 cfg80211_connect+0x420/0x450 [cfg80211]()
[  142.693006] Modules linked in: sun4i_codec snd_soc_core snd_pcm_dmaengine snd_pcm realtek input_leds snd_timer evdev snd nvmem_sunxi_sid dwmac_sunxi sun4i_ts nvmem_core soundcore sun4i_ss cpufreq_dt uio_pdrv_genirq uio thermal_sys bonding brcmfmac brcmutil cfg80211 rfkill fuse
[  142.693102] CPU: 0 PID: 1221 Comm: iwconfig Tainted: G        W       4.4.3-sunxi #19
[  142.693111] Hardware name: Allwinner sun7i (A20) Family
[  142.693152] [<c00160b4>] (unwind_backtrace) from [<c0012ee4>] (show_stack+0x10/0x14)
[  142.693176] [<c0012ee4>] (show_stack) from [<c0397900>] (dump_stack+0x90/0xa4)
[  142.693196] [<c0397900>] (dump_stack) from [<c00246e0>] (warn_slowpath_common+0x80/0xb0)
[  142.693214] [<c00246e0>] (warn_slowpath_common) from [<c00247ac>] (warn_slowpath_null+0x1c/0x24)
[  142.693284] [<c00247ac>] (warn_slowpath_null) from [<bf046088>] (cfg80211_connect+0x420/0x450 [cfg80211])
[  142.693401] [<bf046088>] (cfg80211_connect [cfg80211]) from [<bf0498a8>] (cfg80211_mgd_wext_connect+0x104/0x15c [cfg80211])
[  142.693512] [<bf0498a8>] (cfg80211_mgd_wext_connect [cfg80211]) from [<bf049e14>] (cfg80211_mgd_wext_siwap+0xfc/0x168 [cfg80211])
[  142.693582] [<bf049e14>] (cfg80211_mgd_wext_siwap [cfg80211]) from [<c0680a08>] (ioctl_standard_call+0x58/0x470)
[  142.693604] [<c0680a08>] (ioctl_standard_call) from [<c068106c>] (wext_handle_ioctl+0x24c/0x268)
[  142.693624] [<c068106c>] (wext_handle_ioctl) from [<c0594530>] (dev_ioctl+0x568/0x8a4)
[  142.693643] [<c0594530>] (dev_ioctl) from [<c0115a58>] (do_vfs_ioctl+0x4ac/0x6e4)
[  142.693661] [<c0115a58>] (do_vfs_ioctl) from [<c0115cc4>] (SyS_ioctl+0x34/0x5c)
[  142.693679] [<c0115cc4>] (SyS_ioctl) from [<c000f2c0>] (ret_fast_syscall+0x0/0x3c)
[  142.693689] ---[ end trace 21ae0fb3e31b31db ]---
[  142.887714] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  142.887793] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  157.920895] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[  157.920930] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[  178.910288] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[  178.910322] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[  179.915812] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  180.906117]  RX IPC Checksum Offload disabled
[  180.906157]  No MAC Management Counters available

Now the interesting thing here is that I don't see authentication attempts on the access point, so I'm thinking we never get to the point of transmitting.  I have been able to connect to an unsecured open AP once or twice.

 

I'm happy to hack about but am at a loss after googling and trying things for a few days.  Anyone else have the same issue?  Thanks in advance for the help.

 

[BenCranston]

ok, here's some more information..  I went back to 4.4.1 and had the same issue with the integrated broadcom radio.  For kicks I hooked up a USB RealTek radio and it works just fine. so the core WiFi sub-system is working, it's directly related to the broadcom radio hardware/drivers.  I wonder if the .dtb file has something goofy in it.  I do remember having this working with one of the LeMaker OS loads back with a 3.4 kernel.  is there a way to port the old "fex" files into a "dtb" ?  Am I using the terminology correctly?  Let me go back to the Jessie 3.4.110 load and see if that changes anything.  more updates shortly...   

[BenCranston]

good morning everyone.  I have some good information to pass along from the testing..  It's working! I can associate to my AP now without an issue.

 

What was the *fix* or *workaround*?

 

I had to disable 802.11b legacy speed support in my Access Point, that was all.  For whatever reason, with the "b" speeds active, it would have a fit.  Didn't matter if the SSID was encrypted or open.  once I turned the "b" speeds off the radio would associate.

 

So that tells me there is an issue somewhere in the driver for the radio that is causing it not to be able to associate to an AP if legacy speeds are offered for the connection..  for compatibility sake it would be awesome if the driver would at least tolerate the offering of the "b" spec speeds.

[Igor]

Just for a reference. I did a quick AP test on latest kernel 4.4.6 / Banana PRO. It works out of the box. I used preinstalled hostapd and sample config (wpa2, n enabled) /etc/hostapd.conf together with /etc/networking/interfaces.hostapd

[BenCranston]

Absolutely!  As it turns out my issue (I'll argue the driver still has a *bug* but will 100% concede it has nothing to do with Arabian or your excellent built) was that my access point was allowing for the legacy 802.11b data rates.  Once I limited it to only 802.11g data rates, then the radio in the Banana Pro works great.  the issue is really deep in the driver and not limited to the brcmfmac driver as it would fail with the ap6210 driver on older kernels as well.  I tried several of the LeMaker posted or linked distros and they all had the same issue.  An AP supporting the old 802.11b data rates will cause it to fail.  If for kicks anyone wants to see if they can reproduce the issue, go into their access point an enable 1, 2, 5.5 & 11 megabit data rates.  I'd bet that on attempt to associate the driver fails.

[awe104]

I have exactly the same issue on my BananaPi Pro with the mainline kernel from Igors git repository (gorpecovnik/lib). I built it yesterday.

uname -a
Linux bananapipro 4.4.6-sunxi #1 SMP Sun Mar 27 13:48:45 CEST 2016 armv7l GNU/Linux

With wicd I can establish a WLAN connection to my Fritz!box. I can get from there an ip address via dhcp. But this connection breaks after about 8s. Even some data transfer is possible. Conclusion: a connection is possible, but not permanently. Why?

Also Igors proposal to try hostapd, leads me to no satisfactory results. What hostapd I have to use? The already installed version? Or from the git (gorpecovnik/hostapd)? I've tried both versions.
 

Any ideas why the connection breaks and even better a solution :-)

 

Viele Gruesse

Axel

[awe104]

Problem solved for wireless network setup with wicd. It works on my build  of Armbian_5.07_Bananapipro_Ubuntu_trusty_4.5.1_desktop with the current sources from the repository. By coincidence I have in the wicd settings "Preferences --> Advanced Settings" marked at "Wireless Interface" the checkbox "Use 0dBm to measure signal strengh". What a surprise, WLAN no longer breaks after 8 seconds.

 

Also for Armbian_5.07_Bananapipro_Debian_jessie_4.5.1 I have WLAN. I had only create "/etc/network/interfaces" with the usual Wi-Fi settings.

 

For the BananaPiPro I brought also SATA to run with some userpatches. See atached zip-file.

 

Viele Gruesse

Axel

build.next.zip