Search the Community

ARMBIAN 5.41 user-built Debian GNU/Linux 9 (stretch) 4.14.34-sunxi, Orange Pi Zero board. Very limited Debian installed, wifi doesn't work. I found lines install xradio_wlan /bin/false install 8189es /bin/false in /etc/modprobe.d/blacklist.conf and removed it. In /etc/modules-load.d/modules.conf I added the lines 8189es xradio_wlan. No help, wi-fi didn't work, nothing about xradio or wifi in dmesg. I figured out that there was no drivers (modules) for wifi. Found this article https://linux-sunxi.org/Wifi I execute the commands from the article, section RTL8189ES / RTL8189ETV The driver has its own repository: git clone https://github.com/jwrdegoede/rtl8189ES_linux.git cd rtl8189ES_linux make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- KSRC=../linux This is what it says root@its-02-o:~# git clone https://github.com/jwrdegoede/rtl8189ES_linux.git Cloning into 'rtl8189ES_linux'... remote: Enumerating objects: 2565, done. remote: Counting objects: 100% (807/807), done. remote: Compressing objects: 100% (413/413), done. remote: Total 2565 (delta 432), reused 670 (delta 385), pack-reused 1758. Receiving objects: 100% (2565/2565), 7.29 MiB | 2.32 MiB/s, done. Resolving deltas: 100% (1476/1476), done. root@its-02-o:~# cd rtl8189ES_linux root@its-02-o:~/rtl8189ES_linux# make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- KSRC=../linux make ARCH=arm CROSS_COMPILE=arm-linux-gnu- -C ../linux M=/root/rtl8189ES_linux modules make[1]: *** ../linux: No such file or directory. Stop. Makefile:2292: recipe for target 'modules' failed make: *** [modules] Error 2 root@its-02-o:~/rtl8189ES_linux# What am I doing wrong? How do I install WiFi modules (drivers)? And the following is in the dmesg vcc-wifi: disabling What is this wifi power disabling? How do I turn it on? Googling didn't help, I couldn't find anything clear about vcc-wifi: disabling Don't suggest installing a new/other Debian. Important software works on it (everything works over LAN), you just need to enable wi-fi. Translated with www.DeepL.com/Translator (free version) ARMBIAN 5.41 user-built Debian GNU/Linux 9 (stretch) 4.14.34-sunxi, плата Orange Pi Zero. Очень какой-то урезаный Debian установлен, не работает Wi-Fi. Нашел в файле /etc/modprobe.d/blacklist.conf строки install xradio_wlan /bin/false install 8189es /bin/false, удалил. В файле /etc/modules-load.d/modules.conf добавил строки 8189es xradio_wlan. Не помогло, wi-fi не заработал, в dmesg ничего про xradio или wifi нет. Понял что нет драйверов (модулей) Wi-Fi. Нашел такую статью https://linux-sunxi.org/Wifi Выполняю комманды из статьи, раздел RTL8189ES / RTL8189ETV Driver has its own repository: git clone https://github.com/jwrdegoede/rtl8189ES_linux.git cd rtl8189ES_linux make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- KSRC=../linux Вот что пишет root@its-02-o:~# git clone https://github.com/jwrdegoede/rtl8189ES_linux.git Cloning into 'rtl8189ES_linux'... remote: Enumerating objects: 2565, done. remote: Counting objects: 100% (807/807), done. remote: Compressing objects: 100% (413/413), done. remote: Total 2565 (delta 432), reused 670 (delta 385), pack-reused 1758 Receiving objects: 100% (2565/2565), 7.29 MiB | 2.32 MiB/s, done. Resolving deltas: 100% (1476/1476), done. root@its-02-o:~# cd rtl8189ES_linux root@its-02-o:~/rtl8189ES_linux# make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- KSRC=../linux make ARCH=arm CROSS_COMPILE=arm-linux-gnu- -C ../linux M=/root/rtl8189ES_linux modules make[1]: *** ../linux: No such file or directory. Stop. Makefile:2292: recipe for target 'modules' failed make: *** [modules] Error 2 root@its-02-o:~/rtl8189ES_linux# Что не так делаю? Как установить модули (драйвера) WiFi? А вот такое в dmesg есть vcc-wifi: disabling Что это питание wifi отключено? Как включить? Гугление не помогло, не нашел ничего внятного про vcc-wifi: disabling Не предлагайте установить новый/другой Debian. На нем работает работает важный софт (по LAN все работает), нужно просто включить wi-fi. Если можно на русском. Английский только с переводчиком :-(

