Search the Community

Sure. I just like the Zero's small size. If I'm understanding @tkaiser correctly, disabling a module in the fex switches off the component completely. That is, at no point in time the component is powered up. But how does this actually work on low level? Is XR819's power line an output of the SoC? So the fex strictly defines the state of the power line?

Does anyone know if the Zero's on board WiFi chip XR819 can be disabled? The RJ45 is disabled by default, so there must be a way to disable the XR819 - right? Any thought appreciated.

@jernej Thanks. I actually didn't compare CHIP to Armbian ! Those were my early remarks about CHIP: even though with inferior A13, pulling ahead with hires from Free Electrons. So that was criticizing Xunlong for not hiring/ supporting enough people, just using volunteer help from Armbian, and thus lagging in the market I have made those remarks consistently. On the other hand seeing Armbian spend 70-80% of its time on SD and power repairs, per Zador, is disappointing too. Why not use influence on Xunlong to have an OPi0 version with eMMC ( which will cost same or less than the class 10 sd cards recommended and level the field for all users) and also a DC jack? Much better recommendation than a USB3SATA shield only for OPi0 with USB2! Then of course the problem with the obscure xr819 wifi driver; Realtek chips should have been continued by Xunlong. Those are Armbian inputs Xunlong actually needs, as opposed to a new OPi0 version with GigE and USB3. Let's fix the current products first. Now I see where my confusion was ...Cedrus is open source, which I mixed up with CedarX, the Allwinner proprietary video codec. Because the OP used the term Allwinner Cedrus. I really hope there is a FAQ by Armbian one day.

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

I had the issue with it crashing when I was trying to take the XR819 driver and backfill it into a new driver. There certainly does seem to be some things that have to happen in a certain order or the firmware crashes. If you define DEBUG in the makefile for my version of the driver it'll output the messages going to and from the chip and print out the types etc which might help. On the CW1200 driver: Someone tried to submit patches to make it work better in the past. It seems almost none of those patches got applied so the mainline driver is still roughly a source dump from ST. From what I can tell it has the same issues as the XR819 driver (locking up the kernel if things start go wrong etc). Apparently no one uses it as no one replied to my mail on the linux-wireless mailing list about it and the only patches it's seen recently are low hanging fruit from static code analysis tools. I think the original versions of the cw1200 went to market and ST still apparently sells it as part of a STM32 wifi module. The XR819 seems to be the 1160 which wasn't released according to a comment from the guy that sent patches to improve the cw1200 driver. IMHO we should try to improve the XR819 driver for now. Get it down to as little code as possible. I think there are places that can be replaced with stuff that's already in the kernel like the queue for TX packets.

I got the cw1200 module to load on the xr819. There were two issues: Sending a NOP Setting DPLL to the wrong frequency, apparently this caused the bootloader not to respond (not sure why exactly, maybe DPLL effects SDIO speed?) [ 26.003305] cw1200_wlan_sdio: Probe called [ 26.007933] silicon_vers: 0 [ 26.010731] HIF_8601_SILICON [ 26.057552] Set DPLL to: 0x00000141. [ 26.107539] WLAN device is ready. [ 26.110851] CW1x60 silicon detected. [ 26.136517] Bootloader complete [ 26.139693] Detected CW1160/1260. [ 26.143210] CPU released from RESET [ 26.152946] Bootloader reported ready after 0 [ 26.226567] Firmware download completed. [ 26.240724] CW1200 WSM init done. [ 26.240724] Input buffers: 30 x 1632 bytes [ 26.240724] Hardware: 7.9 [ 26.240724] WSM firmware [XR_C01.08.0043 Jun 6 2016 20:41:04], ver: 8, build: 43, api: 1060, cap: 0x0003 [ 26.316284] Registered as 'phy0' Unfortunately if you try to actually do anything with the WiFi, the firmware crashes due to differences between the sdd file and the running configuration. I've tried both the Allwinner sdd_xr819.bin and sdd_sagrad_1091_1098.bin and neither seem to like what I'm doing. [ 184.358242] SDD file doesn't match configured refclk (24000 vs 38400) [ 184.442816] ieee80211 phy0: Firmware assert at syn_start.c, line 2001 [ 184.449258] ieee80211 phy0: R0: 0x00014080, R1: 0x000007D1, R2: 0x00002711, R3: 0x040088D8, [ 184.457621] ieee80211 phy0: R4: 0x040088D8, R5: 0x04003E88, R6: 0x04003E70, R7: 0x00000000, [ 184.465983] ieee80211 phy0: R8: 0x4C68E107, R9: 0x37A37ED1, R10: 0x42209403, R11: 0x040814CA, [ 184.474519] ieee80211 phy0: R12: 0x0000A7C3, SP: 0x0400B668, LR: 0x00013F9D, PC: 0x00013F99, [ 184.482960] ieee80211 phy0: CPSR: 0x0000001F, SPSR: 0x000000DF [ 184.488790] R1: 73 79 6e 5f 73 74 61 72 74 2e 63 00 70 3e 00 04 syn_start.c.p>.. [ 184.488794] R1: 50 36 00 04 88 8a 00 04 c0 93 00 04 01 80 00 00 P6.............. [ 184.488798] R1: 40 0d 03 00 34 8e 00 04 68 4a 00 00 10 27 00 00 @...4...hJ...'.. [ 184.488855] [BH] Fatal error, exiting. Gist has been updated. I guess the next question is whether the cw1200 driver in mainline is any good or not. In my performance tests I'm getting around 10Mbit/s down/up (unidirectional testing only) using iperf on the XR819 driver: It doesn't seem that the cw1200 module works with any final revision silicon, as evidenced by this from the module source: pr_err("Can't handle CW1160/1260 firmware load yet.\n"); Edit: You can do insmod cw1200_core.ko cw1200_refclk=24000 to override the default refclk, which will get rid of the SDD error above. Unfortunately the firmware still crashes if you try to do anything.

