Search the Community

There were a lot of insanely stupid complaints about this but besides that there are/were also real issues like dropped frames and no way to cure this back then (due to lack of documentation and software). Since this NanoPi Duo image will run on every H2+/H3 board around I simply booted it and had a look. root@NanoPi-M1:/lib/firmware/xr819# ls -la -rw-r--r-- 1 root root 2308 Aug 29 06:37 boot_xr819.bin -rw-r--r-- 1 root root 975 Aug 29 06:37 device-xradio.mk -rw-r--r-- 1 root root 126416 Aug 29 06:37 fw_xr819.bin -rw-r--r-- 1 root root 744 Aug 29 06:37 sdd_xr819.bin root@NanoPi-M1:/lib/firmware/xr819# md5sum * 049abcb4768e92490f9fcafff114d1eb boot_xr819.bin 01a5e63ddf60e2a4af5b073cec783bb7 device-xradio.mk 7a313e6957e635d9c1cd0d6902739d14 fw_xr819.bin e5d4afaf1a8c24f79f6764c289f1102f sdd_xr819.bin That's at least no new firmware (contents identical as what ships with Armbian's firmware package). Let's look at the driver: root@NanoPi-M1:~# modinfo xradio_wlan filename: /lib/modules/4.11.2/extra/xradio_wlan.ko alias: xradio_core license: GPL description: XRadioTech WLAN driver core author: XRadioTech alias: sdio:c*v0020d2281* depends: vermagic: 4.11.2 SMP mod_unload ARMv7 p2v8 Interested OPi Zero users could simply give the nanopi-duo_ubuntu-core-xenial_4.11.2_20170829.img a try and on the other hand NanoPi Duo is that inexpensive that interested persons simply should order one and try it out themselve (reporting back of course).

MAC address should be set by u-boot first. In order to find network devices it looks for aliases named ethernetX (where X is a number) pointing to the network devices DT nodes. In the source DT an alias looks like this: https://github.com/megous/linux/blob/orange-pi-4.11/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts#L58 Regarding the wireless driver - no idea if it supports a fixed MAC address and what method should be used for it. Edit: the first OPi Zero uses the XRadio driver, not a Realtek one, and current mainline images don't have this driver at all in the kernel sources due to many issues with it) If you are using mainline kernel for production and it works good enough for you (even though I would not recommend it, especially for OPi Zero) - okay, fine, but please use apt-mark hold to freeze the kernel, DT and board support packages (or remove /etc/apt/sources.list.d/armbian.list) to minimize the chance of getting a 200 waterproof useless bricks broken by the upgrade.

Same NanoPi M1, RTL8152 attached to usb1, only the USB-Ethernet connected to network, our OPi Zero image booting flawlessly (no need for udev rules IMO): http://sprunge.us/eLJP The xradio driver fails as expected and with Zero's default /etc/network/interfaces contents (none) it should be also easy to bring up RTL8189ETV if present on the board (to be confirmed). Since I don't have any devices with RTL8189ETV maybe someone else (@Igor?) can give it a try booting our Zero image on an OPi Plus and check whether nmtui just works? If that's ok, all further development efforts are two lines adding to documentation / download page.

Wifi on this device is done by XR819, module name is xradio, like on Orangepi Zero. Changing link to right board config might help /boot/script.bin -> bin/orangepione.bin to bin/orangepizero.bin Performance of this chip is bad, so don't expect too much.

Rev. 1.4 problems are related only to the first Zero (one with the Ethernet and Xradio wireless), Zero Plus 2 has better wireless and shouldn't have any serious overheating issues. This applies to all H2+ and H3 devices - quality of the legacy kernel is not the best, and mainline will be much more stable.

start here... https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/ the zero works fine in IoT projects, thing is some folks think a cheap 7.00 board can replace 200.00 of x86 gear. ap limit of 5 connections, weak wi-fi signal, crappy stock antenna, weak psu = failure before they start Igor did build a 4.1x image with wi-fi it is linked here

Repository README: https://github.com/fifteenhex/xradio/blob/master/README.md Discussion: https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/

