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.

sera wrote:

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.

I standardized with wan.

@sera
I dare to assume armada-385-linksys.dtsi will change to include rango in the Linksys series?

Chadster,

Thanks. You wouldn't know of other DSA users with Mamba?

Off... to prepare an swrt release.

ValCher wrote:

@sera
I dare to assume armada-385-linksys.dtsi will change to include rango in the Linksys series?

Yes, armada-385-linksys.dtsi should be included by Rango as well. That requires some changes to the dtsi as well.

sera wrote:

Chadster,

Thanks. You wouldn't know of other DSA users with Mamba?

Off... to prepare an swrt release.

Sorry I don't but I think most users that do would be subscribed to this thread.

swrt-2017-04-10
---------------

While there was progress on the O_TMPFILE issue wrt ubifs, a complete fix is
still missing, so carry over the disable O_TMPFILE support patch.

Mamba uses internet as label for the INTERNET port unlike the others which use
wan, sent a patch out to get this discussed upstream. Waiting for a final
verdict here. For the time being use "wan" for all. For Mamba users this means
you have to replace internet with wan in your network configuration if you
don't use the default one (generated during first boot).

Also dropped the pxa-nand patch in next only. This branch is for testing. So if
the issue is still reproducible get a log from a recent kernel which would help
to revive the issue upstream.

Then as promised a couple version bumps. Changes to kernel configuration,
namely disable the RTC and enable MMC support. Additionally the firmware
packages and drivers for the sd8887 so those who wish to play with it can do
so. That said an improved dts is slowly taking shape but not yet ready for
prime time. Also add the mwlwifi firmware packages meant to be used with the
in-kernel driver in future and which were the occasion to package the former.

next-20170406+ fail to build due to btrfs commits, to be able to do a release
today I used next-20170405, will look into the issue later.

A few packages always fail to build, as it seems standard to feed install all
packages and not just those people care about, I changed the build_dist script
to ignore errors for packages which wont get included in the image when
--build-packages is given.

* linux-4.10: bump to 4.10.9
* linux-4.11: bump 4.11-rc6
* linux-next: bump to next-20170405

* libnftnl: version bump to 1.0.7
* nftables: version bump to 0.7
* iproute2: version bump to 4.10.0, vanillify a bit
* ubox: version bump to 2017-03-10
* linux-firmware: bump to 2017-01-13
* mwlwifi-88W8864-firmware: add package
* mwlwifi-88W8897-firmware: add package
* marvell-sd8887-firmware: add package
* kmod-btmrvl: add module
* kmod-btmrvl-sdio: add module
* kmod-net-mwifiex: add module
* kmod-net-mwifiex-sdio: add module

* profile: add sd8887 firmware to default packages
* kernel-config: disable RTC support, doesn't work for this boards and some
  doggy software appears to have issues with that.
* kernel-config: enable MMC subsystem and driver
* kernel,DSA; use wan for all
* linux-next: drop pxa-nand patch

* swrt/README: a couple updates
* swrt/build_dist.bash: ignore errors for packages not part of the image,
  simplifies the use of --build-packages


swrt-2017-04-10.tar.xz: https://gpldr.in/v/o4vzW2qot7/ekXMKs3IWZDvIeyX
sha256sum: 9eaf704169323798635ca0b2fbc6964dcabb065c14cb4eddd653258f01c81f70

@sera.
In the file rango.dts in the section regulator reg_xhci0_vbus recorded [gpio1 16] and in section & pinctrl [mpp47].
It seems should be 47-32 = 15, i.e. [gpio1 15], or am I wrong?

@sera

4.10 build pukes at swconfig.c:1226:9: error: implicit declaration..................................

Will try 4.11 and next but expect same results

Cheers

ValCher,

the dts in swrt is the one from OpenWrt execpt for the swconfig node fixup to silence the DTC warning. The replacement will be at least a dozen patches. The difficult part is to somewhat future prof the armada-385-linksys.dtsi and organize the changes in a way the chunks remain reviewable. That's what I'm up to currently.

According to nitroshifts patch I linked it's mpp47 / &gpio1 15. According to your report earlier mpp44 / &gpio1 12. I have yet to take out the voltmeter to verify either. Fixups like this are probably the tedious part wink

doiTright,

No need to try 4.11, looks like the function swconfig is calling got removed in 4.10. A fix should be easy, just a shame there is no proper upstream repository for swconfig. Thanks for the report.

Sorry what is the purpose of adding bluetooth support... does our router support it ?

The rango does

Ansuel,

as well as NFC and FM radio support, a purpose you have to create for yourself smile