➜ ~ % strings armbian/lib/bin/firmware-overlay/xr819/boot_xr819.bin xV4 ERROR: ImageSize (%x) not 32bit word aligned ERROR: GET pointer (%x) not zero initialized ERROR: NumBytesToRead (%x) not 32bit word aligned ERROR: NumBytesToRead (%x) too large ERROR: PUT (%x) pointer not 32bit word aligned ERROR: PUT pointer (%x) too large ERROR: Invalid Section type %x ERROR: Invalid image checksum (%x) Downloaded %x bytes OK WSC_FW Label: Got %x bytes. Seen ARE_YOU_HERE. Restart downloading ERROR: PUT pointer (%x) modified after image_size bytes transferred WSC_LOADER_FW_A01_00_0001:Aug 19 2015, 18:57:51:ASIC Well, you can still find them: https://github.com/Evanok/snowball_builder/tree/master/firmware/cw1200 --- So in the end the chip accepts the bootloader but doesn't accept the firmware? And BTW mainline driver from @dgp doesn't suffer from bootloader issues - it's loaded correctly from the first try if I understand it correctly.

I have the electrical datasheet which is useless. The chip and firmware is/is based on an ST/Ericsson design. The cw1200 driver in the mainline kernel source is basically the same as the xr819 driver and that driver (the in-kernel one) came from a code dump from ST/Ericsso so there probably isn't anyone that still has the technical documentation for the firmware (because ST/Ericsson no longer exists) and all winner have probably done a bunch of undocumented hacks in the firmware anyhow.

Hi everyone, I was doing speed tests on the XR819 and started looking at the driver code. My this looks very similar to the cw1200 driver already in mainline Linux. I started modifying the cw1200 driver to try and get it to work with the XR819. Apart from someone renaming functions and adding a bunch of important junk for XR819, the drivers are quite similar. I've modified the cw1200 driver up to the point that it's loading the boot_cw1x60.bin ( boot_xr819.bin ) file, but for some reason the bootloader is returning an error instead of success. I don't think it's possible to diagnose this without the datasheet from ST. Clearly this exists, because people were able to write the cw1200 driver for mainline. Does anyone have a clue where I might find the datasheet for the CW1100? I also haven't been able to find the firmware files from ST for this chip. They don't exist in the linux-firmware tree! Here's my progress thus far: Try to load cw1200_wlan_sdio first time. Timeout waiting for bootloader to respond (I think XR819 has the same bug, no?) Unload the module and load it again: Here's my diff to the mainline driver.