Some test result using iperf. Distance to AP ca. 5m line of sight. Zero as client: [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 17.4 MBytes 14.6 Mbits/sec [ 3] 10.0-20.0 sec 17.6 MBytes 14.8 Mbits/sec [ 3] 20.0-30.0 sec 17.4 MBytes 14.6 Mbits/sec [ 3] 30.0-40.0 sec 17.9 MBytes 15.0 Mbits/sec [ 3] 40.0-50.0 sec 16.6 MBytes 13.9 Mbits/sec [ 3] 50.0-60.0 sec 17.2 MBytes 14.5 Mbits/sec [ 3] 0.0-60.1 sec 104 MBytes 14.5 Mbits/sec Zero as server: [ 4] 0.0-61.3 sec 96.9 MBytes 13.3 Mbits/sec dmesg reports no xradio related drops/errors.

Oh ! You're right ! Back in May, when I've done the job, and when we decided to remove that support, I've never committed the patch fix, it is sitting on my tree : diff lib/patch/kernel/sun8i-dev/add-xradio-wireless-driver.patch.disabled lib/patch/kernel/sun8i-dev/add-xradio-wireless-driver.patch 1902c1902 < @@ -0,0 +1,880 @@ --- > @@ -0,0 +1,884 @@ 1922a1923,1926 > +struct sched_param { > + int sched_priority; > +}; > + 1948d1951 < + struct sched_param param = { .sched_priority = 1 }; 1963a1967 > + struct sched_param param = { .sched_priority = 1 }; 12076c12080 < @@ -0,0 +1,266 @@ --- > @@ -0,0 +1,267 @@ 12092a12097 > +#include <linux/module.h> 13601c13606 < + ieee80211_cqm_rssi_notify(priv->vif, cqm_evt, --- > + ieee80211_cqm_rssi_notify(priv->vif, cqm_evt, rcpiRssi, I will probably commit it soon, but leaving it disabled ...

Thank you, @martinayotte. Hmm, if I rename add-xradio-wireless-driver.patch.disabled to -xradio-wireless-driver.patch (and move it to userpatches/kernel/sun8i-dev/) I get fatal compiler errors: drivers/net/wireless/xradio/bh.c: In function ‘xradio_register_bh’: drivers/net/wireless/xradio/bh.c:46:9: error: variable ‘param’ has initializer but incomplete type struct sched_param param = { .sched_priority = 1 }; ^~~~~~~~~~~ drivers/net/wireless/xradio/bh.c:46:32: error: ‘struct sched_param’ has no member named ‘sched_priority’ struct sched_param param = { .sched_priority = 1 }; ^~~~~~~~~~~~~~ drivers/net/wireless/xradio/bh.c:46:49: warning: excess elements in struct initializer struct sched_param param = { .sched_priority = 1 }; ^ drivers/net/wireless/xradio/bh.c:46:49: note: (near initialization for ‘param’) drivers/net/wireless/xradio/bh.c:46:21: error: storage size of ‘param’ isn’t known struct sched_param param = { .sched_priority = 1 }; ^~~~~ drivers/net/wireless/xradio/bh.c:46:21: warning: unused variable ‘param’ [-Wunused-variable] scripts/Makefile.build:294: recipe for target 'drivers/net/wireless/xradio/bh.o' failed make[4]: *** [drivers/net/wireless/xradio/bh.o] Error 1 scripts/Makefile.build:553: recipe for target 'drivers/net/wireless/xradio' failed make[3]: *** [drivers/net/wireless/xradio] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/net/wireless' failed make[2]: *** [drivers/net/wireless] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 make[1]: *** Waiting for unfinished jobs.... The diff used by the above patch appears pre 4.11. Am I missing something here?

just a note, if you do a ping test to lets say 8.8.8.8, it will be VERY erratic, like 300ms, 200ms, 600ms,200ms etc. but if u do a ping test after sudo ping -s 1 -i 0.2 <orangePiWifiIp> you will see 1ms 1ms 2ms 3ms 1ms... etc. the xradio needs 'constant' connectivity to have a 'smooth' output i realize.

@martinayotte Would you update the actual driver code to your build as well? It seems the driver code in the current add-xradio-wireless-driver.patch.disabled is still pre 4.11.

For the changes to DTS, maybe I can look to append them directly into the add-xradio-wireless-driver.patch.disabled when I will get chance.

I hope so. You could try my userpatch until he does: https://drive.google.com/file/d/0B47UwibE8mfvRXYzR0p4SGJ4Vnc/view?usp=sharing Copy it to userpatches/kernel/sun8i-dev/ Don't forget to set KERNEL_CONFIGURE="yes" and set XRADIO to manual (m).

And this is possible already using the userpatches functionality. @martinayotte or anybody else can update existing xradio patch while leaving it disabled, and developers who build their own kernels will have a relatively easy way to activate it by copying or symlinking this patch and using KERNEL_CONFIGURE=yes to change the kernel config.

That's great news at least this solution will be a solution from some users. The driver is crapy but at least permit transmitting wireless which is a must in some applications. I understand to not include the solution in standard images. There is , however, the option to include as an option in the build tool for those that assume the risk of this crashy driver. As far as I understood to make it work it is needed to do following steps: build with newest patches that solve (aes-arm) crashes. Use correct fifteenhex' driver compatible with 4.11. I think this can be done changing the current add-xradio-wireless-driver.patch.disabled with the correct version. Still if it is remain as disabled it could be enabled manually by the user and compile the correct version. Use XRADIO_* kernel settings to activate the configuration and compilation. By default they can be commented (unset) but the user can remove the contents and get the driver compiled installed in custom builds. Provide a suitable DTS that inform the kernel that the xr819 is present with valid params. Current build system do not do configure it. Can this be done with an overlay? If yes then it can be included in the overlay section of the build script so it get compiled and can be activated by the user in armbianEnv.txt. If this approach is possible we can find a compromise between not supporting the driver in standard images but easy for custom compilation activation. What do you think? Regards,

It just fixes it barely enough to work without crashing (and fix is not related to the xradio driver, it's a kernel-wide fix) My opinion here would be "definitely no", we had enough crap about this driver and none of that was fixed (packet losses, open AP connection, virtual interfaces, P2P mode, etc.)

Yes, thanks Zador to have figured out ! I've tested it on my side too, and right, it fix the xradio perfectly ! Maybe we should re-enabled it in the nightlies ?

@raschid, @martinayotte I was able to compile the driver under 4.11 using this version: https://github.com/fifteenhex/xradio/commit/3f80a7c69a4d00b93bb187edc6beef2b4c38bada. Also I mokypatched the current patch in armbian/build to align the driver compiled during image build process including the XRADIO_* settings. The build is correct and the driver is loaded when booted: Linux orangepizero 4.11.5-sun8i #2 SMP Fri Jun 23 14:44:29 CEST 2017 armv7l GNU/Linux root@orangepizero:~# lsmod Module Size Used by sunxi_cir 16384 0 xradio_wlan 102400 1 sun8i_codec_analog 24576 0 mac80211 335872 1 xradio_wlan cfg80211 204800 2 mac80211,xradio_wlan still no wlan0 is available. It is possible that it has to be with associated DTS files that have been changed also. I'm trying with an overlay to properly configure it but still no success. I'm not an expert on Device-tree but it seems to be in-line with the needs to make the driver work. When loading the overlay there a msg showing that there are duplicate entries and lots of warnings in the compilation. /dts-v1/ /plugin/; / { compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus", "allwinner,sun8i-h3"; fragment@0 { target = "/aliases"; __overlay__ { ethernet1 = &xr819wifi; }; }; fragment@1 { target = "/reg_vcc_wifi"; __overlay__ { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; startup-delay-us = <70000>; }; }; fragment@2 { target = "/wifi_pwrseq"; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <&wifi_rst>; }; }; fragment@3 { target = <&mmc1>; __overlay__ { vmmc-supply = <&reg_vcc3v3>; vqmmc-supply = <&reg_vcc_wifi>; /*max-frequency = <16000000>; */ /delete-node/ xr819; xr819wifi: sdio_wifi@1 { reg= <1>; compatible = "xradio,xr819"; pinctrl-names = "default"; pinctrl-0 = <&wifi_wake>; interrupt-parent = <&pio>; interrupts = <6 10 1>; interrupt-names = "host-wake"; local-mac-address = [dc 44 6d c0 ff ee]; }; }; }; fragment@4 { target = <&pio>; __overlay__ { wifi_wake: wifi_wake@0 { allwinner,pins = "PG10"; allwinner,function = "irq"; allwinner,pull= <0>; }; }; }; fragment@5 { target = <&r_pio>; __overlay__ { wifi_rst: wifi_rst@0 { allwinner,pins = "PL7"; allwinner,function = "gpio_out"; allwinner,drive = <0>; allwinner,pull = <0>; }; }; }; }; Any Idea?

Thanks for the links. But i normally build my own images using lib build tools. I tried to build version 4.10 with xradio support but I cant do it with current master branch. any idea how to get the last version of build tools that will enable that. regards,

I did a big mistake updating to 4.11. So called crappy Xradio has been working great for me with 4.10. Is there any possibility to undo the update?

exquisitus, I don't see how jhpadjustable's reply was patronizing, prejudiced, or full of attitude. He politely said that if you want to know the history of the module (and why it's not well supported) there are other threads talking about it. I really don't see how his reply is "less useful than no reply at all" since he told you where you can find more information (something you can also do with the forum's search feature). When people here provide information to users, and then get replies like yours, it's no wonder the driver situation doesn't improve. Anyone who is working to make it better just gets people coming and being offended by their answers. If you're unhappy with the state of the XR819 driver, I have the perfect place for you to go to solve your problems: https://github.com/fifteenhex/xradio/pulls I hate to say it, I really do, but I think you need to see this: https://www.youtube.com/watch?v=F-mju_gW3c8

@raschid They didn't add the latest fix https://github.com/fifteenhex/xradio/commit/3f80a7c69a4d00b93bb187edc6beef2b4c38bada

I would also like to get the wireless of the Orange Pi Zero working fully. Limited bandwidth is not a problem for my use case. I'm a competent programmer, but normally try to stay away from kernel code. If this isn't too much work, I'm willing to make an exception. To know that, and also to get started, I need to know what needs to be done though. My observations so far: When the xradio module is loaded, the load average is at least 1.0. It seems to be busy waiting whenever it's not doing anything useful. Unloading the module makes the system load reasonable (near 0). The wifi interface works, but when creating other virtual interfaces (iw dev wlan0 interface add), they show up as if they're working, but no communication is possible with them (they also don't find any networks when scanning). Please let me know where I should start if I want to fix things, so I can see if it's worth my time. Thanks!

OK, somewhat obvious: forgot to set CONFIG_WLAN_VENDOR_XRADIO in the kernel config-file. This time compiling the kernel failed, partly due to the face, that the current "add-xradio-wireless-driver"-patch has not been updated to the 4.11 version. Nope, I do not think it is ... (e.g. missing parameter for ieee80211_cqm_rssi_notify function etc.)