Jump to content

orange pi zero, upgraded kernel permanently broken wifi


seandepagnier

Recommended Posts

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?

 

Link to comment
Share on other sites

 

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.

nightly.jpg.ae1956a18c41f135b588a15a0806bd2f.jpg

 

If you did it via armbian-config, something like this appears:

switch_kernel.jpg.c7fdf55c133c9628fdee0d6fa86159db.jpg

or this (if you moved to nightly):

nightly2.jpg.f69c796fd4f0942135777774cdaee9c2.jpg

And if you had a brief look on armbian download page you would see something like this:

opi0.jpg.22d5ccc017b425651b30b493b3811fc6.jpg

and this:

opi0_download.jpg.ffbfb430c76ae23db36252a7aabf2853.jpg

 

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.

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.. :D (but in my case, it ended every time in a crash... :D

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

21 minutes ago, seandepagnier said:

expensive, it cost the same as the OP zero

:lol:

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/

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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..

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines