Orange Pi Zero wireless module status (XRADIO / ST CW1200)

[hmartin]

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?)

 

 

 

[   28.263492] cw1200_wlan_sdio: Probe called
[   28.357664] WLAN device is ready.
[   28.360985] CW1x60 silicon detected.
[   28.386731] Bootloader complete
[   28.389906] Can't handle CW1160/1260 firmware load yet.
[   28.395123] Fuck it, loading firmware anyway!
[   29.415376] Bootloader is not ready.
[   29.418990] Firmware load error.
[   29.422496] cw1200_wlan_sdio: probe of mmc1:0001:1 failed with error -110 

 

 

 

Unload the module and load it again:

 

 

 

[   78.093132] cw1200_wlan_sdio: Probe called
[   78.178590] WLAN device is ready.
[   78.181913] CW1x60 silicon detected.
[   78.205554] Bootloader complete
[   78.208727] Can't handle CW1160/1260 firmware load yet.
[   78.213944] Fuck it, loading firmware anyway!
[   78.219020] Bootloader reported ready after 0
[   78.227529] Bootloader reported error 8.
[   78.231491] Firmware load error.
[   78.234973] cw1200_wlan_sdio: probe of mmc1:0001:1 failed with error -5

 

 

 

Here's my diff to the mainline driver.

[zador.blood.stained]

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!

My Google-Fu suggests that there are at least 2 redistributable firmware files:

http://stuffed.shaftnet.org/cgit/compat-wireless-cw1200.git/diff/

 

Edit: I've found all sdd_xx.bin and wsm_xx.bin files, but still they are worthless without a working bootloader.

 

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 think source file license boilerplates are descriptive enough:

 * Based on:
 * ST-Ericsson UMAC CW1200 driver, which is
 * Copyright (c) 2010, ST-Ericsson

[hmartin]

Edit: I've found all sdd_xx.bin and wsm_xx.bin files, but still they are worthless without a working bootloader.

 

Yes, I was able to find wsm_22.bin as well, it's in linux-firmware. However if you look at fwio.h, there are way more firmware files for this driver:

#define BOOTLOADER_CW1X60       "boot_cw1x60.bin"
#define FIRMWARE_CW1X60		"wsm_cw1x60.bin"
#define FIRMWARE_CUT22		"wsm_22.bin"
#define FIRMWARE_CUT20		"wsm_20.bin"
#define FIRMWARE_CUT11		"wsm_11.bin"
#define FIRMWARE_CUT10		"wsm_10.bin"
#define SDD_FILE_CW1X60		"sdd_cw1x60.bin"
#define SDD_FILE_22		"sdd_22.bin"
#define SDD_FILE_20		"sdd_20.bin"
#define SDD_FILE_11		"sdd_11.bin"
#define SDD_FILE_10		"sdd_10.bin"

I guess these files were never released.

 

The wsm_##.bin and sdd_##.bin files seem to be for specific versions of the hardware. After changing the SDIO ID of the chip, the cw1200 driver is detecting the silicon as CW1X60_HW_REV and attempting to load boot_cw1x60.bin, sdd_cw1x60.bin, and wsm_cw1x60.bin.

 

If you do a hexdump on the boot_xr819.bin from Allwinner, it appears to be a loader for the rest of the firmware (wsm_*.bin files):