Good afternoon, I run Armbian bullseye on my orangepi zeroplus2-h3. My wifi hotspot causes the OS to reboot sometimes, with the error "xradio WSM-ERR: bh error!>>> 0x0012 (16)" I use the NetworkManager conf files below for my wifi hotspot. echo """ [connection] id=mywifi uuid=58356325-7da4-4d1d-ad6b-54f33bfee335 type=wifi autoconnect=false interface-name=wlan0 permissions= [wifi] band=bg mac-address-blacklist= mode=ap ssid=IQLINK-1 [wifi-security] key-mgmt=wpa-psk psk=123456789 [ipv4] address1=192.168.43.1/24 dns-priority=2 dns-search= method=shared route-metric=2 [ipv6] addr-gen-mode=stable-privacy dns-priority=2 dns-search= method=auto route-metric=2 """ > /etc/NetworkManager/system-connections/mywifi.nmconnection echo """[main] dns=default rc-manager=file plugins=ifupdown,keyfile [ifupdown] managed=true [device] match-device=driver:wlan0 wifi.scan-rand-mac-address=no """ > /etc/NetworkManager/NetworkManager.conf I get the syslog error below and the OS reboot : Feb 2 13:17:37 myhostname kernel: [ 2583.698290] xradio WSM-ERR: bh error!>>> 0x0006 (12) Feb 2 13:17:37 myhostname kernel: [ 2583.698301] ------------[ cut here ]------------ Feb 2 13:17:37 myhostname kernel: [ 2583.698307] WARNING: CPU: 1 PID: 996 at drivers/net/wireless/xradio/ap.c:645 xradio_bss_info_changed+0x72f/0xb04 [xradio_wlan] Feb 2 13:17:37 myhostname kernel: [ 2583.698376] Modules linked in: binfmt_misc nft_chain_nat xt_MASQUERADE xt_state xt_conntrack ipt_REJECT nf_reject_ipv4 nft_counter xt_tcpudp nft_compat nf_tables nfnetlink nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_conntrack_pptp nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 option usb_wwan qmi_wwan usbserial cdc_wdm lz4hc lz4 zram xradio_wlan mac80211 smsc cfg80211 nls_iso8859_1 sun4i_gpadc_iio industrialio smsc95xx cdc_acm usbnet sun8i_thermal rfkill libarc4 uio_pdrv_genirq uio cpufreq_dt usb_f_acm u_serial g_serial libcomposite ip_tables x_tables autofs4 pwrseq_simple sunxi phy_generic Feb 2 13:17:37 myhostname kernel: [ 2583.698679] CPU: 1 PID: 996 Comm: wpa_supplicant Tainted: G W 5.15.89-sunxi #trunk Feb 2 13:17:37 myhostname kernel: [ 2583.698694] Hardware name: Allwinner sun8i Family Feb 2 13:17:37 myhostname kernel: [ 2583.698708] [<c010cd21>] (unwind_backtrace) from [<c01095f5>] (show_stack+0x11/0x14) Feb 2 13:17:37 myhostname kernel: [ 2583.698737] [<c01095f5>] (show_stack) from [<c09e10b5>] (dump_stack_lvl+0x2b/0x34) Feb 2 13:17:37 myhostname kernel: [ 2583.698766] [<c09e10b5>] (dump_stack_lvl) from [<c011c439>] (__warn+0xad/0xc0) Feb 2 13:17:37 myhostname kernel: [ 2583.698792] [<c011c439>] (__warn) from [<c09dada7>] (warn_slowpath_fmt+0x43/0x7c) Feb 2 13:17:37 myhostname kernel: [ 2583.698813] [<c09dada7>] (warn_slowpath_fmt) from [<bf9d6f47>] (xradio_bss_info_changed+0x72f/0xb04 [xradio_wlan]) Feb 2 13:17:37 myhostname kernel: [ 2583.698873] [<bf9d6f47>] (xradio_bss_info_changed [xradio_wlan]) from [<bf940a79>] (ieee80211_bss_info_change_notify+0x79/0x174 [mac80211]) Feb 2 13:17:37 myhostname kernel: [ 2583.699288] [<bf940a79>] (ieee80211_bss_info_change_notify [mac80211]) from [<bf952fd3>] (ieee80211_do_open+0x19f/0x5e8 [mac80211]) Feb 2 13:17:37 myhostname kernel: [ 2583.699678] [<bf952fd3>] (ieee80211_do_open [mac80211]) from [<bf9535bf>] (ieee80211_if_change_type+0x147/0x254 [mac80211]) Feb 2 13:17:37 myhostname kernel: [ 2583.700058] [<bf9535bf>] (ieee80211_if_change_type [mac80211]) from [<bf959373>] (ieee80211_change_iface+0x23/0x19c [mac80211]) Feb 2 13:17:37 myhostname kernel: [ 2583.700441] [<bf959373>] (ieee80211_change_iface [mac80211]) from [<bf8c3ff7>] (cfg80211_change_iface+0x107/0x2e4 [cfg80211]) Feb 2 13:17:37 myhostname kernel: [ 2583.701188] [<bf8c3ff7>] (cfg80211_change_iface [cfg80211]) from [<bf8e28cd>] (nl80211_set_interface+0xc9/0x164 [cfg80211]) Feb 2 13:17:37 myhostname kernel: [ 2583.701568] [<bf8e28cd>] (nl80211_set_interface [cfg80211]) from [<c08d9555>] (genl_rcv_msg+0x125/0x27c) Feb 2 13:17:37 myhostname kernel: [ 2583.701761] [<c08d9555>] (genl_rcv_msg) from [<c08d899d>] (netlink_rcv_skb+0x81/0xb4) Feb 2 13:17:37 myhostname kernel: [ 2583.701781] [<c08d899d>] (netlink_rcv_skb) from [<c08d8f9d>] (genl_rcv+0x21/0x30) Feb 2 13:17:37 myhostname kernel: [ 2583.701799] [<c08d8f9d>] (genl_rcv) from [<c08d8301>] (netlink_unicast+0x125/0x1a4) Feb 2 13:17:37 myhostname kernel: [ 2583.701816] [<c08d8301>] (netlink_unicast) from [<c08d851b>] (netlink_sendmsg+0x19b/0x36c) Feb 2 13:17:37 myhostname kernel: [ 2583.701834] [<c08d851b>] (netlink_sendmsg) from [<c08601ef>] (sock_sendmsg+0x23/0x2c) Feb 2 13:17:37 myhostname kernel: [ 2583.701858] [<c08601ef>] (sock_sendmsg) from [<c0860495>] (____sys_sendmsg+0x181/0x194) Feb 2 13:17:37 myhostname kernel: [ 2583.701877] [<c0860495>] (____sys_sendmsg) from [<c08615e5>] (___sys_sendmsg+0x49/0x64) Feb 2 13:17:37 myhostname kernel: [ 2583.701898] [<c08615e5>] (___sys_sendmsg) from [<c08618a7>] (__sys_sendmsg+0x37/0x58) Feb 2 13:17:37 myhostname kernel: [ 2583.701918] [<c08618a7>] (__sys_sendmsg) from [<c0100061>] (ret_fast_syscall+0x1/0x52) Feb 2 13:17:37 myhostname kernel: [ 2583.701939] Exception stack(0xcfdedfa8 to 0xcfdedff0) Feb 2 13:17:37 myhostname kernel: [ 2583.701954] dfa0: 01d9d868 01da4288 00000006 beb3f7c8 00000000 00000000 Feb 2 13:17:37 myhostname kernel: [ 2583.701968] dfc0: 01d9d868 01da4288 b6f651f0 00000128 b6f46000 00000001 00000004 01db6c68 Feb 2 13:17:37 myhostname kernel: [ 2583.701977] dfe0: 00000128 beb3f778 b6b5765f b6ad07e6 Feb 2 13:17:37 myhostname kernel: [ 2583.702054] ---[ end trace e554f90c3b6dcdf3 ]--- Feb 2 13:17:37 myhostname kernel: [ 2583.702077] xradio WSM-ERR: bh error!>>> 0x0012 (16) Feb 2 13:17:37 myhostname kernel: [ 2583.702087] xradio STA-ERR: wsm_set_tx_queue_params failed! Feb 2 13:17:37 myhostname kernel: [ 2583.702093] xradio WSM-ERR: bh error!>>> 0x0012 (16) Feb 2 13:17:37 myhostname kernel: [ 2583.702100] xradio STA-ERR: wsm_set_tx_queue_params failed! Feb 2 13:17:37 myhostname kernel: [ 2583.702106] xradio WSM-ERR: bh error!>>> 0x0012 (16) Feb 2 13:17:37 myhostname kernel: [ 2583.702112] xradio STA-ERR: wsm_set_tx_queue_params failed! Feb 2 13:17:37 myhostname kernel: [ 2583.702117] xradio WSM-ERR: bh error!>>> 0x0012 (16) Feb 2 13:17:37 myhostname kernel: [ 2583.702124] xradio STA-ERR: wsm_set_tx_queue_params failed! Feb 2 13:17:39 myhostname systemd[1]: systemd-rfkill.service: Succeeded. Thanks for your help. Clouvis