Lots of flaming here and I only discovered the thread just now by accident...No email alerts, but that's OK. 1. Martin, I think your contributions were simply lost. I never said useless, just not useful NOW + with future potential. Also you keep saying a Tut is needed, and another guy says it is already available?? Btw, what additional functionality do we gain now with the 2MB NOR + your code, for my own lessening of confusion...except with external USB/ netboots? 2. Spock, calm down. I plan on making a contribution myself. I called the guy thick when he kept ignoring my point about a lot of good work here. I believe some you guys should read better. Listening is a big problem. And if I forced you to make a contribution, that is a good step too. But then, why could you not make this contribution already, in a calmer state of mind? Something to do with your engineering management? 3. The eMMC + NAND thing was best explained by zador, who said to call it onboard memory. Which is exactly what users care- onboard vs other (SD card, for instance.) Most talk about eMMC being NAND/not is loose in the industry with qualifiers, and thus see zador from earlier. But for someone to say that eMMC cannot ever be (managed) NAND is plain ridiculous. Let's focus on what this all means to the end user ! Hopefully this won't be labeled by the insecure as marketing bullshit 4. For some strange reason, my wish list for v2 OPi0 got viewed as an attack on someone else's "Wiki" on the yet unreleased Zero Plus/2, supposedly the next Zero version; and which clearly has nothing to do with the Zero today. And guess who says that now? Now that is marketing bullshit !!! 5. Again, as the great sunxi himself said: Embrace your (fr)enemy (CHIP), not oppose. Let's acknowledge they did a great job and Armbian OS+ OPi can do even better. This has been my bet all along. 6. zador mentioned 50% of Forum discussion is about (bad) SD card problems, maybe 20-30% about power. What a waste of talent and time ...Ever thought about it, seriously? That tells me eMMC is not a bad idea and regardless of how crappy that guy calls it, the same guy has written tomes on how bad a lot of SD cards are ! OPi and other SBC vendors must have a good reason to use eMMC on their "Plus" models. So let's stop calling it crap. Just as for xr819 which the same guy says now is really no better/worse than AP6212 or RTL8189, except that the XR driver has problems ( hopefully to be fixed by Martin in a month?) Cheap SBCs will have cheap parts, but they can be optimized as we all know. So there should be less effort on SD card and power posts, and more on ??? If you really want to argue, don't do it selectively. You are the majority here, and it is your Forum after all. But be OPEN. PS. I see you folks are fascinated, writing all these posts. I got your attention.

Hmm...So eMMC cannot be called NAND? https://www.datalight.com/solutions/technologies/emmc/comparing-emmc-to-other-flash-media Just like technically speaking XR819 is OKish, but well, it is also just confusing and crap, like all other cheap SBC wifi chips. But then, hey, why can't they put expensive WIFi on cheap SBCs???

hmartin, I am doing what my skill set allows me to do- I am neither a HW or SW guy, but have been and am a product manager. And I do see some product questions need to be asked here. Btw, that monthly report is in the best time/effort interests of contributors themselves- less questions, more work. Tkaiser says that xr819 work OK ish, a very technical reply, so how do you dare say the driver sucks ? You don't have to do everything I ask. When does that ever happen? If you have an answer, great; if not, you can pay attention elsewhere. Volunteering is just about that. You can always find a paid gig and maybe do better- exactly the case I see with Free Electron guys bring hired by CHIP, and CHIP zooming. I detect the NIH syndrome here re: CHIP. But I thought Armbian also targeted CHIP.

I'm an engineer by education and profession and somehow I manage to give useful answers to your questions. You're right, how silly that I forgot the questions are the most important part of anything. Who here wants to fix the XR819 WiFi driver so it doesn't suck? Who wants to get it into mainline? Whew, glad I asked these important questions so other people know what to do now. Yes, you are suggesting that we do extra work for you. You "suggest" that we write a monthly update, but won't spend your own time to do it. You might find we're a bit more open to helping you if you contributed more than just questions.

zador, Thanks for pointing out many things. 1. By lack of transparency with XR819 I meant some speed/ features which actually were recently posted on this thread. 2. I didn't call eMMC NAND. But there are many other very tech folks saying so online. Like calling many functions collectively as GPU. Yes lots of confusion- no right or wrong here. 3. Exactly what I said about SPI flash now included. I am not criticizing anyone - it might be useful in the future. 4.Why is this CHIP with seemingly better WiFi / BT marketing hype? Can you disprove it , or isn't this just one of those subjective assessments as above??? In sum, Armbian/ sunxi does a lot of good work for FREE. And thus competing with paid contribution is hard! Now isn't this a fact? May I suggest that Armbian forum post a monthly update with relevant links and a short summary so everyone is on the same page, as opposed to milling around different threads and getting confused? If you read my posts in all, I am trying to help. I truly believe in OPi/0 more than CHIPs, Pine, RPi/0. There is a reason why the world chose Steve Jobs over Steve Wozniak ( not to say I am Jobs)- it's called the Market, and it acts in its own way and it wants out-of-box operation. Or you get to be IWoz.

