OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

tapper,

I looked into DFS and cpuidle before. However, returning from deep idle state caused the kernel to panic. The issue is the drivers weren't written with hardware coherency in mind. So it's either using software coherency or rewriting drivers of which both suck. That's were I left things rest.

Then there is also the question of added latency (switching power states is usually really costly) and how efficient this power saving mechanism actually are for this boards before giving a recommendation. Expecting the same results as with a standard Intel desktop might be very far from the truth but unless people play with such things we wont know.

ValCher wrote:

Thought only on my wrt3200 temperature jumped to 100°C.
I freaked out and installed a fan on wrt3200.

ValCher,

how did you wire the fan? Unlike the armada-xp there are no GPIOs on the armada-385 that could be used for PWM, guess that's at least one of the reasons as to why there is no fan any longer.

@JW0914
@sera
I solved the problem of temperature rise. On the Board remained rudiment of the mamba is a location to install the fan connector and power control key (MOSFET). In these places, I installed the necessary elements. It turned out that the fan control circuit is connected to the mpp18 processor. Applied patch PWM-FAN from the mamba.
Now, compile the kernel at wrt3200, the temperature does not exceed 75°C.
https://github.com/Chadster766/McDebian … -290790365

ValCher,

thanks for the link and pictures. You even cut out a space for the fan, nicely done. A few notes.

1) The PWM-FAN patches can't possibly have an effect. The armada-385 doesn't have the required blink registers. Only armada 370 and xp have those. To use the pwm-fan driver for mamba you'd have to edit armada-38x.dtsi as well, and if you do you should see a kernel panic.

You are using your fan as a gpio-fan and the binding should look along the lines of:

gpio-fan {
        compatible = "gpio-fan";
        gpios = <&gpio0 18 0>;
        gpio-fan,speed-map = <0 0>,
                             <4500 1>;
};

2) mvsw61xx vs swconfig node. The former is the one used in OpenWrt, as you noticed the DTC complains. Fixing this requires changes to swconfig core. As it happens the switches on our devices to not use indirect addressing and so just dropping the "reg" property works as a workaround. I used swconfig for the node name but switch@72004 or such would be even better. Either way mvsw61xx is clearly against conventions. There is no functional impact due to this change. The whole thing behaves exactly the same as the original bindings except for the DTC warning being gone.

3) tlc59116 vs pca9635. Those are different chips with separate drivers. They serve the same purpose and the drivers seem compatible enough according to your testing. However this is not how it's supposed to be handled at all. I suggest to revert this change.

4) You add an "usb_power" property to the usb nodes, don't know how you ended up with this, but it will just silently be ignored.

@sera
Thank you very much for explaining and supplement, especially for valuable clarification on agenda item 2, and in future I shall.


About PWM-FAN, Yes, I have added the appropriate lines to armada-38x.dtsi, but because my hwmod in a single copy, I did not publish that would not enter anyone astray.

I agree with you tlc59116, I wrote installed chip markings, functionally they are the same.

Thanks for the comments on paragraph 4, with this I'll tackle next.

@ValCher Out of curiosity, is your 3200 placed in an area with poor ventilation?  Even under intense load, provided it's getting a minute amount of passive air flow at 2 - 3 CFM, and provided the ambient air temp is within the mid 70F [~24C] range, it shouldn't be overheating.  It could be you're limited in areas it could be placed within, however if you are able to move it, that should resolve the issue without the need for a fan.  (Then again, I'm a bit biased and prefer passively cooled equipment whenever possible =])

@JW0914
Router installed indoors on the Bookshelf with a height of 2 meters, ceiling even 1 meter. Room temperature not exceeding 23° c.
On the router, the processor temperature rises when improper use it, namely when you compile the kernel and modules. This is a very big load on the processor. If you use a router on its purpose, the processor temperature is 80 ... 85° c.
In addition to installing the fan, I have replaced the thermal pads on copper plates. All this greatly increased the degree of cooling.
Before modernization, temperature when compiling reaches 100° c.
After upgrading (without fan), the temperature of the processor does not exceed 93° c. When using the mechanical ventilation, the temperature does not exceed 75° c.
I did not encourage conduct similar upgrades, because when you use the device for its intended purpose, head cooling system fully cope with the heat.
A little off topic.
WRT1900ACv1 vs WRT3200ACM-Time compile the kernel and modules.
WRT1900ACv1 - 1:30
WRT3200ACM -  0:40
What a performance!

@ValCher If you're using it for compiling, that makes sense.  I tried doing the same when I first got my 1900ac v1 years ago and I couldn't stand the noise of the fan on high during the compile so I abandon that idea lol