Description Enabling wireless driver found on many Orange Pi boards. Jira reference number AR-1486 How Has This Been Tested? [ ] Test wireless connection Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Description The current xradio patch causes the wifi mac address to randomize after every reboot on kernel 5.13+ Modified it to use the updated of_get_mac_address function on kernel 5.13+ and get a stable mac address How Has This Been Tested? Tested patch with 5.15.85 kernel on 3 aw-h6-tv boards. The wifi mac address is now stable/unique and not randomized after every reboot Checklist: [X] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [X] Any dependent changes have been merged and published in downstream modules View the full article

Description switched to most recent upstream source fixed wrong header location For 5.19.y and up there is a lot more work, so this will wait for someone else. Jira reference number AR-1316 How Has This Been Tested? [x] Build sunxi and sunxi64 CURRENT Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Changes in kernel 5.19.2 -> are responsible to adjust the code yet again I tried, but I find myself running in the circles ... Anyone more familiar with this driver? @arclight @piknew @Skupsy @Icenowy We are still attached to @karabekfork https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L418-L424 but this https://github.com/dbeinder/xradio/commits/karabek_rebase looks like most recent.

I believe this patch is causing, for kernels >= 5.13 - section of setting up mac address is skipped: https://github.com/armbian/build/blob/master/patch/misc/wireless-xradio-5.13.patch I do not have the knowledge - what was stated behind of this patch... For me the problem is that generally I have a policy to name network interface with mac. And currently on OPI Zero - this is making my wlan interface "random".

