Search the Community

So I was trying to set up a portable wifi hotspot on my Orange Pi Zero (running Armbian buster with Linux 5.4.34-sunxi). But whenever I try to enable wifi hotspot on it through armbian-config, it refuses to create a hotspot. When I looked closely, it tried to probe the nl80211 driver without any error but then it also tried to probe realtek's driver, which is rtl871xdrv according to hostapd.conf in /etc . During its probing, in the corner of the terminal, it said: ioctl[SIOCSIWMODE]: Invalid argument And as a result, it returned the No compatible driver found error. I even tried to make NetworkManager ignore it (wlan0) and stop NetworkManager before enabling the hotspot, and start hostapd manually but no positive results. I'm using the pi's built-in wifi chip - XR819, I'm aware that this wifi chipset isn't greatly supported but before all of this mess, it ran without any hassle. I only encountered this problem after doing an apt upgrade. And I also tried to downgrade hostapd to an earlier version - 2.7 - but still, nothing. What can I do to make hostapd working again? Any help would be appreciated! I also included a screenshot of hostapd when I manually start it.

Great job! Thanks to you I finally have a working image for my MXq-4k , PCB silkscreen : MXQ-S-V3.0-20180126 ZN Hw: Allwinner H3, 1G DDR3, 8G NAND, XR819 XR819 work All 4 USB enable from armbian-config cpufreq is working. Because i have NAND system transfer to eMMC does not work ...

I repharsed that sentence, I was talking about WiFi powersave polling, check my github comments for more details. In the current version, it is active but somewhat broken, and in idle uses about 200mW more than it needs to. On the other hand if you switch powersave mode fully off, the XR819 uses 300mW more in idle than the current driver. My patches enable setting powersave mode from userspace with iwconfig, and so power consumption can go up quite a bit if powersave is not ON by default. OPZ idle at 816MHz, WiFi driver not loaded: 610mW Connected to WiFi network & idle/no traffic: Current XR819 driver armbian/karabek: 910mW (slightly broken powersave) My patch: 700mW (powersave ON) My patch: 1220mW (powersave OFF, enables low latency incoming pings) Unfortunately, I believe kernel modules are not redistributable as compiled binaries, I think they only load if the kernel version matches perfectly.

Sounds indeed interesting There are many people here who will help you to test, but will lack of know how to get this into their Linux. If you have a step-by-step or a .deb or something to extract at the right place. People will walk with you that way. Do you mean if you 'switch off XR819" or if you power off the device? Because the latter is known, and is not related to XR819. Keyword AR100, you find plenty in the forum and if you have some improvements there as well

I know most of you probably don't want to hear any more about this chip, but I recently fixed quite a few long standing issues. It's not perfect yet, but it improves scanning/reliable reconnect, incoming frames missed in powersave, ping times, and rate selection. Here's the patch set: https://github.com/fifteenhex/xradio/pull/12 Edit: rebased from karabek: https://github.com/dbeinder/xradio/commits/karabek_rebase And some important comments about powersave: https://github.com/fifteenhex/xradio/pull/11#issuecomment-616226880 In short, relative to the current version, with powersave on, idle consumption is lower by 200mW, but with powersave off, it is 300mW higher - so that should be a consideration if you want to integrate this into Armbian builds for tiny boards like OPZero. Of course a 65MBit chip will never be fast, but I'd say it is pretty usable as an IoT node now. This hasn't seen much testing, so your comments are appreciated.

Hi, I have an Orange Pi Zero configured as a Wireless Access Point (via armbian-config) and it works great. However, I want to be able to scan for wireless networks whilst configured as an AP. If I try scan, I get the following error: wlan0 Interface doesn't support scanning : Operation not supported Just wondering if this is a shortcoming of the driver or the XR819?

I dont know what exactly happens and what this causes. As stated XR819 is known to be unstable or even considerable broken by design (like PCIe on H6 but at least it works somehow). I own the board by myself but the first thing I did was removing the wireless antenna as I did not need it Anyway. Sure you can script yourself some kind a watchdog that checks by pinging a host outside every second or so and when a disconnect happens do something like ifdown/ifup if that helps or do forcefully rmmod and modprobe the wireless module to recover it (if that works at all, no idea). You have to try around by yourself. Maybe you can come up with something nice.

I guess what Igor meant to say was that you should search for XR819 or xradio in forums to find topics with similar issues and if users solved their issues. Regardless of that I'd still recommened that you upgrade your kernel to sunxi-current (to say Linux 5.4.x) and check if the issue persists.

