Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

ghoffman · October 16, 2020, 11:04am

hello.
i've just looked at the openwrt bug tracker, and it seems the dsa issues for mvebu have been removed, and most others have been designated as low or very low priority. does this mean the openwrt developers have essentially deprioritizedd this line, or are things actually working?
i have not had a stable lan/wifi configuration since dsa was moved into development snapshots for this series (wrt1900, wrt3200).
the superwrt builds incorporate a lot of packages on the new dsa snapshot builds, and would be great - but the dsa issues above persist for me.

thankfully, david's last build, and 19.07.4 still work.
i'm trying to get a handle on where openwrt devlopment for this line of routers has moved.

slh · October 16, 2020, 11:49am

Don't overestimate priority levels in flyspray, no one classifies bugs that way. DSA for netifd is staging, but pending merging to master, afaik initial DSA support is also being tested and just waiting for the former.

ffredy · October 19, 2020, 5:14am

Hello folks

I have a WRT1900AC and have tried 18.06.1 and 19.07.4 with very unstable Wifi. The latency to the router's own IP is in the 2 digits milisecons mark. Very often it disconnects from either 2Ghz or 5 Ghz radios and takes a while to re-connect.

Using David's build (r13342) it seems better than 19.07.4, although not 100% still with some instability on the radios that disconnect every in a while and takes some time to be able to connect again.

Has anyone had any success with 19.07.4 ?
The current OpenWrt snapshot for some reasons doesn't seem to have the builds for WRT1900AC v1, only for v2. Does anyone know why ?

ffredy · October 19, 2020, 5:17am

@davidc502 does your build use the same mwlwifi driver of OpenWrt Snapshot or does it use any modified version that makes it more stable ?

razor7 · October 19, 2020, 10:26am

Hi! I’m using 19.07.4 with this driver and stability is about 90%, meaning you can use it pretty well https://github.com/eduperez/mwlwifi_LEDE/releases

anomeome · October 19, 2020, 6:32pm

Partition size has been exceeded for two wrtpac targets (mamba, venom). See PR3205

ghoffman · October 19, 2020, 7:19pm

i will repeat my plea to increase the size of the lernel partition to 6 MB for wrt1900v1 and for wrt32x. the rationale is clearly stated here:

github.com/openwrt/openwrt

Comment by hnyman to [RFC] treewide: try reduce kernel size on some targets

openwrt:master ← lucize:slimmvebu

> in the discourse of the RFC to take a more future-proof approach as been done… with dc50694 instead of constantly fiddling with the kernel source, increase the the boot partition to like 6 MiB and be done. ipq806x devices apparently survived the event even with the inherent inconvenience it may have caused their owners. Based on the experince from IPQ806x, I would recommend the kernel partition size increase approach to be tested. Looking for that kind of partition size modication solution might be easier than looking for a kernel contents change. Changing wrt32x DTS to have kernel+rootfs as 6+117 instead of 3+120 for both dual-boots should work, I think. The total size would still remain as 123 MB, so reverting back to OEM should be possible quite nicely. (for wrt1900ac that would be 6+34 vs. 3+37, I think) For reference R7800: * kernel size change: https://github.com/openwrt/openwrt/commit/dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6 * and subsequently my commit fb8a578aa7 that futher increased the size taking a "Netgear reserved" area into use. (You can read from forum about my tests and debug, I also tested reverting to OEM from modied firmware) With ipq806x devices, the change broke the OpenWrt sysupgrade from older OpenWrt builds, and required using Netgear TFTP recovery flash to install the new version. (But flashing from OEM still works ok). I think that Linksys does not provide quite that easy TFTP recovery flash tool, so jumping to modified kernel size build might require flashing first OEM firmware and then using that for flashing the new OpenWrt, as OEM flashes images in a single sweep, right? Reason why ipq806x OpenWrt sysupgrade failed: our sysupgrade script writes kernel and rootfs in two steps to the locations given in the currently running DTS, not the DTS in the new image. I haven't looked at the mvebu sysupgrade specifics, but I think that follows the same model. If the OEM firmware flashes the image in one sweep, the new OpenWrt image with larger kernel area would likely be flashed quite ok.

github.com/openwrt/openwrt

ipq806x: increase kernel partition size for the Netgear r7800

committed 06:34PM - 22 May 18 UTC

pkgadd

+7 -7