hello armbian developers recently i have tried to built my own kernel from linus' kernel tree(5.18.1). the build config i use cames from armbian 22.05 bullseye(5.15.43-sunxi) /boot/config-5.15.43-sunxi ,without any changes. the kernel was ok to boot,so i plan to add xr819 support for it，but after days of work，it seems not as easy as i thought. the driver ive tried is from here(https://github.com/karabek/xradio)，but it cant detect chip's hardware revision: [ 13.036884] xradio: XR819 device discovered [ 13.038054] xradio_wlan mmc1:0001:1: no mac address provided, using random [ 13.064445] xradio ERR: FWIO: Unknown hardware: -1. [ 13.064547] xradio ERR: BH: bh thread exiting [ 13.064893] xradio PM-DEV: xradio_pm_release but the stock armbian image works well(5.15.43-sunxi). so i have added a printk to make config reg value visible: ret = xradio_reg_read_32(hw_priv, HIF_CONFIG_REG_ID, &val32); printk(KERN_WARNING "xradio_wlan: read config reg value: 0x%x\n",val32); if (ret < 0) { xr_printk(XRADIO_DBG_WARN, "FWIO: can't read config register, err=%d.\n", ret); return ret; } on 5.15.43: [ 11.737046] xradio: XR819 device discovered [ 11.737725] xradio_wlan mmc1:0001:1: no mac address provided, using random [ 11.739304] xradio_wlan: read config reg value: 0x4005600 [ 11.920160] xradio: hardware vers. 7.9 [ 11.920199] xradio: firmware vers. 8 (WSM), build 5258, api 1060, cap 0x0003 [ 11.920217] xradio: Config USE_EXTENSIONS on 5.18.1: [ 13.036884] xradio: XR819 device discovered [ 13.038054] xradio_wlan mmc1:0001:1: no mac address provided, using random [ 13.039290] xradio_wlan: read config reg value: 0x4 [ 13.064445] xradio ERR: FWIO: Unknown hardware: -1. [ 13.064547] xradio ERR: BH: bh thread exiting [ 13.064893] xradio PM-DEV: xradio_pm_release it seems xradio_reg_read_32 will call xradio_reg_read , and it calls __xradio_read ... last call sdio_memcpy_fromio , so maybe upstream have changed some implementation of sdio?

Well, I digged a little around this issue. It looks like a patch to the kernel driver of the xradio module is somewhat incomplete. So I patched the kernel and now the Wi-Fi works like a charm... well, not really (because of the XR819 module) but at least it gets the stored MAC address, as before. For anyone interested, here is attached the required patch; unfortunately a rebuild of the kernel is needed. 22-05.0-orangepizero-xradio_skupsy_20220520.patch