swrt-2017-04-11
---------------

Beside the swconfig fix for 4.10+ I added a bump of next. The btrfs issue got
replaced with broken xhci, so revert the bogous commit for that one.

* linux-next: bump to next-20170411

* swconfig: fix for kernel 4.10+

* kernel: next: drop disk-activity patch, already in.
* kernel: next: revert bad xhci commit

swrt-2017-04-11.tar.xz: https://gpldr.in/v/Nc1S8djoJe/5t0rw00qJtCvuJvN
sha256sum: ae8604852f8af8b4df86ea7b029f2472322fa1275d9270594f267b4a86f38c47

sera wrote:

doiTright,

No need to try 4.11, looks like the function swconfig is calling got removed in 4.10. A fix should be easy, just a shame there is no proper upstream repository for swconfig. Thanks for the report.

I ran 4.10, 4.11, and next with the same result (as expected)

Will start the builds for swrt-2017-04-11 shortly

Cheers

sera wrote:

swrt-2017-04-10
---------------

Mamba uses internet as label for the INTERNET port unlike the others which use wan, sent a patch out to get this discussed upstream. Waiting for a final verdict here. For the time being use "wan" for all. For Mamba users this means you have to replace internet with wan in your network configuration if you don't use the default one (generated during first boot).

Is this only on certain mamba builds, or something that changed in the last year or so?

  • I only ask because I did my last mamba build about a year ago, and up until that time, the interface name for port 4 was always wan [in DD, can't remember on CC].

I've seen this mentioned a view times over the last year here and there, but always assumed it was simply due to specific builds.



Slazer wrote:

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?

If you're using Windows, SMB [samba] would be preferred to NFS, whereas NFS is generally preferred for Linux OSes (IIRC).

(Last edited by JW0914 on 14 Apr 2017, 07:51)

@sera can you tell me if rtc works on wrt1900acs
on mine hwclock command doesn't work at all... and it's bad cause in the first stage of the boot openwrt uses this to gain the time (and then syncronyze with the ntp)
Some time ntp doesn't works and that strange time (that gets converted to something like 2355...) mess with all the certs present on the board and if someone like me have dnsmasq with dnssec... well all his network is fuck*e LOL
Any idea to fix this? or just drop rtc support?

JW9014,

the vanilla kernel always used "internet" for the label. I'm not aware of OpenWrt ever having had a patch to change this. Also OpenWrt never used DSA, so unless you made the necessary changes I doubt you used it on plain OpenWrt. As labelling it "wan" would have made sense chances are good that the image you tried was patched by the author.

Ansuel,

It depends on the definition of works, as the RTC isn't battery backed it is mostly useless. Looking at doiTrights log snippets the busybox applet seem to crap out if the clock is currently in an invalid state. Reset the clock from uboot to fix that. Then across a reboot without cutting power it sort of works.

What needs "internet" time needs to be started after ntp did synchronize to work reliable. Everything else just needs the time to be monotone.

---

doiTright, did disabling the clock fix your luci slowness? To early to tell?

@sera but if i try to set the rtc with command it doesn't change at all... What could be the problem? the invalid state?
Do you know any hardware modification to add a battery ?

@sera

The Luci slowness went away after a reboot and has not occurred again. 

I have not had much time to play this week, but I had swrt-2017-04-11 running on my mamba for a few minutes...

Had to roll back to 03-28 because something was wrong with both radios (did not capture the error messages)

Time permitting, I will give 04-11 a spin on both mamba and rango this weekend

Cheers

Ansuel,

maybe try the one from coreutils instead of busybox or simply reset the clock to see if this was the issue. About hardware modding, I don't have access to Linksys documentation nor have I taken the device apart to see whether the pins are reasonably identifiable or even accessible. Maybe ValCher (our master modder) would know more. Either way delaying starting of services until the time is synchronised works anyway.

The nginx inclued in 15.05 can not run normally in reverse-proxy mode.
I have re-compiled the nginx package, but it still can not fix the problem, Neither the nginx source version of 1.4.7 nor 1.10.3.
It looks like that the "status line" returned by the upstream has disappeared.
Only on a WRT1900ACv2, the problem always appears. the Devices else i tried include XiaoMi mini , HG255d, 843Nv1.
Is there a bug in another module, may be ?

@Ansuel,
@sera
If you're talking about standalone RTC with battery, the motherboard has no place to install quartz 32768 kHz and battery.

ValCher wrote:

@Ansuel,
@sera
If you're talking about standalone RTC with battery, the motherboard has no place to install quartz 32768 kHz and battery.

so the rtc is present but is not present o.O WTF!