Starting with kernel 4.14 and gcc 7, the kernel doesn't fit into the 2 MB reserv…ed for the kernel partition by the OEM firmware anymore. This patch increases the kernel partition from 2 MB to 4 MB, at the expense of the rootfs, for all supported kernels. WARNING: This breaks sysupgrade! Flashing a firmware containing this changed partitioning from an older image with 2 MB reserved for the kernel partion requires the tftp recovery procedure, thereby losing all settings. This patch is based on a corresponding change by Pavel Kubelun <be.dissent@gmail.com> and has been tested by Michael Yartys <michael.yartys@protonmail.com> Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

slh · October 19, 2020, 7:41pm

You need to check if the bootloader can really cope with larger kernels, afaik linksys sets a fixed size in ubootenv to load from flash - just changing the partitioning wouldn't help without changing ubootenv (and that's problematic for first time installers, upgraders and anyone wanting to revert to the OEM firmware); this wasn't an issue on the ipq806x devices covered by my patches.

anomeome · October 19, 2020, 8:12pm

Those two targets still build successfully for individuals, but the size increase with each kernel push will bite eventually. For example two builds done today:

5.4.71

  3070498 Oct 19 12:41 linksys_wrt1900ac-v1-kernel.bin
  3065738 Oct 19 12:41 linksys_wrt32x-kernel.bin

5.4.72

  3070666 Oct 19 14:00 linksys_wrt1900ac-v1-kernel.bin
  3065906 Oct 19 14:00 linksys_wrt32x-kernel.bin

ffredy · October 19, 2020, 10:36pm

Thanks for the reply @anomeome
Strange because WRT1900ACv1 has 128MB of total flash, so even with 2 partitions there is a fair amount of space to have a much bigger partition, doesn't it ?

Seems the rationale behind @ghoffman make sense, what do you think ?

slh · October 19, 2020, 10:46pm

You need to check https://openwrt.org/toh/linksys/linksys_wrt1900ac#flash_layout for details, https://openwrt.org/toh/linksys/linksys_wrt1900ac#openwrt_bootlog (in particular NAND read: device 0 offset 0xa00000, size 0x400000) would also be relevant. So even with 6 MB flash being reserved for the kernel, the bootloader will only attempt to read the first 4 MB of that. In the best of all cases this size value it defined in uboot-env (see fw_printenv for hints) - changing this might work, or it might fail fatally <-- this would need testing (with an oversized kernel), in worse cases the bootloader would need rebuilding with different settings or the introduction of a second stage bootloader between u-boot and kernel+rootfs.

ffredy · October 19, 2020, 10:51pm

Hi @slh perhaps some stuff from the kernel can be moved to modules. But yes, second stage could be also an option in the worse case.

ffredy · October 19, 2020, 11:08pm

Hi @razor7 did you install 19.07.4 and then dowgraded it to eduperez/mwlwifi version with "opkg install --force-downgrade" ?

razor7 · October 19, 2020, 11:40pm

Yes, that's it!

shuttleman58 · October 20, 2020, 4:10am

@davidc502 : Can you help clarify this for me?

Just a quick question. I am getting ready to upgrade from kernel 4.14.103 r9506 to 5.4.41 r13342 of David's builds. Any gotcha's I need to know about (1900ACS)?

(I was advised download a backup of my config, remove /etc/config/ubootenv and /etc/fw_env, repack. Upgrade w/o keeping config, then restore the modified backup.)

knubbze · October 21, 2020, 7:43pm

I'm currently running r12235 / kernel 4.19.101 of David's build, but unfortunately I don't have time to follow the developments in this thread very often, so I usually just visit his site every few months and upgrade to the latest build (mainly just for security reasons).

I just went to his site after not upgrading for quite some time and read his notice advising that there won't be any new builds for the time being. So, I'm wondering what I should 'upgrade' to - the last Davidc builds are from May of this year - would it still be OK to use this version, several months on? Or are there any other community builds which would be preferable? I saw some mentions of a 'SuperWRT' build? Or would the latest official OpenWRT 19.07.4 release be the best choice?

phinn · October 22, 2020, 1:01am

Just run the final davidc502 build. Comes with Linux kernel 5.4.x and is rock solid for me. At least until OpenWrt does a 20.x build (if they actually do) then re-evaluate.

T-Troll · October 22, 2020, 10:15am

Nice build, no issues, but dragons living in update process - read thread about it and DO NOT keep configuration.

knubbze · October 22, 2020, 4:30pm

Thanks for the warning - is there a guide anywhere on how to safely upgrade?

T-Troll · October 23, 2020, 9:10am

Check up this thread, we have a discussion about it close to firmware release date.

Basicaly, you should NOT keep the configuration.

If you made backup - you need to delete 2 hardware-related files from it before restore backup. Or set all options again manually.