Sorry, I have not clearly understood your suggestion yet. You mean that I should search and install the XR819 or xradio driver for my board to check first, right?

There are many many users with this board - better use a search engine and throw in: XR819 or xradio and check results.

armbianmonitor -u missing. OPi zero WiFi is known to be unstable. Your kernel is outdated. Alternative experimental WiFi drivers for XR819 are included in newer builds.

While I am certainly sympathetic to the cause, i found a solution that works (an old Stretch image) and my elderly parents are able to use their 11 year old photo printer and 15 year old scanner over the network instead of by booting up an old Vista machine. So I'm not going to break it. It's on a reasonably secure network and i don't care if it ever sees a single package update as long as it keeps working. I'll read that thread and see if it makes sense to me to give it a try, just to see and report back, on a completely different sd card. The Zero uses a different wifi part than the Lite, doesn't it? I guess I can personally verify that it's not the xr819 next time i am over there. While i was arguing with the current Buster and Bionic issues, I could sit and watch the nmtui-connect screen and it would lose connection anywhere from a couple seconds to a few minutes. And sometimes it would reject the wpa-psk key which i presume was a similar sort of failure. it would also randomly connect to any of the 4 google wifi points regardless of the fact that one of them was 5 feet away from it. Which may just be normal bad behavior.

Backup your SDcard, and do testing with fresh install. Maybe worth giving it a try if it fixes it: https://forum.armbian.com/topic/12403-opi-zero-xr819-wifi-broken-in-new-builds/?do=findComment&comment=91259 If above doesn't help: Disable network manager (permanently) to avoid it restarting after a reboot: systemctl disable NetworkManager.service Configure your network "old school" /etc/network/interface and test again. Last but not least analyze your logs, here is the how to: Providing logs with armbianmonitor -u significantly raises chances that issue is getting addressed.

Troubleshooting, USB (cable) works Ethernet cable (your printer has one, right?) WiFi, but WiFi on OPiZero is tricky, see below. Once No. 2 works your network is not blocking it - get this sorted out. Do not start with WiFi until that works. If you are using the 'onboard' WiFi of your OPiZero, then try to disable that. Take an USB-WiFi-Stick (borrow one from a friend) test it with this first, because onboard WiFi-Driver is nowhere stable: https://forum.armbian.com/topic/12403-opi-zero-xr819-wifi-broken-in-new-builds/ Last but not least, please report back

