Search the Community

I have been having wifi connection issues with the OPi Zero as well. But only with the mainline kernel. With the legacy kernel, I can connect to my various access points and transfer data, SSH etc. I wanted to try out the mainline kernel, so about a month ago I downloaded one of the nightly builds I was not surprised that the WiFi didn't work at all. I waited several days while reading the forums and once folks were reporting a working mainline, I tried again. THis time I could see access points but could not associate. After a while I started investigating what could be wrong with my setup. At this point I had a working jessie 3.4.113 and a non working Xenial 4.9.0 (not working wifi that is). Both stock installs of Armbian 5.24. I tried several power sources, several usb cables, old slow SD cards, and new fast SD cards. All results were consistent, jessie 3.4.113 worked, Xenial 4,9.0 then 4.9.1,4.9.2,4.9.3 didn't. I then thought that maybe I had a bad OPi Zero, so I ordered and waited 3 weeks to get a second. It arrived the other day and all results with the new board were the same. Today I saw that there was an actual release of Xenial 4.9.4 for the OPi Zero. Downloaded it and got the same results. Ethernet works on both jessie and xenial. I have tried with the ethernet cable connected and disconnected. I have tried with power management on and off. I can do a iwlist scan and see access points on both systems. It almost seems like there is no data being sent from the OPi with Xenial. I probed the 1.8V and 3.3V power for the Wifi chip and both are at nominal levels. Both my boards are 512M and came with the SPI flash soldered on. This is a stock installation of the Armbian Xenial 4.9.4 I downloaded on 1/26/2017. No other packages have been loaded, upgraded or configurations changed. Messages which might be of interest: iwconfig wlan0 essid MyAP [ 1408.950945] xradio_wlan mmc1:0001:1: missed interrupt [ 1449.630902] wlan0: authenticate with 18:a6:f7:02:4d:fa [ 1449.630999] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 1449.631309] wlan0: send auth to 18:a6:f7:02:4d:fa (try 1/3) [ 1449.631713] wlan0: send auth to 18:a6:f7:02:4d:fa (try 2/3) [ 1449.631858] wlan0: send auth to 18:a6:f7:02:4d:fa (try 3/3) [ 1449.631964] wlan0: authentication with 18:a6:f7:02:4d:fa timed out after ifconfig eth0 dowm then iwconfig wlan0 essid MyOtherAP [ 2237.719983] wlan0: authenticate with f4:f2:6d:a3:0e:5c [ 2237.720124] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 2237.720154] ieee80211 phy0: Freq 2412 (wsm ch: 1). [ 2237.721079] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 1/3) [ 2237.721619] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 2/3) [ 2237.721951] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 3/3) [ 2237.722278] wlan0: authentication with f4:f2:6d:a3:0e:5c timed out [ 2237.761757] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) modinfo xradio_wlan filename: /lib/modules/4.9.4-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.ko alias: xradio_core license: GPL description: XRadioTech WLAN driver core author: XRadioTech alias: sdio:c*v0020d2281* depends: mac80211,cfg80211 intree: Y vermagic: 4.9.4-sun8i SMP mod_unload ARMv7 thumb2 p2v8 iw wlan0 info Interface wlan0 ifindex 3 wdev 0x1 addr 12:42:87:47:5c:af type managed wiphy 0 lsmod Module Size Used by evdev 10043 0 xradio_wlan 92375 1 mac80211 322651 1 xradio_wlan cfg80211 191902 2 mac80211,xradio_wlan rfkill 10928 3 cfg80211 sun8i_ths 3134 0 gpio_keys 8453 0 cpufreq_dt 3586 0 uio_pdrv_genirq 3354 0 thermal_sys 42239 2 cpufreq_dt,sun8i_ths uio 8012 1 uio_pdrv_genirq ip link show wlan0 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000 link/ether 12:42:87:47:5c:af brd ff:ff:ff:ff:ff:ff uname -a Linux orangepizero 4.9.4-sun8i #3 SMP Fri Jan 20 22:11:20 CET 2017 armv7l armv7l armv7l GNU/Linux nmcli device show GENERAL.DEVICE: eth0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 02:42:87:47:5C:AF GENERAL.MTU: 1500 GENERAL.STATE: 30 (disconnected) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- WIRED-PROPERTIES.CARRIER: on GENERAL.DEVICE: wlan0 GENERAL.TYPE: wifi GENERAL.HWADDR: 12:42:87:47:5C:AF GENERAL.MTU: 0 GENERAL.STATE: 30 (disconnected) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- GENERAL.DEVICE: lo GENERAL.TYPE: loopback GENERAL.HWADDR: 00:00:00:00:00:00 GENERAL.MTU: 65536 GENERAL.STATE: 10 (unmanaged) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- IP4.ADDRESS[1]: 127.0.0.1/8 IP4.GATEWAY: IP6.ADDRESS[1]: ::1/128 IP6.GATEWAY: systemctl status network-manager ��◠NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p Active: active (running) since Sat 2017-01-21 01:39:25 UTC; 31min ago Main PID: 543 (NetworkManager) CGroup: /system.slice/NetworkManager.service ��└��─543 /usr/sbin/NetworkManager --no-daemon Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6761] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6777] poli Jan 21 02:06:27 orangepizero NetworkManager[543]: <warn> [1484964387.6790] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6810] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6821] mana Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6829] poli Jan 21 02:06:27 orangepizero NetworkManager[543]: <warn> [1484964387.6840] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6871] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6945] devi Jan 21 02:06:32 orangepizero NetworkManager[543]: <info> [1484964392.9635] devi My question is this, where should I go from here to debug this issue, has anyone seen the same or similar problems. I have been able to rebuild the kernel from sources using the Armbian tools, but that was a few days ago with 4.9.3 and now that 4.9.4 is in use, I haven't had time to try building it again. My thoughts were to turn on wifi debugging and see what messages came out. For my project I could use the legacy kernel, but I'd rather not. BTW. I AM in a rural area where the only AP's I see are my own, and there is little other traffic on 2.4G (this may not last forever, but today I can use 2.4G.)

