Search the Community

There are only two versions of this driver as you already discovered. One is stock, from Allwinner and the other is a result of a desperate attempt to make it work on a modern kernel. I don't recall any other wireless driver that would waste community that much time. Do some search on the forum to get a picture: xradio, xr819, zero wireless, ... Rather pick 8811AU (or better), plug it into USB and forget that Opi Zero has a wireless chip.

Personnally, I don't know which ones since I've never use such configuration. But you can leave the internal XR819 as AP while adding an USB WiFi dongle for the STA, you will then get both wlan0 and wlan1.

XR819 is the WiFi chip used on OPiZeroH2+. Most Armbian hate that chip since it provide poor performance, and driver is a bit crappy. STA means STATION and AP means AccessPoint. So, if you wish to have both at the same time, I doubt the driver and/or chip support both mode at the same time ... What you can do is attach a second WiFi thru USB.

Help me out with terms... XR819? STA? Thanks

I doubt any version of XR819 allows STA+AP at the same time ...

Board: Orange pi zero. wifi xr819 driver how to install and start it, step by step. please help

Just a small remark - wifi on Duo ( and on Opi Zero) is famous XR819 which is "half dead" by default

Just open a AP with your XR819 from the NanoPi duo.. That should be garbage enough... I never had wifi issues too.. try to get CSI to work from the couch and mostly to lazy to connect it to ETH. Maybe we should edit the docs? As far as I know, nmtui isn't standard on Ubuntu/Debian server (I think it is on Ubuntu desktop but I don't use linux desktops at all.. )

Both comparisons is what I call a 'goal oriented report'. @Fourdee picked topics where DietPi shines and you picked up topics where armbian shines... I avoid to decide who did it more objective, as a 'never used dietPi' guy my opinion wouldn't be objective. And I've a preference for 'not that much' customized systems cause it makes it easier to fix things with informations besides the official forum of a distribution. It's obvious that armbian outperforms dietPi on a kernel level, there's more knowledge here on a devs side and it's part of the project since the beginning whereas DietPi never touched it (correct me if I'm wrong). Both projects have different goals: DietPi is minimalistic and tries to be unique, they purge out everything from debian which they think is not important and fill it with their scripts for an easy to install things for a use case. As a result you get a minimalistic OS. To quote @zador.blood.stained: What we can learn (personal opinion): - 'customer informations' From the rumors I read, their approach seems to be more 'beginners friendly' - use the dietPi scripts to install *random feature* and it will work 'out of the box'. Their tutorials are similar to their OS - minimalistic. You want a 'DietPi - Kodi + BitTorrent Combo': Step1 --> Step2 --> Step3 etc. This is for sure more user friendly that our tutorials section in the forum whereas sometimes 2-3 pages of discussions are filled. I personally appreciate that we allow our users to discuss after a tutorial, a tutorial can be improved things that are wrong can be corrected or different opinions can be discussed but the starting topic of the tutorial should be updated with the new findings, maybe this needs some stronger moderation? DietPi.com is 'more informative' than ours or at least they tell their userbase better why you should use DietPi instead of a *random Distribution*. Whenever this informations are correct or not is out of my knowledge I don't have the time and endurance to check this statement by statement. It's also of no interest to me cause I don't use DietPi. But IMO they explain better what they are than we do. Before you insist that they don't explain well what they aren't - that wasn't part of my statement... I guess and hope that our new web design allows it to improve this slightly so that beginners read through tutorials beginners guides etc. before they start the same questions again and again. - 'public relations' (edit: you can also call it project presentation - but I like those buzz word bs bingo.. ) DietPi is more visible in reviews, reports etc. It might be easier to get attention when you do things different to other distributions as when you try to be a 'boring debian/ubuntu' with just better performance than the images provided by the boardmaker. Maybe we should make our efforts more visible. Most devs/researcher hate public relations as I do too but it's 'part of the deal'. When nobody recognizes what you do better than your competitor 'the world' doesn't recognize your work. Our release history is quite minimalistic which makes it fast to read but not very informative. E.g.: What is fixed in armbianmonitor -u? I know that I get all those informations when I look through the forum and through the GitHub history, but we must accept that the average user is to lazy to do it. It's not that every small change needs a 200 words comment what we fixed but a 'predictable place' where you find those announcements could be helpful. E.g.: When Bloggers, news sites etc. know where they can pick up those informations they might talk more about the project. In case we want to be more visible, we have to spend more time in summarizing our efforts, if this on minor interest the current approach is fine. When I read through @Igor website (the whole posts are not readable anymore and for sure a bit outdated), you spend more time explaining what you did than now. It's clear that the project growth a lot and your workload is for sure high enough that you don't have time to do all of this on your own. Maybe we can make a call if someone wants to fill this position? Is this more a reaction to @Fourdee decision to drop 'armbian based' dietPi images or is it driven by 'rational reasons'? On SD-card driven SBCs image size is IMO not relevant.. (ok, some 8gb large images from the boardsupplier are annoying but armbian isn't that big ) You don't find any new reliable SD-card below 16GB (and to my knowledge no device has less than 8GB eMMC which should also be enough for our images). 10% more or less aren't that important. IMO the SD-Card shouldn't be used as datastorage (but that's a personal opinion too). Wouldn't it make sense to explain our users how you can purge all the stuff they don't need with the buildscript - means that we explain how you manipulate this part of the buildscript with a clear reminder that we don't suggest it for the *average user* and that we don't provide support for it when you run into trouble after doing it. Packages should be removed by reasons, e.g. a driver which affects reliability of the system (talking about XR819 driver... ) or it forces the user to do stupid things (that's where you're the experts knowing it better). huh... It got a bit long...