short log from 5.15.25 kernel: Apr 6 22:22:03 opizerompd kernel: [ 14.085917] [drm] Initialized lima 1.2.0 20200215 for 1c40000.gpu on minor 0 Apr 6 22:22:03 opizerompd kernel: [ 14.381026] cfg80211: Loading compiled-in X.509 certificates for regulatory database Apr 6 22:22:03 opizerompd kernel: [ 14.386092] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' Apr 6 22:22:03 opizerompd kernel: [ 14.443927] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 Apr 6 22:22:03 opizerompd kernel: [ 14.443968] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db Apr 6 22:22:03 opizerompd kernel: [ 14.445797] cfg80211: failed to load regulatory.db Apr 6 22:22:03 opizerompd kernel: [ 14.771399] xradio: XR819 device discovered Apr 6 22:22:03 opizerompd kernel: [ 14.772207] xradio_wlan mmc1:0001:1: no mac address provided, using random Apr 6 22:22:03 opizerompd kernel: [ 15.018782] xradio: hardware vers. 7.9 Apr 6 22:22:03 opizerompd kernel: [ 15.018816] xradio: firmware vers. 8 (WSM), build 5258, api 1060, cap 0x0003 Apr 6 22:22:03 opizerompd kernel: [ 15.018831] xradio: Config USE_EXTENSIONS Apr 6 22:22:03 opizerompd kernel: [ 15.024541] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Apr 6 22:22:03 opizerompd kernel: [ 15.615404] EXT4-fs (sda2): and shortlog from 5.10.60 kernel .. Apr 7 21:48:56 opizerompd kernel: [ 13.477921] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' Apr 7 21:48:56 opizerompd kernel: [ 13.490193] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 Apr 7 21:48:56 opizerompd kernel: [ 13.490224] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db Apr 7 21:48:56 opizerompd kernel: [ 13.495445] cfg80211: failed to load regulatory.db Apr 7 21:48:56 opizerompd kernel: [ 13.697443] xradio: XR819 device discovered Apr 7 21:48:56 opizerompd kernel: [ 13.945300] xradio: hardware vers. 7.9 Apr 7 21:48:56 opizerompd kernel: [ 13.945314] xradio: firmware vers. 8 (WSM), build 5258, api 1060, cap 0x0003 Apr 7 21:48:56 opizerompd kernel: [ 13.945319] xradio: Config USE_EXTENSIONS Apr 7 21:48:56 opizerompd kernel: [ 13.950696] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Apr 7 21:48:56 opizerompd kernel: [ 14.948195] EXT4-fs (sda2): mou and something about NM .. Apr 7 21:51:27 opizerompd systemd[1]: Started WPA supplicant. Apr 7 21:51:28 opizerompd NetworkManager[1002]: <info> [1649361088.5341] NetworkManager (version 1.14.6) is starting... (for the first time) Apr 7 21:51:28 opizerompd NetworkManager[1002]: <info> [1649361088.5348] Read config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) (etc: 10-override-wifi-random-mac-disable.conf, 20-override-wifi-powersave-disable.conf) Apr 7 21:51:28 opizerompd NetworkManager[1002]: <info> [1649361088.5522] wifi-nl80211: (wlan0): using nl80211 for WiFi device control Apr 7 21:51:28 opizerompd systemd[1]: Started Network Manager. Apr 7 21:51:28 opizerompd NetworkManager[1002]: <info> [1649361088.6020] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager" Apr 7 21:51:28 opizerompd NetworkManager[1002]: <info> [1649361088.6193] manager[0xb5b020]: monitoring kernel firmware directory '/lib/firmware'. Apr 7 21:51:28 opizerompd NetworkManager[1002]: <info> [1649361088.6199] monitoring ifupdown state file '/run/network/ifstate'. Apr 7 21:51:28 opizerompd systemd[1]: Starting Network Manager Wait Online... Apr 7 21:51:28 opizerompd dbus-daemon[984]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.4' (uid=0 pid=1002 comm="/usr/sbin/NetworkManager --no-daemon ") Apr 7 21:51:28 opizerompd systemd[1]: Reached target Network. where is stored mac address for xradio ..? it is generated ..?? dtb or module patch is needed ..??

@PiotrOI deleted the modules and that didn't change the issues on the 2 boxes. Unfortunatly connecting to the UART is a bit too complex for me ;-) But for your information the model P works great with @awawa release including the Wifi (both boxes use the same wifi chipset / XRadio XR819. I'm surprised the behaviour is different between the two, with Armbian they behave the same (and the hardware is more or less the same with the exception of the RAM size and eMMC size)

Hi @Erario The driver for XR819 is included but proper DT configuration for your board is needed for that device to be discovered by the Kernel. As you can compare orange pi zero DT xr819 configuration (vdd_wifi, mmc and pwrseq_wifi section) https://github.com/fifteenhex/xradio it's different from Tanix TX6: Wifi xr819 patch for Tanix TX6 And these sections also need to be tuned to your device, but I don't know their correct configuration.