JW0914 wrote:

@ValCher If you're using it for compiling, that makes sense.  I tried doing the same when I first got my 1900ac v1 years ago and I couldn't stand the noise of the fan on high during the compile so I abandon that idea lol

Regardless of what processes are run on the WRT3200ACM it shouldn't overheat. I'm concerned that this is a hardware design problem.

If would be great if others can check there temps for comparison. If the temps do reach 100deg I will have to notify Linksys engineering of the issue.

Chadster766 wrote:
JW0914 wrote:

@ValCher If you're using it for compiling, that makes sense.  I tried doing the same when I first got my 1900ac v1 years ago and I couldn't stand the noise of the fan on high during the compile so I abandon that idea lol

Regardless of what processes are run on the WRT3200ACM it shouldn't overheat. I'm concerned that this is a hardware design problem.

If would be great if others can check there temps for comparison. If the temps do reach 100deg I will have to notify Linksys engineering of the issue.

My WRT3200, running Gargoyle, is rock solid at 72 degrees Fahrenheit.

mojolacerator wrote:
Chadster766 wrote:
JW0914 wrote:

@ValCher If you're using it for compiling, that makes sense.  I tried doing the same when I first got my 1900ac v1 years ago and I couldn't stand the noise of the fan on high during the compile so I abandon that idea lol

Regardless of what processes are run on the WRT3200ACM it shouldn't overheat. I'm concerned that this is a hardware design problem.

If would be great if others can check there temps for comparison. If the temps do reach 100deg I will have to notify Linksys engineering of the issue.

My WRT3200, running Gargoyle, is rock solid at 72 degrees Fahrenheit.

Great thanks for the reply.

@sera

The mamba running next was up almost 9 days and crashed just a few minutes ago.

Nothing in the log because it stopped logging on March 29th smile

.
.
Wed Mar 29 22:32:24 2017 daemon.notice netifd: Interface 'wlan5GHz' has link connectivity 
Wed Mar 29 22:32:24 2017 daemon.notice netifd: Interface 'wlan5GHz' is setting up now
Wed Mar 29 22:32:24 2017 kern.debug kernel: [   21.471962] ieee80211 phy1: change: 0x2
Wed Mar 29 22:32:24 2017 kern.info kernel: [   21.475883] wlan1: associated
Wed Mar 29 22:32:24 2017 kern.info kernel: [   21.479164] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Wed Mar 29 22:32:24 2017 daemon.notice netifd: wlan5GHz (1768): udhcpc (v1.24.2) started
Wed Mar 29 22:32:24 2017 daemon.notice netifd: wlan5GHz (1768): Sending discover...
Fri Apr  7 21:19:28 2017 kern.info kernel: [   21.757037] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1-1: link becomes ready
Fri Apr  7 21:19:28 2017 kern.info kernel: [   21.763820] br-lan: port 5(wlan1-1) entered blocking state
Fri Apr  7 21:19:28 2017 kern.info kernel: [   21.769377] br-lan: port 5(wlan1-1) entered forwarding state
Fri Apr  7 21:19:28 2017 daemon.notice netifd: Network device 'wlan1-1' link is up
.
.

During the 8 plus days I had the odd wifi hiccup (work vpn would re-connect etc.), but nothing major

Also, wifi was noticeably slower during regular use...

Cheers

Hi Community,

there is a "v2 needs newer wifi driver" warning on Linksys WRT1200AC concerning both OpenWRT and LEDE, inside the "Table of Hardware: Ideal for LEDE" table bellow.

https://lede-project.org/toh/views/toh_ … =WRT1200AC

I wonder if this is a temporary issue, what is its impact (for me) and whether I should consider it when buying this router and perhaps buy the "older" HW revision.

I have a 802.11ac card inside the desktop and would like to create NAS from my USB3.0 external HDD (max 45 MBps) 2TB storage using NFSv4, perhaps. The 2.4 Ghz is incredibly crowded in here, so 5 Ghz is mandatory. The distance will be negligible. I also will have a LineageOS phone.

Is there anything else I should know, considering the intended use-case?

Chadster766 wrote:
mojolacerator wrote:
Chadster766 wrote:

Regardless of what processes are run on the WRT3200ACM it shouldn't overheat. I'm concerned that this is a hardware design problem.

If would be great if others can check there temps for comparison. If the temps do reach 100deg I will have to notify Linksys engineering of the issue.

My WRT3200, running Gargoyle, is rock solid at 72 degrees Fahrenheit.