Very good. The xradio-driver on boards with the xr819-chip seem to work as well with 4.14.17 noe - tested: sunvell r69 and nanopi duo.

Unfortunately, Orangepi Zero wireless (check our frustration with forum search) is half broken and there is nothing to do about. We lost hope that this crappy chip will ever be fully usable. Stay away from wireless chip labeled XR819. Use some external USB or any other board but beware none is capable of handling many clients.

Anyone is better than this. Stick to AMPAK/Broadcomm AP6212 Why not XR819? https://forum.armbian.com/search/?&q=xr819 It is performing very bad and even many people tried to fix this, not much success was made.

Hi. I encountered problem, glimpsed through topics and didn't found anything similar so I am posting this one now. Had set up OrangePi Zero 256MB version with Domoticz and everything looked great. I have 2 internet connections, one is PON FTTH and the other one is VDSL. So I have 2 routers with RJ45 and 2 WiFi networks at home. One for my personal usage (ftth, locked router by ISP, static IP but no port forwarding) and the other one is for all home users (dynamic IP but full access to router options). I hooked up OPI using cat5e cable to my router and this connection is working perfectly reliable. I had XR819 hooked up to VDSL router as auxiliary connection (and connection to ESP8266-based sensors) but it wasn't great and despite showing connection it was stopping to respond through WiFi after some time. So I upgraded armbian to: ARMBIAN 5.36 user-built Ubuntu 16.04.3 LTS 3.4.113-sun8i, disabled WLAN0, blacklisted XR819, and used TP-LINK TL-WN422G spare dongle instead. Networks connected, IP provided: 192.168.3.7 192.168.1.43 Seems ok. Both adapters up and reports ok but after some time (several hours) I can't access domoticz page through auxiliary network (and sensors lose connection with domoticz as well). So at this moment it doesn't appear to be hardware related as the same problem occurred on old kernel with XR819 on-board WiFi, and newer kernel with atheros chip. Anyone have idea why this happens and how can I retain both RJ45 and WiFi connection reliably? Restarted OPi so log at this moment dmesg doesn't show anything particularly useful. I'll fill in some info tomorrow if it fails again (which I suspect it will). connection lost at 7:47 AM, dmesg doesn't really show any useful information regarding it. Interface through system looks still connected with:

buying a reliable fast SD-Card (randomIO) --> boom same price. I don't know how fast (randomIO the other boards eMMC is, maybe you'll find something by using the search engine, probably in one of @tkaisers thread about this topic). you should decide on your needs... Do you need HDMI? Do you need Ethernet? Do you need wifi? There you go: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix But mainline support != armbian support (it depends how good the board is supported, are the dts files written for the board or are there patches to get proper support, in case you need wifi --> does this work properly - in case of the OPi0, XR819 seems to be still a nightmare). To my knowledge H2+/H3 is more or less the same (except GbE opportunity for H3 SoCs). H5 is 64bit, does your project benefit from 64bit? Does your project need 'maximum performance'? What does performance mean? To keep it short, without describing your project a bit more, nobody can help you.. Nobody can say if it will benefit from a 64bit SoC, nobody can say if you need 'maximum performance' etc...

Thanks for reply, 1. Yes I used micro-USB for powering. Mainly because of PCB footprint is smaller. But it can be changed to Barrel Jack for later version. Is it a problem because of max current rating of micro-USB? If it's about voltage drop, the buck AXP8036 support lower voltage than 5V, as it can run on battery with voltage as low as 3-3.2V 2. I just found this link ealier today. I am browsing the build files right now. I'll try to find what to modify. I think (not really sure) main problem is because clock is share with wifi XR819 as opi zero and ram is same 1GB with opi pc +. I should have thought better before mixing schematics... 3. SD card have been tested on other orange pi and works correctly.

Hi, Recently I upgraded /sudo apt-upgrade/ my armbian and my wlan is now gone /it worked perfectly before/. Looks like xradio module is missing from the new kernel? I am trying to download driver from http://linux-sunxi.org/Wifi, especially from http://kaiser-edv.de/tmp/lGtv38/patch-add-support-xr819.tar.gz .... but the site is not working.