000008c0  72 65 64 0a 00 00 00 00  57 53 43 5f 4c 4f 41 44  |red.....WSC_LOAD|
000008d0  45 52 5f 46 57 5f 41 30  31 5f 30 30 5f 30 30 30  |ER_FW_A01_00_000|
000008e0  31 3a 41 75 67 20 31 39  20 32 30 31 35 2c 20 31  |1:Aug 19 2015, 1|
000008f0  38 3a 35 37 3a 35 31 3a  41 53 49 43 0a 00 00 00  |8:57:51:ASIC....|
00000900  28 20 70 7f                                       |( p.|

Edit: I've found all sdd_xx.bin and wsm_xx.bin files, but still they are worthless without a working bootloader.

 

We do have a working bootloader, it's boot_xr819.bin from the Allwinner SDK.

 

 

I think source file license boilerplates are descriptive enough:

 * Based on:
 * ST-Ericsson UMAC CW1200 driver, which is
 * Copyright (c) 2010, ST-Ericsson

 

Thanks, I'll just call up ST-Ericsson and ask them for their firmware reference manual 

[zador.blood.stained]

If you do a hexdump on the boot_xr819.bin from Allwinner, it appears to be a loader for the rest of the firmware (wsm_*.bin files):

000008c0  72 65 64 0a 00 00 00 00  57 53 43 5f 4c 4f 41 44  |red.....WSC_LOAD|
000008d0  45 52 5f 46 57 5f 41 30  31 5f 30 30 5f 30 30 30  |ER_FW_A01_00_000|
000008e0  31 3a 41 75 67 20 31 39  20 32 30 31 35 2c 20 31  |1:Aug 19 2015, 1|
000008f0  38 3a 35 37 3a 35 31 3a  41 53 49 43 0a 00 00 00  |8:57:51:ASIC....|
00000900  28 20 70 7f                                       |( p.|

➜  ~  % 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

I guess these files were never released.

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.

[hmartin]

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.

 

 

Nice find. These still appear to be for some other variants of the hardware, testing versions perhaps?

 

 

	switch (priv->hw_revision) {
	case CW1200_HW_REV_CUT10:
		fw_path = FIRMWARE_CUT10;
		if (!priv->sdd_path)
			priv->sdd_path = SDD_FILE_10;
		break;
	case CW1200_HW_REV_CUT11:
		fw_path = FIRMWARE_CUT11;
		if (!priv->sdd_path)
			priv->sdd_path = SDD_FILE_11;
		break;
	case CW1200_HW_REV_CUT20:
		fw_path = FIRMWARE_CUT20;
		if (!priv->sdd_path)
			priv->sdd_path = SDD_FILE_20;
		break;
	case CW1200_HW_REV_CUT22:
		fw_path = FIRMWARE_CUT22;
		if (!priv->sdd_path)
			priv->sdd_path = SDD_FILE_22;
		break;
	case CW1X60_HW_REV:
		fw_path = FIRMWARE_CW1X60;
		if (!priv->sdd_path)
			priv->sdd_path = SDD_FILE_CW1X60;
		break;
	default:
		pr_err("Invalid silicon revision %d.\n", priv->hw_revision);
		return -EINVAL;
	}

 

 

 

 

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'm comparing the cw1200 driver in mainline to the work from @dgp.

 

The cw1200_wlan_sdio init sequence sends the bootloader, but then the bootloader signals it's not in the right state to download the main firmware, and at this point the module stops trying to initialize the chip. For some reason the DOWNLOAD_STATUS_REG is returning DOWNLOAD_ERR_IMAGE instead of DOWNLOAD_PENDING.

 

...I just realized I could find the errors in hwio.h, so I guess I don't actually need a datasheet from ST to figure out what this error means.

 

I think I will add more debug statements to @dgp's xradio driver to see if I'm missing a setup step in the cw1200 init sequence.

[zador.blood.stained]

Also output of "strings fw_xr819.bin" looks rather interesting...  just some of the strings:

Invalid command: %s
CMD_LINE
The command line is supported. Type ? for help.
Invalid hexdecimal: %s
Invalid unsigned decimal: %s
Memory at %08X:
Sent Exception Indication to host!
Exception Reason - %s
Assert at File %s, Error %u
Unknown Exception Reason - %08x
    R0 = %08X    R1 = %08X    R2 = %08X    R3 = %08X
    R4 = %08X    R5 = %08X    R6 = %08X    R7 = %08X
    R8 = %08X    R9 = %08X    R10= %08X    R11= %08X
    R12= %08X    SP = %08X    LR = %08X    PC = %08X
   CPSR= %08X   SPSR= %08X
wake
fill
stop                     - halt the system
go                       - resume operation
wake                     - suspend sleep
stop
dumpplat                 - dump platform var
dumpplat
mem  [hex_addr] [size]   - read memory
fill hex_addr hex_data   - write memory

[hmartin]

I've confirmed that the _10, _11, _20, and _22 files are for earlier hardware revisions:

 

 

		if (ar1 == CW1200_CUT_22_ID_STR1 &&
		    ar2 == CW1200_CUT_22_ID_STR2 &&
		    ar3 == CW1200_CUT_22_ID_STR3) {
			pr_info("CW1x00 Cut 2.2 silicon detected.\n");
			priv->hw_revision = CW1200_HW_REV_CUT22;
		} else {
			pr_info("CW1x00 Cut 2.0 silicon detected.\n");
			priv->hw_revision = CW1200_HW_REV_CUT20;
		}

 

 

 

So presumably these are files for development silicon (CUT 1.0, 1.1, 2.0, 2.2). I would hope that Allwinner didn't buy an incomplete design from ST.

[hmartin]

I got the cw1200 module to load on the xr819. There were two issues:

1. Sending a NOP
2. 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:

 

 

Download

[ ID] Interval       Transfer     Bandwidth

[  4]  0.0-400.0 sec   512 MBytes  10.7 Mbits/sec

 

Upload

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-379.4 sec   512 MBytes  11.3 Mbits/sec

 

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.

[dgp]

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.

[hmartin]

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. 

 

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.

 

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?

[dgp]

Were the patches to cw1200 of any use for the XRADIO improvements?

 

It was mostly cleaning stuff up like I have been trying to do. For example it took out the ITP thing which is apparently some hardware testing framework that requires tools only ST has access to to make use of.

 

I'm not sure where the performance bottleneck with the current driver is. $iw dev wlan0 station dump; says it thinks the throughput should be ~13-20mbps and that's what I seem to get when scp'ing a file but it also does start out twice as fast before settling at that speed. So I wonder if we are actually failing to transmit frames at the higher rates and the rates are being adjusted down correctly or if what the driver is reporting to mac80211 isn't right and the rates are being lowered incorrectly.

 

That said it's doing what I need at the moment. It's been running as a station and ap for a week or so now and has't crashed the firmware like the original driver did .

[hmartin]

I'm not sure where the performance bottleneck with the current driver is. $iw dev wlan0 station dump; says it thinks the throughput should be ~13-20mbps and that's what I seem to get when scp'ing a file but it also does start out twice as fast before settling at that speed. So I wonder if we are actually failing to transmit frames at the higher rates and the rates are being adjusted down correctly or if what the driver is reporting to mac80211 isn't right and the rates are being lowered incorrectly.

 

I checked on my router while I was doing my performance testing. The PHY was running as high as MCS 7 (65MBit with 20MHz channel @ 1T1R), and averaged around MCS 5 (52MBit) between the Orange Pi Zero and the AP. These are readings from the AP, not the Orange Pi Zero, so I'm fairly sure they're accurately reflecting the true state of the xradio PHY.

 

Nothing was CPU-bound, yet I was still only getting 10MBit/sec with iperf. This was at less than 1m away from the AP, signal is at -14dBm and noise is -95dBm.

 

Then again I normally use 5GHz because 2.4GHz is such a shit show in my building with all the neighbours' APs.

[dgp]

Are you able to get data like the number of retries etc from the AP to the orangepi?

In iw wlan0 station dump on my hostapd based access point (totally different hardware) I can see a lot of TX retries for the orange pi client. A lot more than an of the other connected clients.

[hmartin]

Are you able to get data like the number of retries etc from the AP to the orangepi?

In iw wlan0 station dump on my hostapd based access point (totally different hardware) I can see a lot of TX retries for the orange pi client. A lot more than an of the other connected clients.

 

My AP is running OpenWrt, and I see lots of tx retries for the Orange Pi Zero:

Station dc:44:6d:c0:ff:ee (on wlan0)
	inactive time:	10 ms
	rx bytes:	392890748
	rx packets:	254433
	tx bytes:	10862247
	tx packets:	126252
	tx retries:	112285
	tx failed:	0
	signal:  	-17 [-20, -20] dBm
	signal avg:	-16 [-19, -19] dBm
	tx bitrate:	65.0 MBit/s MCS 7
	rx bitrate:	26.0 MBit/s MCS 3
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no

[dgp]

I suspect that's where most of the problem is. When I get time I'll setup my sniffing stuff and true to capture what is going on.

[carabennemsi]

Hey guys,

 

I have a lot of performance issues the wifi of the opi zero, too. With the armbian debian release I have experienced an average download speed of 1MBit/s. Get's a bitt better if I get closer to the AP. 

The nightly build of ubuntu performance slightly better for me, but still not very useful for any application using wifi.

 

Everything else works fine for me, so I would love to have a Orange Pi Zero with improved wifi drivers.

Would the very great if you could do this, because I'm not able to do this...

 

So thank you in advance!

 

PS: Is it possible to install your version of the drivers already? (52MBit/s in average seems quite good in comparison)

[hmartin]

so I would love to have a Orange Pi Zero with improved wifi drivers.

 

We would all like better WiFi drivers. Unfortunately, all we have right now is what we got from ST-E/Allwinner and it's not very good.

 

Is it possible to install your version of the drivers already? (52MBit/s in average seems quite good in comparison)

1. 52MBit/s is the PHY data rate, not the download speed. I'm getting at most 10MBit/s in testing (less than 1m from AP).
2. The driver in use is xradio and can be built against the kernel sources (e.g. 4.9) so you have WiFi. Get it here: https://github.com/fifteenhex/xradio
3. My modifications to the mainline cw1200 driver are enough to initialize the hardware, but the WiFi chip crashes when you try to scan or join a network.

 

Since the cw1200 module in the kernel is almost identical to the driver from the Allwinner SDK, this means even if it worked with the XR819 (which it doesn't) the performance would be just as bad.

 

Honestly not sure why a driver for pre-production silicon with crap performance ever made it into mainline, but whatever...

 

Would the very great if you could do this, because I'm not able to do this...

 

We are working to improve the driver, but please realize:

1. We have no datasheet from Allwinner on how it's supposed to work
2. None of us are paid to do this
3. We all have normal lives with jobs and shit that take up lots of time

 

So please be patient, and don't ask us when it will be finished. If you need a board with good WiFi, then that is not the Orange Pi Zero.

 

If you want to help, get Allwinner to release the datasheet so we don't have to guess how this thing works. 

[tkaiser]

We would all like better WiFi drivers.

Your all work on improving the driver is highly appreciated and we're looking forward to integrate a more advanced driver version once ready. But I think we should clearly state that wonders do not happen. This is ultra cheap crappy Wi-Fi regardless of driver quality. Expecting something like 50 Mbits/sec throughput at the application layer is a clear sign that the whole Wi-Fi technology is not understood.

 

Single antenna low power Wi-Fi in 2.4 GHz band is great to send some sensor data around but please don't expect 'throughput' with this 'as cheap as possible' type of wireless device.

 

Regarding PHY rate and 'throughput' reading through http://80211notes.blogspot.de/2014/03/phy-rate-and-udp-throughput.html for example might help (but please keep in mind that it's about perfect conditions and UDP -- in real-world conditions and when using TCP 'environment' and a lot of retransmissions add to a much lower bandwidth).

 

The best I got with el cheapo Wi-Fi (tested with OPi Lite, Banana Pro, Pine64 and NanoPi Air) here in my place was 20 Mbits/sec over a pretty short distance using a good AP configured to use highest power profile. At night! During the day and especially in the evening when loads of other devices around utilize the same radio channels bandwidth drops down to laughable numbers and latency increases like hell.

 

BTW: 20 Mbits/secs means not even 3 MB/s! Just to be sure... I'm always surprised about the huge amount of confusion around Wi-Fi: people thinking there would be something like 'guaranteed bandwidth', hiding SSID would improve security, same with MAC filter... all plain BS but a lot of people believe in

[carabennemsi]

@hmartin and @tkaiser

 

Thank you very much for your replies!

I really appreciate your work and your advice.

Made my understand the problem more clearly.

[Sdpetersen]

Thanks for your efforts on this! I'm hoping, like everyone else, for a better wifi driver.

 

I'd love to help, but my skillset doesn't run that deep, unfortunately.

 

I'm pretty ignorant to how this all works, but from what I read, the H2+ in the OPi Zero is about the same as the H3. If that's the case, would this datasheet for the H3 give you what you need?

 

http://wiki.friendlyarm.com/wiki/images/4/4b/Allwinner_H3_Datasheet_V1.2.pdf

 

I'm super motivated to get the OPi Zero wifi working a bit better, as it's the perfect hardware (exact features) I need for my project. If there's anything I can do (my knowledge goes as deep as setting up a Linux web server and setting HostAPD and other application settings), please let me know. I'm happy to test, research, search and tinker.

 

@carabennemsi, 

 

I have a lot of performance issues the wifi of the opi zero, too. With the armbian debian release I have experienced an average download speed of 1MBit/s. Get's a bitt better if I get closer to the AP. 

The nightly build of ubuntu performance slightly better for me, but still not very useful for any application using wifi.

 

I had that same problem at first (1Mbps speeds), but got my speeds up to 5-6Mbps @ 3 meters and 8-10Mps @ 1 meter through tinkering with settings and configurations... I didn't do the best job documenting what worked, but I think it was in my HostAPD settings, which you can find in this thread: https://forum.armbian.com/index.php/topic/3414-orange-pi-zero-wireless-ap/#entry24370

[tkaiser]

I'm hoping, like everyone else, for a better wifi driver.

Unfortunately you're hoping like a lot of OPi Zero customers for wonders. Even if the driver will be fixed once XR819 won't be great.

[hillz]

I take issue with companies that are developing and selling these hardware products and expecting the users to fend for themselves on the software side. At least provide some form of operating system, or a ready-made Linux distro ISO that actually works. I have no idea how long until the wifi driver will actually be fixed. Note, that mainly is aimed for the maker of this board, I take no issues with the people of armbian, they're good people

[Sdpetersen]

Unfortunately you're hoping like a lot of OPi Zero customers for wonders. Even if the driver will be fixed once XR819 won't be great.

 

Perhaps, but right now I'd settle for a small miracle of reliable connections, which I'm guessing isn't happening based on the large number of a fore mentioned tx retries.

[hmartin]

I take issue with companies that are developing and selling these hardware products and expecting the users to fend for themselves on the software side. At least provide some form of operating system, or a ready-made Linux distro ISO that actually works. I have no idea how long until the wifi driver will actually be fixed. Note, that mainly is aimed for the maker of this board, I take no issues with the people of armbian, they're good people

 

Then vote with your wallet and buy a Raspberry Pi or ODROID.

 

I'm sorry but people who spend the absolute minimum on a board and then expect it to have the same level of community and support as the Raspberry Pi are the problem, not the companies making them.

 

Adjust your expectations accordingly. You paid <$10 for this board. Don't expect a perfect product for that price.

 

 

Perhaps, but right now I'd settle for a small miracle of reliable connections, which I'm guessing isn't happening based on the large number of a fore mentioned tx retries.

 

I haven't noticed too many problems using TCP. If the packet is dropped, TCP will handle delivery. UDP and other protocols which don't handle retransmission are not recommended at the moment.

[hillz]

Then vote with your wallet and buy a Raspberry Pi or ODROID.

 

I'm sorry but people who spend the absolute minimum on a board and then expect it to have the same level of community and support as the Raspberry Pi are the problem, not the companies making them.

 

Adjust your expectations accordingly. You paid <$10 for this board. Don't expect a perfect product for that price.

 

 

 

I haven't noticed too many problems using TCP. If the packet is dropped, TCP will handle delivery. UDP and other protocols which don't handle retransmission are not recommended at the moment.

Or perhaps the company shouldn't sell half-baked products in the first place

[jkajolin]

The boards are fine they can run Android or Linux variants.

They just are hobbyist products not targeted for any commercial use cases (there is no real support from Raspberry either they just hide behind "non profit").
If you want real support you need to buy boards witch cost a lot more.

 

but getting a bit off topic...

 

 

Or perhaps the company shouldn't sell half-baked products in the first place

[Igor]

Or perhaps the company shouldn't sell half-baked products in the first place

 

All those companies sell half baked products simply because they can and must if they want to survive and we you buy their bullshit. Majority of people have zero clue and believe nice shaped marketing stories -> here is textbook example.

 

Board with good support and not with the cheapest components on Earth, let's say with something similar like we do, would need to have 5-10x higher price tag and it will become less attractive for masses ... no one is investing into scheme more than pure minimum. If you want to make profit, if you want to survive on the market, you need to fool people, that they are getting a board with full featured Ubuntu / Debian / Android + you name it ... for 9.99 USD or similar unrealistic price tag for such bundle.

 

Since we are crazy enough and provide top support for free and since community do exists, you get all this already for this price tag.

 

Wireless module, which we talk about here, is not high end router class wireless device. It's not even low end router class device. Its not router class device but just something that provide some wireless connectivity. Its low end of low end. I doubt there is any room for improvement left.

 

If you need higher speed, do the home work / research and than buy the board. Not everything can be boosted or fixed. For 9 USD, presale research is usually skipped or there are simply not enough reliable information around. You need to wait few months that developers community creates some deeper insight of the device, that you don't need to gamble and judge based on (fake/missing) promo docs.

 

[pacifica]

Hi everyone,

 

First of all I'd like to express my appreciation for the folks working on Armbian. I recently discovered the OPI0 and see many applications that could use an inexpensive yet full fledged embedded linux system.

I'm not too concerned about the wireless throughput of the OPI0 but I do need stability, which I have not been able to achieve so far. I'm using the OPI0 as an AP with it's wireless interface bridged to the LAN interface. DHCP,  DNS, gateway etc all provided for by another node on the network. A wireless device associates successfully, get's a bit of network access but as soon as I play a Youtube video it all starts failing. Here are some parts of dmesg and syslog although I guess most of you have already seen the message related to XRADIO (I've removed the bits that are likely not relevant).

 

Has anyone been able to get the wireless to work reliably?

 

[    6.601429] [XRADIO] Driver Label:L34M.01.08.0002  Nov 14 2016 08:41:12
[    6.601543] [XRADIO] Allocated hw_priv @ d5bf1240
[    6.602314] [sBUS] XRadio Device:sdio clk=50000000
[    6.602643] xradio wlan power on
[    6.754844] [XRADIO] Detect SDIO card 1
[    7.101435] [XRADIO_ERR] xradio_load_firmware: can't read config register, err=-110.
[    7.101473] [XRADIO_ERR] xradio_load_firmware failed(-110).
[    7.437706] xradio wlan power off
[    7.437753] gpio wl_reg_on set val 0, act val 0
[    7.487840] [XRADIO] Remove SDIO card 1
[    7.488148] mmc1: card 0001 removed
[    7.488590] [mmc]: sdc1 power_supply is null
[    7.500494] systemd[1]: Started Journal Service.
[    7.540998] [XRADIO_ERR] xradio_host_dbg_init failed=2599
[    7.541040] [XRADIO] Driver Label:L34M.01.08.0002  Nov 14 2016 08:41:12
[    7.541148] [XRADIO] Allocated hw_priv @ d5bf1240
[    7.541741] xradio wlan power on
[    7.541774] gpio wl_reg_on set val 1, act val 1
[    7.591834] gpio wl_reg_on set val 0, act val 0
[    7.593888] gpio wl_reg_on set val 1, act val 1
[    7.694070] [XRADIO] Detect SDIO card 1
[    7.695583] [mmc]: sdc1 power_supply is null
[    7.749447] mmc1: new high speed SDIO card at address 0001
[    7.750272] [sBUS] XRadio Device:sdio clk=50000000
[    7.751341] [XRADIO] XRADIO_HW_REV 1.0 detected.
[    7.947908] [XRADIO] Bootloader complete
[    8.185099] [XRADIO] Firmware completed.
[    8.187818] [WSM] Firmware Label:XR_C01.08.0043 Jun  6 2016 20:41:04
[    8.196411] [XRADIO] Firmware Startup Done.
[    8.198911] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[    8.313819] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x48)
[    8.315067] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x48, dev addr: 0x48)
[    8.318255] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x77)
[    8.318316] bmp085: probe of 0-0077 failed with error -70
[    8.966173] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
[    9.344995] Adding 131068k swap on /var/swap.  Priority:-1 extents:1 across:131068k SS
[   10.927838] systemd-journald[173]: Received request to flush runtime journal from PID 1
[   11.372011] Bridge firewalling registered
[   14.440409] PHY: gmac0-0:00 - Link is Up - 100/Full
[   14.441407] br0: port 1(eth0) entered forwarding state
[   77.913076] device wlan0 entered promiscuous mode
[   77.913240] br0: port 2(wlan0) entered forwarding state
[   78.040468] [AP_WRN] ap restarting!
[   78.092772] [AP_WRN] vif0, AP/GO mode THROTTLE=35
[   92.960132] br0: port 2(wlan0) entered forwarding state
 

root@opi55:/lib/firmware/xr819# tail -f /var/log/syslog
Feb  1 18:18:14 localhost systemd[1]: Started Session 3 of user root.
Feb  1 18:18:18 localhost kernel: [   92.960132] br0: port 2(wlan0) entered forwarding state
Feb  1 18:21:06 localhost kernel: [  261.050133] [AP_WRN] Multicast delivery timeout.

...snap...
Feb  1 18:21:39 localhost kernel: [  293.860293] [WSM_ERR] wsm_flush_tx:No pengding, but hw_bufs_used=1

...snap...

Feb  1 18:21:59 localhost kernel: [  314.740116] [AP_WRN] Multicast delivery timeout.
Feb  1 18:22:30 localhost kernel: [  345.220307] [bH_WRN] miss interrupt!
Feb  1 18:22:42 localhost kernel: [  357.570241] [AP_WRN] Multicast delivery timeout.
Feb  1 18:23:35 localhost kernel: [  409.991567] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208.
Feb  1 18:23:35 localhost kernel: [  410.350102] [AP_WRN] Multicast delivery timeout.
Feb  1 18:23:41 localhost kernel: [  415.997716] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208.
Feb  1 18:24:56 localhost kernel: [  491.690269] [bH_WRN] miss interrupt!
Feb  1 18:24:57 localhost kernel: [  491.850202] [AP_WRN] Multicast delivery timeout.
Feb  1 18:25:12 localhost kernel: [  507.073815] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208.
Feb  1 18:25:38 localhost kernel: [  533.210214] [AP_WRN] Multicast delivery timeout.
Feb  1 18:25:54 localhost kernel: [  549.137943] [WSM_ERR] wsm_flush_tx:No pengding, but hw_bufs_used=1
Feb  1 18:26:14 localhost kernel: [  569.650088] [AP_WRN] Multicast delivery timeout.
Feb  1 18:26:15 localhost kernel: [  570.162082] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208.
Feb  1 18:26:23 localhost kernel: [  578.290174] [AP_WRN] Multicast delivery timeout.
^C
root@opi55:/lib/firmware/xr819# ls -al
total 144
drwxr-xr-x  2 root root   4096 Nov 14 21:14 .
drwxr-xr-x 12 root root   4096 Nov 14 21:14 ..
-rw-r--r--  1 root root   2308 Nov 11 00:14 boot_xr819.bin
-rw-r--r--  1 root root    975 Nov 11 00:14 device-xradio.mk
-rw-r--r--  1 root root 126416 Nov 11 00:14 fw_xr819.bin
-rw-r--r--  1 root root    744 Nov 11 00:14 sdd_xr819.bin
root@opi55:/lib/firmware/xr819# uname -a
Linux opi55 3.4.113-sun8i #50 SMP PREEMPT Mon Nov 14 08:41:55 CET 2016 armv7l GNU/Linux
 

[ENDS]

[pacifica]

Hi everyone,

 

To all people saying that we can't expect much from a <$10 board.

 

It may be true that the board is cheap, however I think it's reasonable to expect that it works as advertised (which includes using it as an AP). I don't think anyone would accept flipping 0.000001% of the bits in memory, not even for a cheap board ;-)

 

Thanks to the Armbian folks, we have a great OS that we can use on this board. I'm working on a solar controller hopefully based on the OPI0. It has everything I need - except reliable wireless as it stands now.

[hmartin]

I don't think anyone would accept flipping 0.000001% of the bits in memory, not even for a cheap board ;-)

 

First off, this happens on x86. Google "rowhammer" if you think that this kind of situation isn't a problem even for "expensive" computers.

 

It may be true that the board is cheap, however I think it's reasonable to expect that it works as advertised (which includes using it as an AP).

 

Xunlong never advertised the Orange Pi Zero as an AP! Please, show me where they said "use the Orange Pi Zero as a WiFi router"

 

Even the cheapest WiFi routers that I know of cost $15 (AR9331/MT7620).

 

This is additional functionality that we've been lucky to get from the WiFi radio, and now people are getting all pissed that it doesn't work as well as a Raspberry Pi.

 

In my country, the Orange Pi Zero costs as much as a hamburger meal from McDonalds. Just try and use your hamburger as an AP...

 

Fack, people. Lower your expectations.