hmartin

First off, this happens on x86. Google "rowhammer" if you think that this kind of situation isn't a problem even for "expensive" computers.
 
 
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.

So please go visit https://lede-project.org/supported_devices and choose a supported device. If you really want to use crappy Wi-Fi (single antenna, 2.4 GHz band only) there are a lot of cheap AP to choose from. Please also note that you're using legacy kernel and literally no one ever will be that dumb to even touch this driver version.
 
Why the hell do people buy an SBC if they want an AP instead? Is it really saving the few bucks? Why are people that weird and believe in advertising and then add also (wrong) assumptions to that ("if there's Wi-Fi I expect it to be performant and stable, it has to be useable as access point and of course with monitor mode too")?
 
BTW: the thread you entered with support questions is a developer thread talking about tweaks for the mainline variant of the driver or similarities with a different and already present driver there. In the meantime I think it was a mistake starting to support those cheap H3 devices and it got even worse with H2+
 
What to do with the pollution of this thread (whining and support questions)?

First off, this happens on x86. Google "rowhammer" if you think that this kind of situation isn't a problem even for "expensive" computers.
 
 
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.

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.  

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.

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.
 
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). 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 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...
 
 
We are working to improve the driver, but please realize:
We have no datasheet from Allwinner on how it's supposed to work None of us are paid to do this 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. 

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.
 
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). 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 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...
 
 
We are working to improve the driver, but please realize:
We have no datasheet from Allwinner on how it's supposed to work None of us are paid to do this 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. 

You're welcome to submit a u-boot patch to support it faster.

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.

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.

Thanks for telling us what's in our best interest. And here I thought we were doing pretty well...
 
 
I'm not sure you understand how open source development works...
 
Sales: We're not selling anything, so we don't really need sales.
 
Product management: Since we're not selling anything, so we don't really need someone to stand on a soap box and tell us what to do.
 
Engineers: Design the hardware, write the software, write documentation for the hardware and software.
 
So if you want to help by writing documentation, or software, then we will welcome your contributions. But no one wants, needs, or asked for a product manager, so don't be surprised when we don't welcome this with open arms. I get enough of PM crap in my 9-5 job.

Thanks for telling us what's in our best interest. And here I thought we were doing pretty well...
 
 
I'm not sure you understand how open source development works...
 
Sales: We're not selling anything, so we don't really need sales.
 
Product management: Since we're not selling anything, so we don't really need someone to stand on a soap box and tell us what to do.
 
Engineers: Design the hardware, write the software, write documentation for the hardware and software.
 
So if you want to help by writing documentation, or software, then we will welcome your contributions. But no one wants, needs, or asked for a product manager, so don't be surprised when we don't welcome this with open arms. I get enough of PM crap in my 9-5 job.

This forum mostly solves random issues, with 50% being SD card related problems (SD cards are not the problem, but cheap/fake/malfunctioning SD cards are), 20% being power supply issues (powering a board from a PC USB port or with a crappy phone charger for some reason sounds like a good idea for an average user), another 20% being the problem with blind spots, which for some reason affect only documentation and search buttons/links, and what's left is actual problems or requests. If there is any time left after this, it can be spent on mainlining, assuming that after dealing with previous issues you still want and can do it.
 
Edit 22.01.2017 for people that are quoting me here, on cnx-software, etc.
I am talking specifically about issues - end user problems where images don't work at all or don't work as expected. Other forum posts - questions, HW discussions and even off-topic posts don't go into the mentioned percentage because they don't usually require specific attention from any developers - there "community support" can shine at its best - users that are more experienced in some topics can help other users. And SD card and wireless quality "issues" can't be solved in reality - people will still buy the cheapest stuff they can find and will believe in marketing provided specifications.

Ah, now I got your point. Since we (the community) are 'competing' with commercial entitites and we do our work for free it can't have any value or be as good as 'paid contribution'. Now I understand why you're thinking the stuff community does is worse compared to paid jobs (you're good in blindly adopting marketing BS even if you seem to have no clue about the nature of Open Source development)
 
 
Yes, and by letting your f*cking market trashtalking all the time this thread has now 10 pages with all real information got lost somewhere on the first pages. I would love to see the market shutting up now forever (at least here in Armbian forum!)
 
 
 
You called NAND eMMC which is plain wrong. Could you please stop flooding this forum with misleading assumptions and all this useless and stupid valuations?!
 
No one so far correctly benchmarked OPi Zero WiFi, we got only a lot of confusing feedback and still have no clue what the issues with this WiFi chip or the various drivers are. Doing such a benchmark correctly is not that easy and time consuming and as Zador already said it's stupid anyway to even try to benchmark this el cheapo WiFi crap (this applies to all these single antenna, non-MIMO, 2.4 GHz only crap chips on all the cheap SBC around)

Fuses are a good idea, but we're talking about 24V here. Enough to make a spark if you've got a big enough source (e.g. car battery) but in low currents it should be entirely safe to use.
 
650mA * 24V is 15.5W, which is the same limit as normal 802.3af. If they are not a one-time fuse, I would guess they're a polyfuse, meaning they are heat activated. The same kind of fuses are used to protect USB ports from over current.
 
However looking at the photos on Amazon, I can't see these fuses anywhere. If you buy this injector I would verify that there are actually fuses installed.
 
 
 
200mA * 24V is only 5W. In my opinion this is cutting it too close, you're very likely to have the fuse burned out at some point due to a current spike (e.g. if you have a power failure and all Orange Pi Zero's restart at the same time). I also think that 3W for 4 Orange Pi units with Ethernet and WiFi is too conservative.
 
I would recommend using a larger fuse. Something around 1A (24W) will provide both enough head room for all Orange Pi Zero units to run and yet still provide the protection you're seeking.
 
24W won't generate enough heat to cause a fire, even if there's a direct short.

Busy with xmas stuff right now, but once this craziness is behind me I'll package dgp's work as I tried to do with fifteenhex and submit a PR so we *can* have a working WiFi driver included.
 
 
 
I am slightly confused by your questions here, so sorry if I answer them wrong.
 
1. Unless the passive PoE splitter includes a 25kOhm resistor, the switch won't provide any power to the port:
"A PD indicates that it is standards-compliant by placing a 25 kΩ resistor between the powered pairs."
 
https://en.wikipedia.org/wiki/Power_over_Ethernet#Powering_devices
 
Also "PoE" switches all implement 802.3af/at, which operates at 48V. You need to step this down to 5V for the OPi unless you want a small fire.
 
So I think the answer to the question is: no, you cannot use a PoE switch as a PSE with a passive adapter on the OPi end.
 
2. For an 802.3af/at compliant switch, this would only be possible with step down from 48V to 5V at the OPi. As mentioned previously, these are pretty expensive and for the power envelope of the OPi0 may not be energy efficient.
 
Or you can use a normal Ethernet switch with a passive 24V injector, as tkaiser pointed out it's cheaper to drop 24V to 5V than 48V: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/page-7#entry21880

Okay, I have the XR819 driver compiling against https://github.com/megous/linux/(this is the kernel source Armbian appears to have switched to).
 

 
Should I submit a pull request to the above repo, or to the Armbian repo?
 
Not sure where the firmware for the radio comes from though, I just grabbed it out of the Armbian image.
 
Pull request submitted to megous/linux...

Okay, I have the XR819 driver compiling against https://github.com/megous/linux/(this is the kernel source Armbian appears to have switched to).
 

 
Should I submit a pull request to the above repo, or to the Armbian repo?
 
Not sure where the firmware for the radio comes from though, I just grabbed it out of the Armbian image.
 
Pull request submitted to megous/linux...