Pulpstone OrangePiZero OpenWrt Chaos Calmer 15.05.1 ============================ Orange Pi Zero Hardware specification CPU H2 Quad-core Cortex-A7 H.265/HEVC 1080P. GPU Mali400MP2 GPU @600MHz Memory 512MB DDR3 TF card (Max. 64GB)/ NOR Flash(2MB Default not posted) 10/100M Ethernet WIFI XR819, IEEE 802.11 b/g/n [http://www.orangepi.org/orangepizero/] . . Pulpstone OrangePiZero Added : All Modem Packages Support 4G Modem Support HiLink Modem Support USB Tethering Android Support SFTP Server Pulpstone Mikodemos v5 (fix restart OpenVPN) Pulpstone MJPG Streamer (gigi webcam-uvc) Pulpstone Tramsmission Pulpstone miniDLNA LuCI-App-SQM LuCI-App-Access-Control LuCI-App-HD-Idle LuCI-Theme-DarkMatter 3G/4G Info by eko.one.pl Samba Network Shares (NTFS/EXT4) MPD (soundcard internal + fix volume button n sound) ping_loop v3 Mikodemos - Design by Andriawan Simple Network Interface Profile Fix Bridging Lan and Wireless Support USB WiFi (Atheros, Ralink) . . Basic Information : LAN = LAN LuCI '192.168.1' Username/Password 'root / root' SSID Wifi 'OrangePiZero' SSID Password 'internet' Default Modem Device '/dev/tty/USB0' Service Type 'UMTS Only' APN 'internet' 3G/4G Info '192.168.1.1:81' ping_loop GUI '192.168.1.1/cgi-bin/pingloop' Pulpstone Mikodemos v5 '192.168.1.1/pulpstone' Pulpstone MJPG Streamer '192.168.1.1:8291' ** Pulpstone Tramsmission '192.168.1.1:9091' ** **username/password = pulpstone/pulpstone . . How to flash OpenWrt to MicroSD card ------------------------------------------------------- On a Linux desktop and Windows desktop insert your MicroSD Extract file use Etcher software to write the img file to your MicroSD card's. [https://etcher.io/#downloads] . . Regrads, FuadSalim [ https://www.facebook.com/fuad.salim.drg ] . download : http://pulpstone.pw/

I have not applied any patch regarding ethernet except xr819 (which is still bad), so i got ethernet running by accident, possibly. What i know is working but have not done any becnhmark. DT has FBTFT setup to spidev0, but i think it would work only on spi1, right or wrong?

There will be no stable releases for H3/H5/A64 in the current stable release and there will be no stable releases for these boards with kernel 4.13 since it will be upgraded to 4.14 soon. OPi Zero may get a stable mainline release in a few months, but without support for onboard XR819 wireless.

Hello there, I need to use the XR819 driver because this is what the board I have use. How do I enable it? I am researching this subject for three weeks now. Device wlan0 does not exist. Please advise, Michael Here is my lsmod: Module Size Used by xradio_wlan 94208 0 mac80211 446464 1 xradio_wlan cfg80211 376832 2 mac80211,xradio_wlan rfkill 20480 2 cfg80211 sun8i_codec_analog 24576 0 snd_soc_core 118784 1 sun8i_codec_analog snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 69632 2 snd_pcm_dmaengine,snd_soc_core snd_timer 24576 1 snd_pcm snd 45056 3 snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd sun4i_gpadc_iio 16384 0 uio_pdrv_genirq 16384 0 uio 16384 1 uio_pdrv_genirq usb_f_acm 16384 1 u_serial 20480 3 usb_f_acm g_serial 16384 0 libcomposite 40960 2 g_serial,usb_f_acm pwrseq_simple 16384 1

At a first glance NanoPi Duo looks like a combination of Lichee Pi Zero (form, idea) and Orange Pi Zero (ingredients: H2+ and XR819 Wi-Fi). But once combined with the Mini Shield (RPi form factor -- connector and mounting hole positions), USB hub to provide 4 USB2 ports, Fast Ethernet exposed and a short mSATA slot behind a JMS567 USB-to-SATA bridge) it starts to get interesting. More information in FriendlyELEC's wiki/Github: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo http://wiki.friendlyarm.com/wiki/index.php/Mini_Shield_for_NanoPi_Duo Device tree file