tkaiser, I am asking quite significant questions given many of your own comments about XR819...Clearly many other quite tech folks don't necessarily agree with you either. What I do see is this amazing lack of transparency with xr819 Armbian support ! You want to scream about accuracy re: some benchmarks, but what kind of benchmark is "ok-ish"? When did I talk about different RTL models except say I would like to see 8189 vs xr819 comp, given someone said 8189 is the wifi chip for other than Zero OPi models. I call 4GB as eMMC because tons of other folks say so. What counter argument do you have which majority folks will agree with you on? I still don't get your morbid fascination with 2MB SPI NOR which still does nothing very useful in practise. But I still want to ask questions, not reach quick judgement. My marketing bullshit or your tech hype? What BS have I offered so far except ask very legitimate tech questions that really few people seem to address...Can you give me any examples of my marketing BS??? Am I promoting any vendor product except OPi itself? If you have a legitimate gripe against my OPi0 v2 wish list, say so. Don't pretend it's bullshit. Re:" all that is known about Zero Plus 2..." Well maybe Xunlong knows a bit more, including some guy named Steven? " All" here arguably is a bullshit construct here on your part. I keep saying OPi + Armbian OS has the best price/performance so that is what excites me. Now, do you have specifics on WiFi speeds on Zero and other models ? Do you know if any supports WiFi Direct or Miracast as host? Or should I assume your bullshit OK-ish is a logical, tech focused answer, as opposed to your plain BS? Let's be honest...Despite many good volunteer efforts including your own, we don't have a "mainline" Armbian OS yet for Allwinner. But nothing wrong with that. And yes it is true that CHIP has pulled ahead in the market given its paid tech savvy and market PR. Problem as I said is that OPis are exploiting volunteers to their own long term detriment. Now can you show this claim to be marketing bullshit too? I call it common sense. I remember your recent remark about making the distro updates more consumer friendly. You should think same about answering other serious questions. PS. My and hmartin's PoE discussions did result in updating the OPi0 linux-sunxi sunxi page. So useful things can happen with a cool head or two.

Steven sounds to me a pretty smart cookie. In our emails from last week he talked about a "new version" (OPi0 version?) coming out in about a month, so we'll see. He said he didn't have info on the leaked NAS board. But...it's really frustrating to see smart China vendors thinking they can produce good but cheap HW and make volunteers do all the software work; and on top experiment with just inexcusable things like XR819 for widely adopted RTL8189 that is already working on their own well selling models. I look at CHIP, using Allwinner chip, which hired Free Electrons to do the mainlining ( apparently done since June), even though the HW is old. But CHIP also had the sense to add good WiFi/ BT and recognize that SD cards are a pain, so voila ! 4GB eMMC. Yes CHIP has other issues compared with OPi0 ( no Eth port/ PoE, single core A13, no cheap expansion board with extra ports, etc), but they will sell, keep upgrading features and build the market hype. Still cheap enough. Pretty much like the non production RPi0. I still hope they go back to RTL8189: they already have those tested designs, or maybe put in quietly on a v2 $2.50-3 expansion board for now. Who imagined WiFi would become a bottleneck for no good reason? Don't see other problems with OPi0 for the $7/9 price, only upgrade opportunities like v2 proposed. Otherwise by the time patches arrive, OPi0 will have been forgotten as a niche/ failed product with much potential.

hi, I am looking for XR819 datasheet. does anyone help me?

IMHO, XR819 is killing the OPi0 golden goose...All else looks so perfect for the price ! Can't they just go back to RTL8189 in the next couple production batches? Will that make life easier? Ironic to hear that XR819 has its own ARM core- what good is the core? What is the prospect of Xunlong offering a eMMC 4-8GB version of OPi0? SD cards are expensive and unreliable, plus can add an SD card drive for more memory. And adding a power barrel to the $2 expansion board that is otherwise just what is needed, maybe make it $2.50? My take: OPi0 v2 512MB, say $12-15, with RTL8189, 4-8 GB eMMC + $2.50 expansion board adding power barrel + Armbian OS = market winner. Other GbE, NAS stuff can be taken care of on higher models. H3 has USB- SATA bottleneck.