After the non-working DTS patch for Tanix TX6 XRadio XR819 was recently finally removed from balbes150 git repo and there is no outlook to bring back support for working TX6's wifi, I decided to create an alternative CLI release for my TX6 server with a priority for XR819 & AC200 network cards. After many, many tries with the official Armbian repository I gave up on them: apparently they are missing some magic from balbes150's versions So I had to back in time in armbian-tv repo, merge some new stuff like latest kernel 5.10.*, remove some patches (including some custom cedrus patches, don't need them for CLI but they can be included back after the revision) that had conflicts with newer kernel, provide new patches and some improvement for kernel configuration, DTB wifi section and for XR819. None of XRadio XR819 drivers without the patch is compatible with current AArch64 crosscompiling and probably that's why it was removed even from the latest official Armbian AArch64 releases. Works stable with fast SD card access and CPU governor: I tried also 5.15 and 5.16 kernels using mainstream Armbian versions but there are some problems with slower SD access (initial partition resizing took x5 longer than usually) and/or with the CPU governor (CPU was staying at 1.7GHz all the time). I have not observed it using 5.10.99 Bullseye CLI build based on armbian-tv. Will try to provide fully working 5.15 if possible. I'm thinking also about CPU downclocking because that box is really hot on default settings. Feel free to improve it further. Sources are available of course. Tested configuration: current (5.10.99), Debian Bullseye, server. Enjoy! https://github.com/awawa-dev/build/releases/tag/v2022.02.10

The wifi on the TX6 equipped with the XRadio XR819 chipset is working fine with the (pretty old ;-) image Armbian_20.10_Arm-64_buster_current_5.9.0.img, but no longer with the recent image Armbian_21.11.0-trunk_Aw-h6-tv_bullseye_current_5.10.68.img. I tried to add the drivers to the new image but they are not taken into account (but I'm a newbie). I wonder if the problem is not simply in the dtb.

@balbes150thanks for your great work on the TV boxes and for sharing. I’m playing with different images you provided and TV boxes (for a project I’m working on). According to your advice I’m now testing your new images on the H6 TX6. It works well however with an old image the Wifi was working (XRadio XR819 chipset) but no longer with the new builds ? Do you know why ? And is there a way to overclock a bit those boxes (as a bit slower than the Amlogic based X96 Air or Max) ? I tried though the dtb but the change is ignored.

Hi Dolf, See this link on github, in particular the paragraphs "read this" and "issues". When i was using the internal wifi, pings to the OPi from network resulted in dropouts and lags, but from OPi to network were better. https://github.com/fifteenhex/xradio/blob/master/README.md So as a workaround I have a USB wifi N dongle from Ali Express (very cheap) https://www.aliexpress.com/item/1005002626370066.html?spm=a2g0o.productlist.0.0.5eda3ec9E8E9W2&algo_pvid=c6007224-e8da-49fd-a509-c30ed26bc42f&algo_exp_id=c6007224-e8da-49fd-a509-c30ed26bc42f-11 This is recognised by the kernel in current Armbian buster and works better. Although it doesnt answer your question, these dongles are very good and you can use an external antenna of greater gain if you wish.

Hi all, I have a few orange pi zero's and recently on 2 I had an issue with wifi AP that I am trying to properly understand. I have read some of the discussion regarding the wifi chip on the opi0 and that's not a great chip. I thoroughly agree with people that say that if you pay bottom dollar for a board, don't expect top dollar performance. And especially don't come complaining on a public FOSS forum. The only thing I am trying to do is understand the error and see if there is anything I can do to improve it. I use my orange pi zero's with a basic (custom) armbian image that starts up with a wifi AP briefly, so I can ssh in and do some config. Afterwards I reboot it and either turn wifi off altogether, or just connect as a wifi client using wpa_supplicant/ `/etc/network/interfaces.d`. So no heavy wifi AP usage. This has been working fine so far, but with 2 recent boards I couldn't connect to the wifi, and upon inspection of the logs, it showed these errors: [ 21.667120] random: crng init done [ 21.667157] random: 7 urandom warning(s) missed due to ratelimiting [ 21.692073] xradio AP-WRN: ap restarting! [ 21.731438] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 33.782692] vcc3v0: disabling [ 33.782721] vcc5v0: disabling [ 56.852083] xradio TXRX-WRN: received frame has no key status [ 56.852107] xradio TXRX-WRN: dropped received frame [ 56.852208] xradio TXRX-WRN: received frame has no key status [ 56.852218] xradio TXRX-WRN: dropped received frame [ 56.855392] xradio TXRX-WRN: received frame has no key status [ 56.855413] xradio TXRX-WRN: dropped received frame [ 56.861510] xradio TXRX-WRN: ***skb_queue_tail [ 56.973724] xradio TXRX-WRN: ***skb_queue_tail [ 57.028068] xradio TXRX-WRN: ***skb_queue_tail [ 57.040336] xradio TXRX-WRN: ***skb_queue_tail [ 57.042775] xradio TXRX-WRN: received frame has no key status [ 57.042789] xradio TXRX-WRN: dropped received frame [ 57.198022] xradio TXRX-WRN: ***skb_queue_tail [ 57.198644] xradio TXRX-WRN: received frame has no key status [ 57.198669] xradio TXRX-WRN: dropped received frame [ 57.198740] xradio TXRX-WRN: received frame has no key status [ 57.198752] xradio TXRX-WRN: dropped received frame [ 57.199236] xradio TXRX-WRN: received frame has no key status [ 57.199249] xradio TXRX-WRN: dropped received frame [ 57.199662] xradio TXRX-WRN: received frame has no key status [ 57.199672] xradio TXRX-WRN: dropped received frame [ 57.273269] xradio TXRX-WRN: ***skb_queue_tail [ 57.398636] xradio TXRX-WRN: ***skb_queue_tail Can anybody explain what these errors actually mean? Is this indicative of an actual hardware error on the board? Or could it be caused by something else? I did update my base image recently (using the same `customize_image.sh`), or could it be something locally on my wifi that can cause these errors? ---- EDIT ---- After diving into the driver source (well, at least one of the versions), I found this piece of code that seems to trigger the message: void xradio_rx_cb(struct xradio_vif *priv, struct wsm_rx *arg, struct sk_buff **skb_p) { . . . . . . . if (unlikely(early_data)) { spin_lock_bh(&priv->ps_state_lock); /* Double-check status with lock held */ if (entry->status == XRADIO_LINK_SOFT) { skb_queue_tail(&entry->rx_queue, skb); dev_warn(priv->hw_priv->pdev, "***skb_queue_tail\n"); } else ieee80211_rx_irqsafe(priv->hw, skb); spin_unlock_bh(&priv->ps_state_lock); } else { ieee80211_rx_irqsafe(priv->hw, skb); } *skb_p = NULL; I am not very familiar with the linux networking drivers/stack, but from what I understand, a wifi frame comes in over a socket, causing the rx callback to be called, which does a bunch of stuff, ending with checking some status (on the wifi chip? or on the frame?) concludes that the status is XRADIO_LINK_SOFT, which I guess means it isn't able to do something, and queues the frame back on the receive socket buffer/queue (and warns about it)? So does anyone know what that status means? And if there is anything that could cause it? Cheers, Dolf.

I assume you know how to estimate project costs in (embedded) software development? Then invest a day or as much as necessary, analyze all feature requests and count market prices since nobody will donate time. ("Just") make X board stable is easily this number or much more, adding X board can be 3-4 times this number if there is weird architecture and little to no community activity, developing / porting some driver can eat weeks of a devs team if not very complicated, depending of the current support, but you can find some projects which can be estimated easier. If you have this know-how. For a joke I have recorder how much we wasted just for dealing with one board wifi problem - infamous xradio r&d and never ending river of users questions on all possible channels ... I stop estimating time we waste at 20.000 EUR ... engineering hour in EU is 20-60 EUR, support hour a bit less or much more. Depending on situation and necessity. And no organisation can run solo on developers ...

Tested with the standard Armbian 20.11 Buster with Linux 5.8.16-sunxi [7789.126960] xradio WRN: BH: missed 9 consecutive interrupts! [ 7798.343147] xradio WRN: BH: missed 10 consecutive interrupts! [ 8168.424968] xradio WRN: BH: missed 11 consecutive interrupts! As already mentioned happens also on the old version [14108.446345] wlan0: XXX tries to chanswitch to same channel, ignore [14108.446708] wlan0: cannot understand ECSA IE operating class, 11, ignoring Happened only once with the new version in 6 days, never with the old version. I have however something similar on the OPiZ+ with roughly the same time stamp and hence doubt that the firmware is to blame. [ 5248.939102] xradio STA-WRN: [CQM] BSS lost, Beacon miss=20, event=24. [ 5249.043167] xradio STA-WRN: [CQM] Beacon loss. [ 5251.051198] xradio STA-ERR: [CQM] if0 Reporting connection loss. Only happened once with the new firmware, never with the old. Don’t know what to think of it. -> The firmware seems to be just as crappy as before. Is there a changelog available?

I have observed kernel panics using xradio driver before. Check Opizero wifi kernel hang I decided to test it with this driver. Summary: No improvements Ap mode No kernel panics were observed during 1 day when running only on AP mode. However, when Orange Pi is rebooted in AP mode, kernel panic was observed. After running 5 Orange Pi devices, after 60 average reboots, Kernel panic occurred for all devices. [ 25.238909] xradio WSM-ERR: CMD timeout!>>> 0x0006 (16), buf_use=1, bh_state=0 [ 25.247990] xradio WSM-ERR: bh error!>>> 0x0006 (12) [ 25.254591] xradio WSM-ERR: bh error!>>> 0x0006 (12) [ 25.261367] xradio WSM-ERR: bh error!>>> 0x0012 (16) [ 25.266375] xradio STA-ERR: wsm_set_tx_queue_params failed! [ 25.271979] xradio WSM-ERR: bh error!>>> 0x0012 (16) [ 25.276963] xradio STA-ERR: wsm_set_tx_queue_params failed! [ 25.282555] xradio WSM-ERR: bh error!>>> 0x0012 (16) [ 25.287536] xradio STA-ERR: wsm_set_tx_queue_params failed! [ 25.293128] xradio WSM-ERR: bh error!>>> 0x0012 (16) [ 25.298109] xradio STA-ERR: wsm_set_tx_queue_params failed! [ 42.299138] rcu: INFO: rcu_sched self-detected stall on CPU [ 42.304730] rcu: 1-....: (1 GPs behind) idle=21e/1/0x40000002 softirq=3544/3545 fqs=2623 [ 74.743671] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 1-... } 5569 jiffies s: 129 root: 0x2/. [ 74.754140] rcu: blocking rcu_node structures: Same error was observed in old firmware. Client mode No kernel panics were observed during 1 day when connected to an AP with a non-changing channel. Running in Client mode and changing AP’s channel result in similar kernel panic. But this occurred rarely. Running 5 Orange pi zero devices and changing channel continuously 72 times, lead to a Kernel panic only on 1 device. Running in Client mode, and rebooting also result in Kernel panic. It took an average of 200 reboots for the Kernel panic for 5 Orange Pi Zero Devices. Same error occurred on all situations. Hope this helps. This is how I tested.

I've checked on my second OPi0 where I didn't upgrade firmware, so still previous version, and the issue is also present : [ 14.824376] xradio: XR819 device discovered [ 15.056442] xradio: hardware vers. 7.9 [ 15.056457] xradio: firmware vers. 8 (WSM), build 43, api 1060, cap 0x0003 [ 15.056460] xradio: Config USE_EXTENSIONS [ 40.809788] xradio TXRX-WRN: received frame has no key status [ 40.809802] xradio TXRX-WRN: dropped received frame [ 3653.654011] xradio WRN: BH: missed 4 consecutive interrupts! [ 5423.670767] xradio WRN: BH: missed 5 consecutive interrupts! [ 7584.760350] xradio WRN: BH: missed 6 consecutive interrupts! [ 9724.478792] xradio WRN: BH: missed 7 consecutive interrupts! [10080.291066] xradio WRN: BH: missed 8 consecutive interrupts! [10777.751448] xradio WRN: BH: missed 9 consecutive interrupts! [13480.647858] xradio WRN: BH: missed 10 consecutive interrupts! [18367.827745] xradio WRN: BH: missed 11 consecutive interrupts! [19237.530227] xradio WRN: BH: missed 12 consecutive interrupts! [20461.024844] xradio WRN: BH: missed 13 consecutive interrupts!

After 24h running the new firmware on Armbian 21.02.0-trunk Buster with Linux 5.9.11-sunxi I got the following: [7789.126960] xradio WRN: BH: missed 9 consecutive interrupts! [ 7798.343147] xradio WRN: BH: missed 10 consecutive interrupts! [ 8168.424968] xradio WRN: BH: missed 11 consecutive interrupts! [ 8317.727378] xradio WRN: BH: missed 12 consecutive interrupts! [ 8458.633587] xradio WRN: BH: missed 13 consecutive interrupts! [ 8875.000177] xradio WRN: BH: missed 14 consecutive interrupts! [ 9703.025621] xradio WRN: BH: missed 15 consecutive interrupts! [11029.338694] xradio WRN: BH: missed 16 consecutive interrupts! [11698.845312] xradio WRN: BH: missed 17 consecutive interrupts! [11830.943440] xradio WRN: BH: missed 18 consecutive interrupts! [...] and: [14108.446345] wlan0: XXX tries to chanswitch to same channel, ignore [14108.446708] wlan0: cannot understand ECSA IE operating class, 11, ignoring Edit: and: [ 5248.939102] xradio STA-WRN: [CQM] BSS lost, Beacon miss=20, event=24. [ 5249.043167] xradio STA-WRN: [CQM] Beacon loss. [ 5251.051198] xradio STA-ERR: [CQM] if0 Reporting connection loss.

As far as I can tell nothing much changed - nothing negative and nothing positive (still 200ms ping). Did I actually install the new version or am I just an idiot? [ 10.021886] xradio: XR819 device discovered [ 10.181980] cfg80211: failed to load regulatory.db [ 10.257067] xradio: hardware vers. 7.9 [ 10.257082] xradio: firmware vers. 8 (WSM), build 5258, api 1060, cap 0x0003 [ 10.257086] xradio: Config USE_EXTENSIONS

If somebody has a chance to test new firmware blob for XR819 feedback would be appreciated Simply grab the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } fw_xr819.bin from the PR below, replace your current one and reboot. Check if Wi-Fi still works as expected or ideally even better. The file is located here: code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } /usr/lib/firmware/xr819/ https://github.com/armbian/firmware/commit/aff348fa9eef0fcc97d4f2bb7304f0862baffc20 If in doubt create a backup of your current firmware bin.

Perhaps we only need to blacklist xradio? Once and for good. I just tested Orangepi R1 ... and it works perfectly.