dgp

You really couldn't make this shit up could you.
 
As far as I know connecting to open aps and being an open ap with hostapd works.
 
The main issues with the driver is that performance is awful because of all the frames it drops and that it's not structured very well and can lock up the kernel if it gets into a bad state. These things are also true if you compile the code dump from allwinner on their hotchpotch prehistorical kernel.
 
FYI - A weekend of work on stuff like this will cost you more than $5000. The source for the kernel may be "free" but getting people to do work on stuff you want costs money and lots of it. You might want to think of all the free work people here have put into putting together something useful before writing any more of your bizarre posts.

Sigh. I thought I'd spend the weekend working on the xradio driver again to see if I could work out why it drops so many frames and then I see this in the google search results while trying to find some more info on the cw1200 (if there is a register to query the state of the buffers). I find it really crazy that someone can come along and make a stink about people choosing not to do work for free and while providing almost no information to help debug their issue make out that it's an easy fix.
 
I guess I'll read a book or something instead.

Sigh. I thought I'd spend the weekend working on the xradio driver again to see if I could work out why it drops so many frames and then I see this in the google search results while trying to find some more info on the cw1200 (if there is a register to query the state of the buffers). I find it really crazy that someone can come along and make a stink about people choosing not to do work for free and while providing almost no information to help debug their issue make out that it's an easy fix.
 
I guess I'll read a book or something instead.

Sigh. I thought I'd spend the weekend working on the xradio driver again to see if I could work out why it drops so many frames and then I see this in the google search results while trying to find some more info on the cw1200 (if there is a register to query the state of the buffers). I find it really crazy that someone can come along and make a stink about people choosing not to do work for free and while providing almost no information to help debug their issue make out that it's an easy fix.
 
I guess I'll read a book or something instead.

Sigh. I thought I'd spend the weekend working on the xradio driver again to see if I could work out why it drops so many frames and then I see this in the google search results while trying to find some more info on the cw1200 (if there is a register to query the state of the buffers). I find it really crazy that someone can come along and make a stink about people choosing not to do work for free and while providing almost no information to help debug their issue make out that it's an easy fix.
 
I guess I'll read a book or something instead.

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.

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.

For anyone expecting the wifi performance to be as good as their laptop or smart phone please adjust your expectations.
This is a chip for super cheap applications. It's basically a G device that supports enough of N to avoid hurting the performance of network it's on too much.
 
Even if the chip could handle high rates etc the SDIO bus it's on isn't amazingly fast either.

https://github.com/fifteenhex/u-boot/commit/56160c82d5f273bee8fdf1045eb415f9ae0c002c

To save confusion, talking about this https://github.com/fifteenhex/xradio/tree/original onthe mainline kernel.
 
I now have station + ap mode working.. so you can have the pi zero connected to wifi and acting as it's own ap. This is probably useful for a lot of potential applications for doing the initial wifi setup. Only downside is the station and ap side need to be on the same channel at the moment.

dgp and fifteenhex are one and the same aka me.

NAS hat is interesting. Might not be good enough for 4k media streaming but would be fine as an NFS server for doing backups etc.
 
If anyone has contact with them I would like a little board with an i2c controlled pmic that can charge batteries with the other switching and ldo supplies from the pmic broken out for use with sensors. Needs to be i2c controlled so the extra supplies can be turned on and off on demand.

Great news: linux-sunxi community got boot from SPI NOR flash to work: http://linux-sunxi.org/Orange_Pi_Zero#Mainline_U-Boot
 
Apritzel also managed to hack the function of the 'power button' to become a FEL button instead (so you're able to boot from SD card by pressing the button even if a 'firmware' is already stored in SPI flash -- useful only for OPi PC 2 now since Zero is missing the button).
 
What's missing still? SPI NOR flash soldered on the Zero by default as it's already the case with OPi PC 2. So please make some noise to convince Xunlong soldering the same 16 Mb (2 MB) flash on the Zero starting with next production batch. Please leave feedback in OrangePi forum and on Aliexpress!

Refactoring (Fix the structure and back filling the existing code until it works) the xr819 driver is taking some time so I have created a branch that incorporates some changes that make the driver work properly with a DT based system and added some usage instructions:
 
https://github.com/fifteenhex/xradio/tree/original
 
Aside from that a mainline based branch that has a DT for the pi zero and has working ethernet etc is available here:
https://github.com/fifteenhex/linux/tree/orangepizero
 
I will add a defconf for the pi zero sometime today.
 
Uboot with a defconf for the pi zero is here:
 
https://github.com/fifteenhex/u-boot/tree/orangepizero

Unless you need SPI (which is planned for 4.10 apparently) you should be able to do everything you want with the mainline kernel and the current xradio driver.
Once SPI is supported it should be possible to put a very small rootfs (buildroot generated or similar) on the SPI flash and have a system that that's a bit more reliable than a complete linux distro running on SD cards.

I haven't tested Icenowy's branch so I don't know if it works but it's basically the same thing. I just added code to get the interrupt pin from the device tree node and the "platform" code for the driver to toggle the power etc. The platform stuff shouldn't actually be needed. A regulator in the mmc node and a pwrseq node in the device sub node is the right solution and that does work but I thought that could be causing the firmware crash so I implemented that stuff. With the platform code you can unload the module and reload the module which is faster than rebooting to test.
 
I'm working on cleaning up the driver. For example they've been lazy in a few places and are using global variables to move state around instead of properly allocating the structures for that instance of the device. At the moment you couldn't have two chips connected for example. That doesn't matter for the pi zero but because they have global variables in the module instead of doing the setup of the device in the probe function called by the sdio subsystem in the kernel they are doing unneeded synchronisation between the sdio probe function and the module init function. They are also passing around a struct with function pointers to the sdio bus functions which would make sense if the chip had alternative interfaces but other parts of the code rely on the interface being sdio so it's totally useless.
 
And their debugfs code doesn't unregister correctly so once the module unloads if you access anything in debugfs it causes a kernel panic...
 
I don't have much time to work on this so it'll probably be a few weeks before I have something that is relatively clean and works.