Hi Jernej, I've uploaded a u-boot into the SPI Flash, and working well with USB-Boot. Network is another issue, problably because u-boot is unware of xr819, and neither the plain H3 eth0 (I was getting DHCP not responding, if I remember), I didn't investigate further. SPI-Flash Tutorial ? Well, there are a lot of manual steps, first making sure you have a SPI floash solder properly (my early PiZero didn't have any), then loading my spidev overlay to get /dev/spidev, then get latest flashrom sources, edit the source to make sure it doesn't do any SPI transaction longer than 64 bits, compile it. Create flash.img of the size of the SPI Flash, then "dd" again on the same image to write /usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin into it with "conv=notrunc" and write the resulting image into flash using modified flashrom. Nothing automated yet ... Maybe scripts can be written here, maybe even avoid using flashrom and use pure Python script which will handle the DT overlay also ... Lot of jobs in the pipeline.

It is a bit disappointing that Xunlong chose to use an obscure and cheapo XR819 wifi chip to save maybe a dollar so OPi0 could look like a more featured $9 CHIP. But CHIP has way better marketing: https://techcrunch.com/2017/01/06/next-thing-chip-pro/ 1. Can someone elaborate a bit on OPi0 WiFi available vs missing features, e.g. speed in Mbps over what range, AP, bridge etc modes? 2. How does above compare with WiFi on other OPis? Do other models all have same WiFi chip, not XR819? 3. Any comments on comparison with CHIP WiFi capabilities?

I've done it for LamoboR1 (A20), only Orange, supported by OpenWrt is Orange Pi Plus (with comment that is not bootable at the moment). I can try to build custom sunxi image with some stuff included, but i am not sure if wifi module in OpiZero (XR819) is supported by OpenWRT. I don't remember if there where any AllWinner wifi drivers and firmware. But googling around i come through this - ОбÑуждение Orange Pi Zero. Looks like some 4pda guy claim to have OpenWrt image with working wifi - http://4pda.ru/forum/index.php?s=&showtopic=782242&view=findpost&p=55805628. But image uploaded can't be downloaded. Maybe registration is needed, but i always forgot my login and conformation emails from this site takes forever to come.

@scargill Looks like you are missing the firmware... If a directory /lib/firmware/xr819 doesn't exist, then please create it and put files from here inside it.

As per request - the log is here... http://sprunge.us/VWZB This line stood out from the crowd... xradio_wlan mmc1:0001:1: Direct firmware load for xr819/sdd_xr819.bin failed with error -2 As did these later on [ 12.031511] xradio_wlan mmc1:0001:1: Direct firmware load for xr819/sdd_xr819.bin failed with error -2 [ 12.031532] xradio_wlan mmc1:0001:1: Falling back to user helper Standing out is one thing of course - I've no idea what to do about it.

I am using fresh installation of armbian legacy server version 3.4.113 on the Orange Pi Zero Rev v1.1. The FEX file seems to be incorrect. Some driver or process is blocking PA10, which is wired directly to the expansion header pin 26. According to the schematics, this port is not used anywhere else. # cat /sys/kernel/debug/gpio GPIOs 0-383, platform/sunxi-pinctrl, sunxi-pinctrl: gpio-10 (? ) out hi gpio-17 (red_led ) out lo gpio-202 (xradio_irq ) in lo gpio-354 (? ) out hi gpio-362 (green_led ) out hi In case i am the first one that tested this: gpio-10 aka PA10 aka ? is blocked gpio-17 aka PA17 aka red_led is correct, echo 1 > /sys/class/leds/red_led/brightness is working gpio-202 aka PG10 aka xradio_irq is wired to WL-WAKE-AP, which is corrected to WL-WAKE-HOST of the XR819, seems legit gpio-354 aka PL2 aka ? is wired to USB0-DRVVBUS, which is not mentioned again in the schematics, may be legit, not sure, tell me how to test.. gpio-362 aka PL10 aka green_led is correct, echo 1 > /sys/class/leds/green_led/brightness is working I am new to armbian, please bare with me if the following questions are stupid. How do i fix this issue correctly? Where can i find and modify the FEX file that is used? How can i disable the occupation of the red/green leds, so i can export the GPIO myself? Thanks a lot

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