It's not about last chance, I think you missed a key point there. Support for a new board is mostly a question of time and knowledge of an experienced developer taking care of a SBC. When you've a look which BPi boards are supported with a 'stable' armbian. You could see that there are a few of there boards: BPi M2+ (H3) BPi M2 (A31s) BPi Pro (A20, actually a lemaker, not SinoVoip product, correct me if I'm wrong here...) BPi + (I think this is called M1+ by SinoVoip, also a A20) BPi (should be the one called M1 by SinoVoip, A20) IMO, the reason why you see so much more OPi boards supported by Armbian is the following: They have a real conservative 'board design philosophy' - more or less every board from xunlong is based on H2+/H3 which as Thomas said, makes it easy to add support (as long as you've correct schematics, or as xunlong does it 'never change a winning team' - you know one, you know most OPIs ). SinoVoips approach to invent '20 different wheels for 15 use cases' (means having a bunch of different SoCs on their SBCs, and therefore many different board designs make it harder to support their boards). I bought a BPi Zero (and paid the full price ) and I'm sure that I'll have a dedicated armbian running on it (I think I'm able to adjust the basic things I need to get my needs running if nobody from the 'core developers' are willing to do it) but I'm not able and passionate enough to be a 'maintainer' like @TonyMac32 for the tinkerboard (actually a board which has also a lot of design flaws ). Means I'll not spend much time on things I'm not interested in and I don't feel responsible to answer every question about it on the armbian forum. Naming your images Raspian (something Xunlong and SinoVoip do) is IMO false advertising. First their boards are not RPIs. Second, Raspian is built on a (more or less) recent kernel (at least 4.x). Third, GPIO libraries are working out of the box (which is often not true for these boards) and last, things like mathematica, Node-Red & Wolfram Alpha works also out of the box (I never checked all these things on the OPis or BPis Raspians, but for the kernel it's sure - most OPis running the outdated 3.4.39 kernel BPi0 improved here slightly with a 3.4.113 kernel). Both companies don't shine on software support (but Xunglongs 'conservative design strategy' makes it easier to support their boards), so improvement there would be really appreciated. Annotation: this part of my post has some sort of humor, sarcasm & frustration in it, if you can't deal with it, just don't read it. A basic 'board bring up' for an H2+/H3 board (as repeated a way to often in this thread ) is not a huge deal. But maintaining the community support clearly is (just have a look here how many questions come up for *random SBC*). More or less every week a thread 'why wifi on OPi0 does not work?' (shitty XR819 just use search engine) or 'why armbian does not support RPi display on tinkerboard?' (armbian is not the board maker, this is a spare time 'job' we don't have time to do everything in minutes, btw. congrats to @tonymac32, you got it work! I think we're now close to ASUS advertised RPi compatibility with the tinker ). So, the more boards armbian supports, the more time experienced supporters of armbian are absorbed by answering this questions, testing images etc. (Thomas would say, 'waisting time' ). And what's also clear, the more a board is claimed to be raspberry compatible, the more 'inexperienced users' joining armbian (best example Tinkerboard). This might avoid someone like Thomas being excited adding support for such a board cause he knows the consequences - more 'inexperienced users' (sometimes too ignorant following basic instructions from an experienced armbian supporter - see here for some examples), expecting that everything on armbian should work similar than on raspian cause boardmaker claimed RPi compatibility and armbian is based on debian. So, 'no difference to *random RPi*' (except, it has to be cheaper than a RPi and I want 'real SATA' on my board). That's why I still like the RPi - more or less everything they advertise works on their boards. It's not the most powerful board (you get more powerful & cheaper SBCs on an H2+/H3 basis) but most things the *average SBC user* can imagine is solved by someone from the RPi world and they've targeted the 'noob problems' (it's a shame that they still use the micro USB connector for the RPi3 but nevertheless they have a 'protection mechanism' to avoid underpowering the board - one major issue on cheap H2+/H3 boards here at armbian). I hope you see the point in all this *random BS I talk here* Board bring up would be easy Support needs a lot of time more *average RPi users* means more ignorant users (not all of them, but part of them are) the more a bord is claimed to be 'RPi compatible' the more *average RPi users* will show up here - the more time is needed to explain to them that verdor claimed RPi compatibility doesn't mean that this is true nor armbians major goal is to be 'RPi compatible' Seems that they run out of their 'good eMMC' chips. (maybe I should sell my 'old' OPi Pc+ on ebay, advertising that it is a 'fast one' ). IMHO no! The only reason using NanoPi Duos 'motherboard' is during product development to get 'all features' easily accessible. If you still use it 'on production scale' of your project, just go for an *random H2+/H3 SBC* which deploys this features without a 'motherboard'. The main benefit of those SBCs is their size with a drawback that not everything is deployed on the board (this could also be a benefit if you don't want to have things deployed on the place the boardmaker deploys it, e.g. ETH is deployed 'on the false edge' for your project). But this is clearly a personal opinion.... @Lion Wang - take care of this sort of feedback. At the moment, your BPi zero is a 'quad-core rip off' of the RPi 0 for a higher price than the original which would make it hard for most SBC customers to buy it instead of the 'original'. The fact that the camera connector is not compatible to RPi makes it even worse for a lot of use cases (you'll find a generic RPi compatible camera for ~6$ on aliexpress but a BPi compatible camera is in the range of 20$). RPis videocore GPU works on recent kernels whereas Mali is 'work in progress' (but to my knowledge, nobody works really on it. ). So, your board needs some 'features' which makes it interesting for people which are annoyed by the RPi0. This could be (personal opinion). eMMC instead of/combined with SD card ETH on a pinheader (which you have) more than one USB port (maybe also on a pin-header) etc. I said it once and now the second time, don't bring this discussion to personal level between you and him which will end similar to the 'famous' BPi-R2 thread we had here and @Tido or myself will close it cause it's only about you don't understand why Thomas doesn't like your products and you're claiming that he must work for Xunlong. This thread is a little bit like a baseball game - a lot of boring, not BPi0 related, stuff (maybe also provided by myself ), and some new information we didn't know before (e.g. ETH is accessible through pin-header, 1.1/1.3V cpu regulation is on PL1 instead of PL6, first version of schematics). But as a real American @TonyMac32 can explain to you what happens in baseball after strike two... (hint: I'll close the thread maybe only for a 'cool down time' maybe forever cause I don't think we need a second 'BPi-R2 thread' again). If you felt upset by Thomas and you can't deal with it, ignore him. If you're smart you 'extract' the key concerns he has about your product/company and evaluate if it's worth to improve/adapt it.

Maybe not for your use cases but for others. Not everyone has the same needs... I see use cases where size and wifi matters... Since OPi0 has heat issues, and both other cheap small boards (opi0 and nanopi) have the annoying XR819 wifi. don't start this again... Thomas and you will fight on a personal level again, and @Tido will close the thread again... Doesn't make sense... If they have an interesting board, I'm sure people from the Armbian community will work on this board (maybe not Thomas but others.. ) And as @@lex said... Edit: Getting basic armbian support for this board should not be that much work. Starting with a similar board (1.1V/1.3 V regulation) add wifi and configuration of fex for the pinheader and you'll have a basic armbian image for this board. I appreciate this, so let's start with the 4pin connector from my last post. FYI: Short version of the post with the picture which is lost somewhere in the www nirvana during upload. I was too annoyed to write everything again...

That's Ethernet (so packets in this direction travel over the other interface -- which might have slightly improved your wifi numbers before, it's not that easy to correctly measure wifi performance when more than one interface is active and two or more interfaces are connected to the same subnet). Anyway we already know we can't expect wonders from XR819, it works somewhat ok-ish (see @t.munzer results) and anyone wanting to have decent Wi-Fi performance can always add an RTL8211AU 2x2 MIMO dongle anyway (well, that needs most probably mainline kernel support so someone has to hack together a .dts and submit upstream) Ok, then blue and visible led is connected to PA15 (and labeled wrongly red) and there's another rather invisible led connected to PL10 and wrongly labeled green. To make things worse I decided to now label the blue one green just to get almost consistent boot behaviour on all H2+/H3 boards (blue led labeled green will light up when kernel starts to load, at the time login is possible it will blink 3 times and then turn into solid mode again): https://github.com/armbian/build/commit/6981e324192dd6aad06e9ebd1a21a4c2f5c47d32 Will now create the Xenial image again (just check the timestamps at the download location). So now two contributions are IMO needed to consider switching from 'community supported' OS image to fully supported: Someone has to create a device page in linux-sunxi wiki Someone has to submit pull requests with u-boot config (576 MHz DRAM clock, 1008MHz CPU clock and MMC2 setting for eMMC) and a patch adding DT for the board (please keep in mind that 3.4 LTS kernel support ended already half a year ago)

Hmm... there should be no need to execute scripts any more if you did the modifications above. According to dmesg output it already worked at startup and still loading the xradio_wlan module twice seems to be necessary. What about a quick check with 'nmtui-connect' to see whether Wi-Fi really works? And maybe even a quick iperf3 test to confirm that data can be transmitted? That would finally confirm fex settings so anyone interested in supporting this device long-term could then start to hack a .dts for the board suitable for mainline kernel (fairly easy when starting with the DT for OPi Zero and then adding the necessary node for eMMC/mmc2 and different pin mappings for XR819. It would also be a great idea to create a device page in linux-sunxi wiki similar to the one for Beelink X2 at least documenting Wi-Fi settings and DVFS situation (no voltage regulation and 1.2V VDD_CPUX) Maybe caused by the sound drivers? Usually crashes at shutdown are related to driver hassles. You could try to remove all the snd_* entries from /etc/modules so that only the two xradio lines remain.