Yeah. XR819-Wifi stopped working with stretch and buster, but still works with bionic. Here's my syslog with a buster build: ov 30 16:45:56 localhost NetworkManager[1116]: <info> [1575132356.6690] wifi-nl80211: (wlan0): using nl80211 for WiFi device control Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1449] device (wlan0): driver supports Access Point (AP) mode Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1555] manager: (wlan0): new 802.11 WiFi device (/org/freedesktop/NetworkManager/Devices/4) Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1656] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Nov 30 16:45:58 localhost kernel: [ 34.419112] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Nov 30 16:45:58 localhost kernel: [ 34.423469] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.1790] device (wlan0): set-hw-addr: set MAC address to AA:88:8F:8F:8F:AF (scanning) Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.2924] device (wlan0): supplicant interface state: init -> starting Nov 30 16:45:58 localhost wpa_supplicant[1115]: Could not set interface wlan0 flags (UP): Invalid argument Nov 30 16:45:58 localhost wpa_supplicant[1115]: nl80211: Could not set interface 'wlan0' UP Nov 30 16:45:58 localhost wpa_supplicant[1115]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0 Nov 30 16:45:58 localhost wpa_supplicant[1115]: Could not set interface wlan0 flags (UP): Invalid argument Nov 30 16:45:58 localhost wpa_supplicant[1115]: WEXT: Could not set interface 'wlan0' UP Nov 30 16:45:58 localhost wpa_supplicant[1115]: wlan0: Failed to initialize driver interface Nov 30 16:45:58 localhost NetworkManager[1116]: <error> [1575132358.3304] sup-iface[0x1175c18,wlan0]: error adding interface: wpa_supplicant couldn't grab this interface. Nov 30 16:45:58 localhost NetworkManager[1116]: <info> [1575132358.3309] device (wlan0): supplicant interface state: starting -> down Nov 30 17:21:39 localhost NetworkManager[1116]: <warn> [1575134499.3085] device (wlan0): re-acquiring supplicant interface (#1).

I've done some work on kernel drivers and uboot in the past, that would not be a problem. My point is that the XR819 worked on Armbian as good as the chip allows two months ago, and now the driver doesn't even initialize properly. The fact that it stopped working on the old 4.19 kernel branch too, makes me think this is probably not a problem with kernel patches but with the system image. I'm happy to help, but I'm looking for some pointers.

I did, and did not find anything relevant to this particular problem. Can you point me to it? I'm not complaining about the general unreliability of the XR819, I am well aware.

Is it possible that there have been some image changes that broke the XR819 wifi completely? The available images for download on the Armbian page (5.3 server, and 5.4 minimal) as well as a custom built "legacy" branch linux-4.19 image all show the same behavior, The wlan0 interface is not active and it's not possible to bring it up. And dmesg shows that module has been initialized but not much more. Armbianmonitor support info: 5.3.9 official buster server image: http://ix.io/240Y 4.19.88 self-built, two days ago, legacy branch: http://ix.io/240U Everything below is from the official image, but the 4.19 image shows the exact same It is definitely not a hardware issue, I have a SD card with a an older 4.19.72 image (when the branch was still called "next") that works just fine. ifconfig -a ifconfig root@orangepizero:~# ifconfig wlan0 up SIOCSIFFLAGS: Invalid argument root@orangepizero:~# rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no root@orangepizero:~# journalctl -b | grep xradio Nov 19 08:08:00 orangepizero kernel: xradio_wlan mmc1:0001:1: Input buffers: 30 x 1632 bytes Nov 19 08:08:00 orangepizero kernel: xradio_wlan mmc1:0001:1: Firmware Label:XR_C01.08.0043 Jun 6 2016 20:41:04 Nov 19 08:08:28 orangepizero NetworkManager[1057]: <info> [1574150908.3204] rfkill0: found WiFi radio killswitch (at /sys/devices/platform/soc/1c10000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy0/rfkill0) (driver xradio_wlan) root@orangepizero:~# uname -a Linux orangepizero 5.3.9-sunxi #19.11.3 SMP Mon Nov 18 18:49:43 CET 2019 armv7l GNU/Linux

- [x] HDMI -> no need ( ssh and http enough ) Those caught my interest: - [v] better voltage regulation -> that was my hunch but trying to verify how H2+ is nowadays ( kernel 5.3/ 5.4 ) - [v] full H3 instead of H2+ - [v] no broken by-design WiFi chip -> OPi One does not have WiFi imho Zero LTS hopefully has no longer that "heat" problem , LTS states: " low running temperature and low power consumption. ", but I dunno. Though I was not aware of crappy WiFi (xr819?), is mandatory though as I dont have cables in the meter cupboard, unless I'd use a HomePlug Except for that have older H5 ( first Neo2 series ), but without WiFi and H2+ was the missing piece I did not have stocked ;-), thus consider this more like a little "funny" project and might swap the board sooner or later, only stuff on there would be armbian ( buster ) with domoticz thanks!

Yeah, looks like one of them - at least it's not XR819

Opi Zero is the XR819 - which has some odd connection to the ST micro cw1200 chip - licensed maybe, or reverse engineered - anyways, a bit problematic https://linux-sunxi.org/Wifi#Allwinner

Might I ask - what is the AP/Gateway? Vendor/Model/Version (and if known, chipset) - based on review of code and the results, the driver is rejecting something at the 802.11 level, so it never makes it up to the IP stack. It's been mentioned that the XR819 is a bit challenging, as most have implemented the ST CW1200 driver, and folks have been working to sort that device out. I don't have a board with the XR918, but if I were to debug, I would have a AR9331/9531 based device on OpenWRT, which uses the ATH9K driver, and access down into the WLAN stack to see messaging there.

Thanks, this turned out to be much more involved than I expected. To save the next person some time, here's what it took: Activate the uart(s) and change stdout-path in the device tree, then add CONFIG_CONS_INDEX=3 (starts from 1) in configs/orangepi_zero_defconfig: diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index d166ffc0..abcc1874 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -56,13 +56,15 @@ aliases { serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ ethernet0 = &emac; ethernet1 = &xr819; }; chosen { - stdout-path = "serial0:115200n8"; + stdout-path = "serial2:115200n8"; }; leds { @@ -172,13 +174,13 @@ &uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>; - status = "disabled"; + status = "okay"; }; &uart2 { pinctrl-names = "default"; pinctrl-0 = <&uart2_pins>; - status = "disabled"; + status = "okay"; }; &usb_otg { diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig index ef0c6884..956f6a28 100644 --- a/configs/orangepi_zero_defconfig +++ b/configs/orangepi_zero_defconfig @@ -17,3 +17,4 @@ CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y +CONFIG_CONS_INDEX=3 \ No newline at end of file But CONFIG_CONS_INDEX is currently missing the pinmux code for uart1/uart2 in u-boot, so this also needs to be patched: diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h index 40a3f845..e6048983 100644 --- a/arch/arm/include/asm/arch-sunxi/gpio.h +++ b/arch/arm/include/asm/arch-sunxi/gpio.h @@ -148,6 +148,7 @@ enum sunxi_gpio_number { #define SUN6I_GPA_SDC2 5 #define SUN6I_GPA_SDC3 4 #define SUN8I_H3_GPA_UART0 2 +#define SUN8I_H3_GPA_UART2 2 #define SUN4I_GPB_PWM 2 #define SUN4I_GPB_TWI0 2 @@ -188,6 +189,7 @@ enum sunxi_gpio_number { #define SUN8I_GPG_SDC1 2 #define SUN6I_GPG_TWI3 2 #define SUN5I_GPG_UART1 4 +#define SUN8I_H3_GPG_UART1 2 #define SUN6I_GPH_PWM 2 #define SUN8I_GPH_PWM 2 diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index effbd032..e022bee4 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -133,10 +133,18 @@ static int gpio_init(void) sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1); sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1); sunxi_gpio_set_pull(SUNXI_GPG(4), SUNXI_GPIO_PULL_UP); -#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) +#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNXI_H3_H5) + sunxi_gpio_set_cfgpin(SUNXI_GPG(6), SUN8I_H3_GPG_UART1); + sunxi_gpio_set_cfgpin(SUNXI_GPG(7), SUN8I_H3_GPG_UART1); + sunxi_gpio_set_pull(SUNXI_GPG(7), SUNXI_GPIO_PULL_UP); +#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUNXI_H3_H5) sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_GPB_UART2); sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_GPB_UART2); sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP); +#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUNXI_H3_H5) + sunxi_gpio_set_cfgpin(SUNXI_GPA(0), SUN8I_H3_GPA_UART2); + sunxi_gpio_set_cfgpin(SUNXI_GPA(1), SUN8I_H3_GPA_UART2); + sunxi_gpio_set_pull(SUNXI_GPA(1), SUNXI_GPIO_PULL_UP); #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I) sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART); sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART); diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 47ea1243..46866c5d 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -255,7 +255,7 @@ extern int soft_i2c_gpio_scl; #else #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28000:115200" #endif -#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I) +#elif CONFIG_CONS_INDEX == 2 && (defined(CONFIG_MACH_SUN5I) || defined(CONFIG_MACH_SUN8I)) #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28400:115200" #elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28800:115200" This will make U-Boot output to uart1/uart2, but the Linux kernel has a low level debug output (e.g. to write "uncompressing kernel...") which writes to uart0 and simply freezes if it hasn't been initialized by U-Boot. So you'll need to compile a custom kernel with (Kernel Hacking -> Low Level debug functions) turned off. Then the linux console can be moved the normal way, using a boot param: e.g. console=ttyS2,115200

I'm trying to recompile U-Boot to move the serial console on my OP Zero from uart0 to uart2. I didn't have any trouble to move the linux console, but I'm struggling with U-Boot. I tried creating a patch to change stdout-path in the device tree: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts#L65 ff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index d166ffc..0e2e48d 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -55,7 +55,7 @@ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus"; aliases { - serial0 = &uart0; + serial0 = &uart2; /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ ethernet0 = &emac; ethernet1 = &xr819; @@ -178,7 +178,7 @@ &uart2 { pinctrl-names = "default"; pinctrl-0 = <&uart2_pins>; - status = "disabled"; + status = "okay"; }; &usb_otg { I doesn't seem to make a difference if change the alias or stdout-path directly - with the changed tree I get this output on uart0: U-Boot SPL 2019.04-armbian (Aug 16 2019 - 23:13:41 +0200) DRAM: 512 MiB Trying to boot from MMC1 And then it just freezes, with no output on uart2 at all. Does anyone have an idea where else I should look?

The sticker on the PCB also says H3, also the XR819 is the companion WiFi chip from Allwinner... That's definitely an Allwinner chip, most probably an H3 with a minor possibility it is an H2+ (which is almost the same as H3)