seandepagnier Posted September 18, 2017 Posted September 18, 2017 I have two orange pi zero H2+ boards. Using kernel 3.4 they get very hot, and wlan0 also is not very stable. I upgraded to version 4.11 kernel using Armbian_5.32_Orangepizero_Ubuntu_xenial_dev_4.11.7.img. I was able to have a much cooler orangepi, and also wlan0 appears in iwconfig. I ran "apt update" and "apt upgrade" When I boot the upgraded kernel wlan0 does not appear. I reimaged the sdcard again using the above image, but now wlan0 still is no longer there. I switched to my other orange pi, and wlan0 works. I won't upgrade the kernel and run it on this orange pi. I now have one orange pi with wifi, and one without. It won't even work with the 3.4 kernel. Somehow upgrading the 4.11.7 kernel and booting that kernel permanently broke the wlan0 in one of my orange pi, is there any way to get it back again?
chwe Posted September 19, 2017 Posted September 19, 2017 3 hours ago, seandepagnier said: I upgraded to version 4.11 kernel using Armbian_5.32_Orangepizero_Ubuntu_xenial_dev_4.11.7.img. When you started with a freshly burned SD-Card running mainline something like this should appear within your first login. If you did it via armbian-config, something like this appears: or this (if you moved to nightly): And if you had a brief look on armbian download page you would see something like this: and this: I can't repeat your experiment, booted a 4.11.7 image (wifi was visible, cause not deactivated on this image), followed by booting a 3.4.113 image and wifi worked, without any issues (no long-term test!!).. So it might be hard to figure out why wifi on your board is broken now. If you look around here, you'll see that wifi on this board is somehow questionable (just an example, you'll find multiple threads about this issue). A personal opinion: Using a older nightly with 4.11.7 just cause wifi wasn't deactivated by default isn't really smart (you got maybe wifi, but cause you've to freeze kernel and board upgrades, you'll miss all the improvements on board support). It seems that the wifi driver for XR819 is in such a bad shape that nobody wants (or is able) to work on it. If I would need wifi on one of my opi0, I'd go for a usb wifi stick. If I would need wifi permanently, I'd go for another board with better wifi support. 1
seandepagnier Posted September 19, 2017 Author Posted September 19, 2017 to repeat my experiment, after booting the 4.11.7 with wifi, issue: apt update apt upgrade This installs a very slightly newer kernel When you reboot then wifi is permanently broken on that orange pi zero Any clue what the cause is? Is the firmware in the wifi corrupted? How can I tell? As for the onboard wifi, why is no one willing or able to work on the driver? I don't need good throughput on wifi, so speed is not important. I think it works fine so long as it always has traffic. Otherwise it seems to timeout and not work for a while, maybe the power management is the issue?
TonyMac32 Posted September 19, 2017 Posted September 19, 2017 If only any wifi were so simple... 7 minutes ago, seandepagnier said: As for the onboard wifi, why is no one willing or able to work on the driver? https://github.com/fifteenhex/xradio is an example of someone working on this. The readme excerpt below came from there: Also: The xr819 chip/firmware drops tons and tons of frames with FCS errors and this makes performance horrible at best. Most people have lost interest in having anything to do with the xr819 because of people being idiots and demanding that issues that are incredibly hard to fix without documentation be fixed because they spent $8 on a board and somehow people that got exactly zero of their $8 are responsible. Moral of the story: If you're going to post nasty things on the interwebs and demand people fix stuff because reasons at least have a bunch of packet dumps etc and have some idea about what you're talking about. 1
chwe Posted September 19, 2017 Posted September 19, 2017 8 minutes ago, seandepagnier said: apt update apt upgrade This installs a very slightly newer kernel after upgrade, wifi will be disabled cause not supported in mainline anymore. That's what happens on experimental, things are tried and if they doesn't work smoothly, they are improved or in this case disabled. 14 minutes ago, seandepagnier said: As for the onboard wifi, why is no one willing or able to work on the driver? I don't need good throughput on wifi, so speed is not important. I think it works fine so long as it always has traffic. Otherwise it seems to timeout and not work for a while, maybe the power management is the issue? Since friendlyelect has for whatever reasons now also have a board with the xr819 wifi soldered on it you might be lucky and they improve the driver (or not, I've no clue if they have it on their todo list). When we talk about 3.4.113 kernel armbian.. Power Management lead to confusion. Whereas Bubba has better results with power management off, my opi0 lived longer with power management on.. (but in my case, it ended every time in a crash... ) IMO, go for a usb wifi stick or another board. I know that this sounds annoying, when you buyed it just freshly... I like my zeros, but I use them just for lightweight IoT server applications connected via cable to my router.
seandepagnier Posted September 19, 2017 Author Posted September 19, 2017 I realize the wifi is disabled in mainline kernel... What I don't understand is why when I booted the latest kernel, and then boot the older kernel wifi still doesn't work again. Which board would you suggest for better wifi? I had similar problems with nanopi neo air, plus other problems. Which wifi dongle is good? I have edi max but it's expensive. The cheaper ones don't work as an access point.
Igor Posted September 19, 2017 Posted September 19, 2017 1 hour ago, seandepagnier said: Which board would you suggest for better wifi? I had similar problems with nanopi neo air, plus other problems. Which wifi dongle is good? I have edi max but it's expensive. The cheaper ones don't work as an access point. Just about any board has better wireless chip than Orange Pi Zero but don't expect router class experiences on any other since you won't find them. Get something with RT5572, RT3572, RT3070, AR9271, ... first two will go up to 300mbps at 5Ghz, while last two up to 150mbps at 2.4. Access point mode of course. With something like this: http://www.ebay.de/itm/ALFA-Networks-AWUS052NH-2-4-5-GHz-USB-WLAN-Adapter-300-MBit-Ralink-RT3572- you could have (very good) router class experience. Long range and presumably a lot more clients than on those on board el cheapo wifi chips. Quote The cheaper ones don't work as an access point. I think all Armbian supported boards that have wifi chip can operate in access point mode. The question is a quality/speed/distance and max. client count. All this is fairly limited. 1
seandepagnier Posted September 19, 2017 Author Posted September 19, 2017 I do not care about speed or range. 1mbit is already 10x what I need and 10 meter range is fine. The driver is simply unreliable. It often hangs for 30 seconds or more with no traffic possible. This is a problem. There is no problem with edimax wifi on usb. I had the same problem on the nanopi neo. I think it's the same wifi. What alternative boards have builtin wifi? I use also the raspberry zero W and it works well, but it cost a lot more because of shipping and limit 1 per order. Are there any usb dongles that support AP mode? The edimax one is very expensive, it cost the same as the OP zero.
chwe Posted September 19, 2017 Posted September 19, 2017 21 minutes ago, seandepagnier said: expensive, it cost the same as the OP zero So, 8-12$ (depends if you calculate the price for an orange pi with or without shipping) is expensive? I do some testings with the opi pc+ in AP mode, but to be honest I like the 'connecting sbc to access point wired, and connect nodes normally to this ap' approach more. It's less load on my SBC and capabilities of my AP are better (throughput, which is of no interest in your case but ping seems also to be better). Just have a look with the google search engine here if you find something that fulfills your needs. It's a bit out of my knowledge cause my sbcs are mostly wired. https://www.armbian.com/search_gcse/ 1
Igor Posted September 20, 2017 Posted September 20, 2017 7 hours ago, seandepagnier said: The driver is simply unreliable. It often hangs for 30 seconds or more with no traffic possible. This is a problem. It's not our decision to put this chip on board, we don't sell boards, we only try to make them usable. We already wasted an enormous amount of our extremely scarce time on this piece of crap and got nowhere. We decided to drop support - you can find the reason on this forum if you do some search. Forget about that there is a WiFi chip on board. As I already told you - just about any other chip works O.K. also in AP mode. RPi has very similar Wifi chip which you can find in Opi Zero 2+, Neo Air, Banana PRO, ... it works just fine, more than 1mbit at a distance of 10m. 7 hours ago, seandepagnier said: but it cost a lot more Time from people who are willing to help you might cost way more. 1
tkaiser Posted September 20, 2017 Posted September 20, 2017 On 19.9.2017 at 1:06 AM, seandepagnier said: I now have one orange pi with wifi, and one without. It won't even work with the 3.4 kernel. I have one Orange Pi Zero which had Wi-Fi working in the beginning and after some days Wi-Fi stopped working. I'm always surprised that hardware that cheap as an Orange Pi Zero works in the first place. I remember the last thing I did before realizing that I had broken Wi-Fi on my Zero was taking a nap (you remember the last thing you did was trying out another kernel). But I don't think me taking a nap is related to hardware becoming broken. 1
A_bruce Posted October 3, 2017 Posted October 3, 2017 (edited) There is now a working xradio/xr819 driver for the 4.11.12 and 4.11.5 kernels at https://github.com/karabek/xradio So when does this work back into the armbian "release management"? Edited October 3, 2017 by A_bruce added a link
Igor Posted October 3, 2017 Posted October 3, 2017 1 hour ago, A_bruce said: So when does this work back into the armbian "release management"? It's still barely usable.https://github.com/armbian/build/commit/dbdf2a0f15aa8a9640460e2e8f4a688028160158 Switch to "NEXT" kernel, 4.13.x
A_bruce Posted October 3, 2017 Posted October 3, 2017 Thanks for the reply and your work. Ok .. currently I am trying the "NEXT". Wifi seems to work. Except there is frequent kernel(module)-message: "xradio_wlan mmc1:0001:1: missed interrupt" Can't I reduce the kernel debug level to hide this message somehow? I tryied dmesg -n 5, /etc/sysctl.conf->"kernel.printk = "3 4 1 3" and sysctl -w kernel.printk="2 4 1 7" These did not help. PS: Now also it seems that the serial tty-interface is somehow disabled.
Igor Posted October 3, 2017 Posted October 3, 2017 44 minutes ago, A_bruce said: Can't I reduce the kernel debug level to hide this message somehow? From armbian-config if you are running latest beta otherwise peek here https://github.com/armbian/config/blob/dev/debian-config-jobs#L601-L609
A_bruce Posted October 6, 2017 Posted October 6, 2017 When using the NEXT there seems to be a problem with the govenor's. the cores show only 48 BogoMIPS (togehter 194). And cpufreq-set does not change anything.
Igor Posted October 6, 2017 Posted October 6, 2017 6 minutes ago, A_bruce said: When using the NEXT there seems to be a problem with the govenor's. NEXT kernel on H3 is not finished yet and problems are expected. For testing only.
willmore Posted October 6, 2017 Posted October 6, 2017 9 minutes ago, A_bruce said: When using the NEXT there seems to be a problem with the govenor's. the cores show only 48 BogoMIPS (togehter 194). And cpufreq-set does not change anything. That's always been the case, hasn't it?
A_bruce Posted October 6, 2017 Posted October 6, 2017 Possibly I thought this could have been overseen somehow. But it seems many are aware of this. I did not find many comments about this. And NEXT is meant to to be the next mainland kernel? And there are claimed not more than 40 days to the NEXT release .. so possibly this could change soon. But Thanks for the answer anyway.
willmore Posted October 6, 2017 Posted October 6, 2017 From a 3.14.29 kernel: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000) ARM doesn't use a busy wait loop, so the BogoMIPS calculation was abandoned a very long time ago. The value you see now is only a placeholder for old scripts and programs that expect to find it for whatever their reasons.
Igor Posted October 6, 2017 Posted October 6, 2017 7 minutes ago, A_bruce said: And NEXT is meant to to be the next mainland kernel? And there are claimed not more than 40 days to the NEXT release .. so possibly this could change soon. NEXT stable. Made from a recent mainline stable base. We have currently 100+ patches on top and few more are expected to make those little boards usable with a modern kernel. Just hundreds of working hours and we are done 1
A_bruce Posted October 6, 2017 Posted October 6, 2017 1 hour ago, willmore said: The value you see now is only a placeholder for old scripts .. I can not believe this because the NEXT-Kernel makes the system to run much slower. The sysbench and for example some installs take ages. It is not driven or capable to run as fast as it is under the 3.14 kernel. 1 hour ago, Igor said: .. expected to make those little boards usable with a modern kernel .. so it sounds rather not to to expect a recent kernel before the end of 2017
zador.blood.stained Posted October 6, 2017 Posted October 6, 2017 4 minutes ago, A_bruce said: I can not believe this because the NEXT-Kernel makes the system to run much slower. No DVFS on the next branch, so CPU there is running at 480MHz by default. 1
A_bruce Posted October 7, 2017 Posted October 7, 2017 19 hours ago, zador.blood.stained said: No DVFS on the next branch, so CPU there is running at 480MHz by default. And where is frequency scaling and the current cpu frequency now 'visible'? 21 hours ago, willmore said: ARM doesn't use a busy wait loop, so the BogoMIPS calculation was abandoned a very long time ago. .. Are 'all' these (NEXT) kernel design decisions written down somewhere? Could I know about them? Or are they just 'talked' in between the kernel developers only? Is there a place where I could possibly find them together mentioned? Thanks..
zador.blood.stained Posted October 7, 2017 Posted October 7, 2017 12 minutes ago, A_bruce said: And where is frequency scaling and the current cpu frequency now 'visible'? Nowhere. No DVFS in this case means the kernel doesn't know anything about CPU frequency and how it can be read or controlled.
willmore Posted October 7, 2017 Posted October 7, 2017 16 minutes ago, A_bruce said: And where is frequency scaling and the current cpu frequency now 'visible'? Are 'all' these (NEXT) kernel design decisions written down somewhere? Could I know about them? Or are they just 'talked' in between the kernel developers only? Is there a place where I could possibly find them together mentioned? Thanks.. The decision to remove BogoMIPS measurements in ARM was made a decade or so ago. It was made in the open on the linux arm mailing list. You're welcome to search the archives and reread the discussion. If you take issue with any of it, you are free to try to reopen the issue. I would suggest that such a pursuit will not be productive. In the context of Armbian, read the forum here, read the appropriate linxu-* mailing list, and join the IRC channel. All of these decisions are discussed there. Are they distilled into some convenient Wifi? No, but anyone is free to read all of these sources and edit the relevant wiki.
tkaiser Posted October 7, 2017 Posted October 7, 2017 51 minutes ago, willmore said: The decision to remove BogoMIPS measurements in ARM was made a decade or so ago. Or so https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays Edit: sun8i legacy kernel is a 3.4 kernel so we have there high BogoMIPS values, starting with 3.6 on ARM the meaning is something different, now no DVFS so 'next' is a lot slower than 'default' and even if DVFS will work soon those small H3 board with mainline kernel will still be slower compared to before since 1
willmore Posted October 7, 2017 Posted October 7, 2017 4 minutes ago, tkaiser said: Or so https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays Okay, half a decade ago.
A_bruce Posted October 7, 2017 Posted October 7, 2017 3 hours ago, willmore said: .. but anyone is free to read all of these sources and edit the relevant wiki. I am thankful for your all explanations here and it would seem quite a bit of work to fetch all this from the lists. I am keen to be able to use an adapted current kernel but feel not in the position to suggest directions of it. Probably it is working out after a while .. cheers.
Recommended Posts