Great thanks for the reply.

@mojolacerator Are you sure it's 72F [22.22C] or 72C [161.6F]? It's likely 72C, as most SOCs run north of 113F [45C].  72F would be cool to the touch, the same as water at room temperature.

(Last edited by JW0914 on 8 Apr 2017, 12:16)

JW0914,

You could put the device into a freezer to get to 72°F, old overclocker trick wink. Probably you are right and he meant °C instead.

---

Chadster,

My current readings:

# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
DDR:          +50.5°C
WIFI:         +52.9°C

armada_thermal-virtual-0
Adapter: Virtual device
CPU:          +80.4°C

As cpuidle isn't working I don't expect the CPU temperature to rise a lot under heavy load. Will have to test though.

ValCher,

now that you have a fan you could overclock the device to 2GHz, that's what Marvell rates those SoCs and what Linksys might use for the next big upgrade in the product line.

doiTright

The log issue is a first, maybe updating ubox (logread) helps, I'll add it to the list of packages to update. There is still the Mamba pxa-nand regression revert patch. You could try if removing that one helps. Guess I do it for next anyway so someone can post the failure with a recent kernel if it's still possible to trigger. Certainly would help for reviving this issue upstream.

Any issues with Rango and mwlwifi, not that it would help, just wondering.

sera wrote:

JW0914,

You could put the device into a freezer to get to 72°F, old overclocker trick wink. Probably you are right and he meant °C instead.

lol Or liquid nitrogen, as was done with the new Intel CPU to overclock it to 7gHz+

Anyone tried replacing original wifi with eg. R11e-5HacT and R11E-2HPnD? Will those cards work with WRT1900AC (ofc with special OpenWRT build including proper drivers)?

sera wrote:

doiTright

The log issue is a first, maybe updating ubox (logread) helps, I'll add it to the list of packages to update. There is still the Mamba pxa-nand regression revert patch. You could try if removing that one helps. Guess I do it for next anyway so someone can post the failure with a recent kernel if it's still possible to trigger. Certainly would help for reviving this issue upstream.

Any issues with Rango and mwlwifi, not that it would help, just wondering.

Looks like the Rango stopped logging last night as well... 
Date and time were messed up too....  but still up and stable:

Model Linksys WRT3200ACM
Firmware Version OpenWrt Designated Driver 50104+swrt-2017-03-28 / LuCI Master (git-17.087.65547-3dc08a3)
Kernel Version 4.11.0-rc4-next-20170328
Local Time Sat Apr 8 11:03:06 2017

Fri Apr  7 07:30:00 2017 cron.info crond[1192]: USER root pid 4529 cmd /sbin/fan_ctrl.sh
Sat Apr  8 11:00:57 2017 user.notice sysfixtime: saved 'Sat Apr  8 11:00:57 EDT 2017' to /dev/rtc0
Sat Apr  8 11:00:57 2017 daemon.err uhttpd[1237]: hwclock: settimeofday: Invalid argument
Sat Apr  8 11:01:04 2017 cron.err crond[1192]: time disparity of 1649 minutes detected

doITright

Interesting find, wonder what doggy app is trying to mess with the hwclock . The the RTCs on this boards aren't really useable. Probably you can get it to tick by resting it in u-boot. However that is in wane as there is no battery backing the clock. Getting this message from uhttpd would also suggest this doggy app to be the issue for your slow luci. Let's see if disabling RTC support will cure this. Expect the next release tomorrow.

So the canonical driver with swrt works for 3 people vs 1 as reported, 75% is a lot higher than expected, thou the sample size is ridiculously small wink

sera wrote:

now that you have a fan you could overclock the device to 2GHz, that's what Marvell rates those SoCs and what Linksys might use for the next big upgrade in the product line.

But not now, first I want to wait for the normal driver Wifi.
Who knows when to appear in the release of the Linux kernel rango.dts?

ValCher

My target for the rango.dts is kernel 4.13. Two patches toward that goal I already sent upstream, one of them still under review, the other one got merged last week.

---

Chadster,

About the interface names for DSA, internet vs wan for the INTERNET port on Mamba; McDebain is the only other firmware currently using DSA I know of. What's your and your users take on labelling them all wan (or alternatively internet) vs keeping as is? How do you handle the name differences currently (documentation, udev, something else)?

Others are obviously welcome to skim in for this as well.

belliash wrote:

Anyone tried replacing original wifi with eg. R11e-5HacT and R11E-2HPnD? Will those cards work with WRT1900AC (ofc with special OpenWRT build including proper drivers)?

noone tried?