Yes, it's too much. We can't take responsibility for the vendor's choice of the wireless chip. If you don't like the wireless status, you can blame either HW vendor for using XRadio chip on this board or yourself for buying this board and trusting in marketing specifications rather than actual end user feedback (which this forum is full of). It is working already for the nightly images, assuming only one USB storage device is connected and this storage is fast enough (USB HDDs that respond only after spinning up probably won't work). Officially it may be introduced in the next release.

cat /etc/hostapd/hostapd.conf interface=wlan0 hw_mode=g ctrl_interface=/var/run/hostapd ssid=holywifi_opi0 channel=11 wpa=2 wpa_passphrase=****** cat /etc/dnsmasq.d/wlan0.conf listen-address=192.168.43.1 interface=wlan0 bind-interfaces dhcp-range=192.168.43.100,192.168.43.200,12h resolv-file=/etc/resolv.dnsmasq.conf cat /etc/network/interfaces # This file intentionally left blank # # All interfaces are handled by network-manager, use nmtui or nmcli on # server/headless images or the "Network Manager" GUI on desktop images allow-hotplug wlan0 iface wlan0 inet static address 192.168.43.1 netmask 255.255.255.0 network 192.168.43.0 broadcast 192.168.43.255 gateway 192.168.43.1 uname -a Linux orangepizero 4.9.4-sun8i #2 SMP Fri Jan 20 10:22:01 CET 2017 armv7l armv7l armv7l GNU/Linux modinfo xradio_wlan filename: /lib/modules/4.9.4-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.ko alias: xradio_core license: GPL description: XRadioTech WLAN driver core author: XRadioTech alias: sdio:c*v0020d2281* depends: mac80211,cfg80211 intree: Y vermagic: 4.9.4-sun8i SMP mod_unload ARMv7 thumb2 p2v8

Huh? Ethernet isn't disabled by default and Wi-Fi can be disabled -- see post #37 in original thread (also remove the xradio... occurences from /etc/modules to prevent warnings in dmesg output)

Sure, but honestly... who cares? Please read through this thread where the guys who are actually working on improving the driver share some insights: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-xradio-st-cw1200/ The driver the mainline nightly image contains is based on dgp's version from 3 weeks ago and in the meantime he improved stuff. Unless you want to help these guys improving the driver (then using their most recent version of course!) any feedback on 'performance' seems pretty useless to me. It's ok for IoT stuff (sending/receiving small amounts of data from time to time) but as you can see above (your 30 second tests being delayed to 57.4 sec most probably due to excessive TX retransmits) you should lower expectations with the driver in its current state and this chip in general. This is 'as cheap as possible' WiFi and IMO it's pretty useless to 'benchmark' throughput anyway especially since we're talking about 2.4 GHz band here where you never can be sure that 'low througput' is not just the result of your 'shared media' (the specific radio frequency) being used by too many other 'devices' at the same time (Microwave ovens, USB3 peripherals [1], and of course other WiFi networks using the same channels and so on). But in your case and based on the breakdown from the aforementioned thread it's obvious that there's still something wrong in TX direction anyway. But again: without a reference providing numbers is useless (please compare with Martin's and dgp's iperf numbers that are way higher than yours). With reference I mean something like this: http://www.friendlyarm.com/Forum/viewtopic.php?f=42&t=379#p1222 (it's obvious that internal aerial of NanoPi M3 sucks compared to NanoPi Air with same WiFi chip but external aerial. But in my neighborhood 2.4 GHz band is close to unusable since way too overcrowded so you never know what's the reason the Air achieves only 20 Mbits/sec -- the tests were done at night since during the day and especially in the evening here 2.4 GHz is close to unusable) [1] At a small customer (agency using only MacBooks for all their stuff) they bought external USB3 harddrives and connected those to every Mac a while ago. Then complaints started their server would've been becoming slow. In the end only those Macs were affected using WiFi and only when the hourly TimeMachine backups ran. Fortunately we were able to figure out that due to a misconfiguration of the AP only 2.4 GHz band was used. Switching to 5 GHz was the obvious solution.

hi tnx for working wifi on 4.3.9 kernel but sometime it drop kernel (((((( root@OpenWrt:/# [ 1244.983831] ------------[ cut here ]------------ [ 1244.988569] WARNING: CPU: 0 PID: 626 at drivers/net/wireless/xradio/txrx.c:1526 xradio_tx_confirm_cb+0x460/0x54c [xradio_wlan] [ 1245.000018] Modules linked in: xradio_wlan mac80211 cfg80211 rfkill ccm g_ether usb_f_rndis usb_f_ncm usb_f_ecm usb_f_eem u_ether libcomposite sunxi_cir sun8i_ths cpufreq_dt thermal_sys [ 1245.016776] CPU: 0 PID: 626 Comm: xradio_bh Not tainted 4.9.3-sun8i #24 [ 1245.023392] Hardware name: Allwinner sun8i Family [ 1245.028126] [<c010bc29>] (unwind_backtrace) from [<c0108ea7>] (show_stack+0xb/0xc) [ 1245.035716] [<c0108ea7>] (show_stack) from [<c04283b7>] (dump_stack+0x67/0x74) [ 1245.042960] [<c04283b7>] (dump_stack) from [<c0119c45>] (__warn+0xa9/0xbc) [ 1245.049844] [<c0119c45>] (__warn) from [<c0119cc3>] (warn_slowpath_null+0x13/0x18) [ 1245.057464] [<c0119cc3>] (warn_slowpath_null) from [<bf904d89>] (xradio_tx_confirm_cb+0x460/0x54c [xradio_wlan]) [ 1245.067727] [<bf904d89>] (xradio_tx_confirm_cb [xradio_wlan]) from [<bf9093fb>] (wsm_tx_confirm+0xde/0xfc [xradio_wlan]) [ 1245.078671] [<bf9093fb>] (wsm_tx_confirm [xradio_wlan]) from [<bf90bda9>] (wsm_handle_rx+0x648/0xc38 [xradio_wlan]) [ 1245.089181] [<bf90bda9>] (wsm_handle_rx [xradio_wlan]) from [<bf90895d>] (xradio_bh_exchange+0x264/0x570 [xradio_wlan]) [ 1245.100036] [<bf90895d>] (xradio_bh_exchange [xradio_wlan]) from [<bf908de1>] (xradio_bh+0x178/0x2f8 [xradio_wlan]) [ 1245.110519] [<bf908de1>] (xradio_bh [xradio_wlan]) from [<c012de79>] (kthread+0x99/0xac) [ 1245.118628] [<c012de79>] (kthread) from [<c0105f31>] (ret_from_fork+0x11/0x20) [ 1245.125881] ---[ end trace 3bda58e40008b467 ]--- [ 1247.019292] sched: RT throttling activated

I checked on my router while I was doing my performance testing. The PHY was running as high as MCS 7 (65MBit with 20MHz channel @ 1T1R), and averaged around MCS 5 (52MBit) between the Orange Pi Zero and the AP. These are readings from the AP, not the Orange Pi Zero, so I'm fairly sure they're accurately reflecting the true state of the xradio PHY. Nothing was CPU-bound, yet I was still only getting 10MBit/sec with iperf. This was at less than 1m away from the AP, signal is at -14dBm and noise is -95dBm. Then again I normally use 5GHz because 2.4GHz is such a shit show in my building with all the neighbours' APs.

Thanks for the feedback. I agree on improving the XR819 driver. I was hoping that the cw1200 driver would bring some performance improvements since it's already in mainline, but it seems it's the same kludge as what we got from Allwinner. I guess when no one else is using the hardware the kludge never gets cleaned up. The reference driver checks the WORKSFORME box and moves on. Were the patches to cw1200 of any use for the XRADIO improvements?

Nice find. These still appear to be for some other variants of the hardware, testing versions perhaps? I'm comparing the cw1200 driver in mainline to the work from @dgp. The cw1200_wlan_sdio init sequence sends the bootloader, but then the bootloader signals it's not in the right state to download the main firmware, and at this point the module stops trying to initialize the chip. For some reason the DOWNLOAD_STATUS_REG is returning DOWNLOAD_ERR_IMAGE instead of DOWNLOAD_PENDING. ...I just realized I could find the errors in hwio.h, so I guess I don't actually need a datasheet from ST to figure out what this error means. I think I will add more debug statements to @dgp's xradio driver to see if I'm missing a setup step in the cw1200 init sequence.

Why it's about Armbian suddenly? It's not an official Orange Pi OS distribution, so it depends on vendor provided sources or on mainlining efforts. And I would prefer not to talk about "transparency" with all wireless modules that require closed-source firmware (this includes most if not all Realtek devices) eMMC != NAND in many ways. If you don't know what the differences are, please simply call it "the onboard storage". I don't want to create confusion for other users since NAND support is much more compilcated and MLC NAND support is not even mainlined yet. If it does nothing for you then please simply ignore it. If I understand it correctly, OPi Zero boards (at least one of two variants) is now shipped with soldered SPI flash and it didn't affect the proce. This: Any wireless chip can be good or bad depending on a use case and a price. If stability issues with XRadio will be resolved, then it will offer wireless connectivity for an IoT node - which it is's main purpose for this board and for its price. And I can't understand people who start benchmarking this type of wireless chips or even think about using it for a desktop/multimedia purpose.

That image posted by Hyphop on 4pda.ru is the same as the one created by following my Gist posted on GitHub from my previous posts. In fact I created my image and that gist following @hyphop's and @dreamdream's cues and directions. It uses Armbian uBoot and Kernel (including modules and firmware) and the rest is OpenWRT. If you read through my gist you will understand it. Since Wifi works on Armbian with a small tweak ( #printf "xradio_wlan" >> /etc/modules ) it will work on OpenWRT too with a similar tweak ( #printf "xradio_wlan\nxradio_wlan" >> /etc/modules.d/xradio_wlan ). The trick is you need to load xradio module twice because of a bug. We can make a generic sunxi build of openwrt to boot on OpiZero with Wifi support following this gist. https://gist.github.com/praveenbm5/3c81692e6b2b651bb450fb7fc45dff4d So if you can build a generic OpenWRT image with Wifi and other menus / pages / plugins enabled, it will be great.

In my case, after several issue, crappy cable, crappy sdcard, I got it working several times. But unfortunately, I got back into troubles again, I presume my PiZero has hardware issue. It is flooding the dmesg with the following lines : [ 28.399502] xradio_wlan mmc1:0001:1: Failed to read control register. [ 28.443148] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! [ 28.449194] sunxi-mmc 1c10000.mmc: data error, sending stop command [ 28.455622] sunxi-mmc 1c10000.mmc: send stop command failed [ 28.461347] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! [ 28.467458] sunxi-mmc 1c10000.mmc: data error, sending stop command [ 28.473820] sunxi-mmc 1c10000.mmc: send stop command failed Trying to SSH thru ETH, sometime take minutes to get to the prompt, probably due to flooding taking to much CPU. So, I will forget about WiFi for now until I get another PiZero. EDIT: In fact, even if xradio is commented in DT, the flooding still present, to get rid of it, I need to comment the whole mmc@01c10000.

Ok, guys ! I found my hardware issue : I've been caught myself with an SDCard that becames crappy ! For the xradio issue, I don't know if it was also related, but I've created image with Zador stuff, although I had to tweak a bit the DT, and it is now working fine. @Zador, the tweak needed is related to the fact that PL7 was already defined in PiOne, but due was slipped into pio instead of r_pio (same issue found few weeks ago for PiPC https://github.com/igorpecovnik/lib/commit/31c3133cf65af66197b0e78f92eae835615a90b1 ) I will commit this fix in few minutes along some removal in PiZero since we can reuse the PL7 from PiOne, simply by using same names. EDIT : here is the first fix : https://github.com/igorpecovnik/lib/commit/5fff38add9873b50bc71d540573e4294bc97c10d, and here the redundancy cleanup : https://github.com/igorpecovnik/lib/commit/fdaadb42d7587371a7cb7f1184ade5915cd77924#diff-ef59beeea2dd85451fb9bf2905fb7ebf and https://github.com/igorpecovnik/lib/commit/369d3928e7154ac12c34f0e2bc4ce0e24636cb4e#diff-ef59beeea2dd85451fb9bf2905fb7ebf

Most of those options will probably be removed at some point. The non power of 2 block size option for example has to be enabled or the firmware crashes. I'm slowly taking the useless stuff that allwinner/xradio have bolted on so that it's closer to the cw1200 driver in the kernel that it's based on.

@dgp, yes, I was trying to integrate xradio in armbian build process, it was the default configs. But since zador is faster than me, I think my effort are now useless. @zador, thanks for committing those changes, I will gave it a try when I get chance. (especially that this morning, my PiZero didn't even boot at all, I hope it doesn't end up to be hardware issue)

You can try to provide default options via separate Kconfig symbol like this (using "select"): config XRADIO_SDIO bool config XRADIO_USE_EXTENSIONS bool config XRADIO_5GHZ_SUPPORT bool config XRADIO_XR819 bool "XRADIO XR819 support" depends on WLAN_VENDOR_XRADIO select XRADIO_SDIO select XRADIO_USE_EXTENSIONS select XRADIO_5GHZ_SUPPORT default y

@dpg, I've tried to integrate your xradio work into my branch, it compiled properly. Using your sun8i-h2-orangepi-zero.dts, it was hanging on the CPU throotling, I don't know why. So, I decided to merge only xradio stuff into plain copy of sun8i-h3-orangepi-one.dts. No more hand, but a flood of mmc error when network is started, such as : Dec 28 17:04:12 localhost kernel: [ 40.171288] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! Dec 28 17:04:12 localhost kernel: [ 40.177230] sunxi-mmc 1c10000.mmc: data error, sending stop command Dec 28 17:04:12 localhost kernel: [ 40.183531] sunxi-mmc 1c10000.mmc: send stop command failed Dec 28 17:04:12 localhost kernel: [ 40.189150] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !! Dec 28 17:04:12 localhost kernel: [ 40.195093] sunxi-mmc 1c10000.mmc: data error, sending stop command Dec 28 17:04:12 localhost kernel: [ 40.201387] sunxi-mmc 1c10000.mmc: send stop command failed Dec 28 17:04:12 localhost kernel: [ 40.206982] xradio_wlan mmc1:0001:1: Failed to read control register. Looking more at this big syslog, I could see that it has actually got it IP from DCHP, but it is a bit after that it start flooding. Do you have any ideas why I'm unable to make it working ?

Probably some generic userspace related instructions like setting up /etc/network/interfaces. Allwinner specific stuff like xradio kernel module should work out of the box and doesn't need any instructions in stable leleases AFAIK.

1. yes, SPI NOR will only be used to load u-boot. Normal rules apply once the kernel is running. 2. U-boot already inserts fixed MAC addresses based on the unique chip ID from the processor if you kernel device tree is setup correctly. Works for both wired and wireless on mainline with my xradio driver 3. no idea 4. u-boot on SPI NOR is enough for booting a kernel over the wired interface with TFTP etc. You can then use an NFS rootfs to have a diskless setup. SPI NOR should be cheaper and more mechanically reliable (soldered on instead of a connector) than an SD card.... and if you get a chip that supports it you can write protect the blocks with the SPL/u-boot and make it pretty hard to break. Main con is that 100mbit isn't all that fast.. but if you run everything out of RAM it doesn't matter once booted.

Does it work if you disable WPA in hostapd? I'm working on fixing hostapd with WPA for my mainline version of the xradio driver and what I can see is that clients authenticate and associate but the handshake for WPA never happens and the client disconnects. There seems to be some disconnection between hostapd and the driver because the driver doesn't get anything to transmit between the association completing and the client sending it's deauth on disconnect. It might be hostapd expecting the chip to offload (do it itself) that part. :/

FCC certification would be on a module or a product containing the chip as far as I know. There is a WiFi cert (http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA61880) for the chip/driver that is dated September 2015 and it looks like the bits to make the driver compliant were hacked in after the driver was completed. My guess is that this chip became available in 2015 (datasheet also has that date, but says it's from a company called xradio) but it's based on something that's been kicking around for a while and that's why the driver has older dates in it. I will upload the electrical datasheet somewhere if I remember but it's not really that interesting. The only interesting thing from a driver perspective are the timings for the reset pin. The block level diagram shows the radio parts but none of the processing parts.

I'm not sure asking the Xunlong guys is going to get very far, but it's worth a shot. The Orange Pi is popular, but these SBCs are a niche market, I don't think Xunlong is a high volume seller of Allwinner chips. I think the best chance is to wait until something else using the XRADIO is shipping (probably something Android based) and then bother that manufacturer for the module source code/documentation. It's too bad that Allwinner doesn't see the value of open source. They could have an XRADIO driver in mainline kernel quite quickly if they were willing to release the datasheet. The way now is wasted effort for us (trying to reverse engineer without documentation) and them (having a crappy driver).

To save confusion, talking about this https://github.com/fifteenhex/xradio/tree/original onthe mainline kernel. I now have station + ap mode working.. so you can have the pi zero connected to wifi and acting as it's own ap. This is probably useful for a lot of potential applications for doing the initial wifi setup. Only downside is the station and ap side need to be on the same channel at the moment.

Look at the big readme the original branch has https://github.com/fifteenhex/xradio/tree/original or take a look at the device tree I am using https://github.com/fifteenhex/linux/blob/orangepizero/arch/arm/boot/dts/sun8i-h2-orangepi-zero.dts The unmodified driver tries to power up and detect the chip when the module loads and fails the module loading if it fails. My version decouples that. So the module can be loaded even if the chip hasn't been detected. You should see on boot the MMC subsystem telling you that a new SDIO card has been detected. If you have that when you load the module it'll get probed and wlan0 should appear.

Hi everyone, Got problem with WiFi using nightly kernel. I installed Armbian_5.24.161219_Orangepizero_Ubuntu_xenial_4.9.0.7z and upgraded the nightly repo via sed -i "s/apt/beta/" /etc/apt/sources.list.d/armbian.list apt-get update apt-get upgrade then copied the repo from github.com/fifteenhex/xradio and compiled the kernel with root@orangepizero:# make -C /lib/modules/4.9.0-sun8i/build M=`pwd` modules -j4 root@orangepizero:# cp xradio_wlan.ko /lib/modules/4.9.0-sun8i/kernel/drivers/net/wireless root@orangepizero:# depmod -a root@orangepizero:# modprobe xradio_wlan and loaded the kernel module properly. dmesg: [ 246.402613] xradio_wlan: loading out-of-tree module taints kernel. [ 246.404432] xradio_wlan: unknown parameter 'macaddr' ignored But there are no interface available at ifconfig -a as a wlan0. I also tried original branch of xradio with same result. Can you guess why?