Builds for Linksys WHW03 V2 + V1

For Developers
103

As promised, here's reassembled rebaseable branch: https://github.com/angdraug/openwrt/tree/linksys-whw03v2

Notable differences from the tip of whw03v2:

  1. Pass only half of the size of u_env mtd to ubootenv_add_uci_config (not sure why but ea8300 and mr8300 cases do that and it works for them).
  2. Don't patch back out mr8300 support (should help with cleaner rebase in the future).
  3. Drop the 4.19 bits and move dts from files-5.4 back to files (not 100% sure about this move but it looks like the old target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-whw03v2.dts got grandfathered in from whw03v1).

An image built from this branch yields exact same outcome as before: device won't boot.

104

Thanks for the rebase.

No clue, but MR8300 might have a different partition scheme.

Some leftovers from various tests/merge I guess.

This is inherited from when there were two major kernel version, might need to check what master branch is doing.

Been comparing the DTS file from Linksys GPL to the one I have on my github.
Indeed there are only two versions specified, and there are subtle changes between the two.
Factory image passes the MTD partition scheme as a boot parameter, whereas I decided to use fixed-partitions instead.
However, factory image defines a QPIC NAND at address 0x7980000 which I cannot find on the default DTSi for IPQ4019. -- it actually seems there is a double mapping, as it defines two sets of addresses, 0x7980000 and 0x07984000, the latter being mapped to QPIC BAM on the default DTSi; and if we look further, it defines a UART on the same address on an intermediate DTSi to just disabled it on the DTS and enable NAND.

I've built a new test version, whose only changes is to load partitions when the NAND chip m25p80 is defined instead of at the QPIC NAND level.
Don't have much expectations that it'll work, but you can get it form github.

105

Yes, this new version didn't make a difference, still won't boot. FWIW I'm pretty sure the partition layout is not the problem here, what you have in DTS matches what I see in sysinfo.cgi.

While poking around the patches included in Linksys GPL release, I found one patch for u-boot that isn't a backport of an upstream bugfix and seems Linksys specific: 200-linksys_find-mtd-part-num.patch. Did you see it? I don't know u-boot enough to understand the context of why it's doing this, but it replaces a static #define that defaults to /dev/mtd1 with a dynamic lookup of the "u_env" partition by name in /proc/mtd. I am probably missing something in DTS that makes this hack unnecessary, because MR8300 also has u_env in a different partition than /dev/mtd1 and OpenWrt that doesn't include this patch boots fine.

If it's not bad boot configuration, might be a kernel panic because of a missing or buggy driver. No way to confirm that theory without serial access, but maybe you could cut down the DTS just to the bare minimum required to boot the system with just the Ethernet and no other hardware enabled?

106

Would it be possible to use the Linksys supplied 3.14.77 kernel source combined with OpenWRT userland ? How much do OpenWRT's features depend on changes made to the kernel since the Linksys code release ?

107

I have Linksys VLP01. will this work for that?

Thank you very much! :slight_smile:

108

Use this for the VLP01, which is identical to the WHW01.

https://openwrt.org/toh/linksys/linksys_whw01_v1

109

Hi everyone I am new and trying to find a working link to download a build for my velop WHW03 v1

110

Thanks for your work, I just now stumbled upon this thread. Could you provide a new link to the WHW03V1 build?

111

hey did you get a reply from anyone?

112

Unfortunately not, I will try to build his branch on github wenn I find some free time (not before easter).

113

I will try to build a new version based on the latest master branch of OpenWRT.

On my GitHub there are binaries to install on both models.
Note that going back to default firmware does require some command line knowledge.

There is an observed performance drop that I am investigating, most related to MUMIMO and 160hz frequency scope.

114

Just a quick update: I am currently working in migrating to the next stable release, 21.02; and resolving a WiFi performance issue detected.
V2 will be the first one to have a new build, and then I'll ask for help to test V1 as I only have 1 working device.

1 Like
115

Uploaded a new build for V2.

Will do some more testing and benchmarking, but build is usable at this point.

Update: Did some initial benchmarking over the IPQ4019 wireless driver and it now behaves as expected.

2 Likes
116

New build for WHW03 V1.

Benchmarking shows improvements as well, but user feedback is important.

Do make a backup of your current partitions before updating/installing.

Note: if possible do a fresh install from factory firmware.
Otherwise, pull the latest linksys.sh upgrade file from the same release tag and replace on the current version.

1 Like
117

Note for the brave souls:
On both devices Linksys has a configuration partition to store common files between firmware versions.

In V2 size is close to 150Mb while in V1 is close to 3.4Gb.

The current OpenWRT implementation does not use this partitions but, if needed, I can add it or explain how to mount it to take benefit from it.

1 Like
118

I really appreciate your efforts on making OpenWRT work for this device.
I recently got your latest build flashed onto 2 of my WHW03 V1 nodes. Just wanted to mention a few issues I'm seeing on my units.

  1. Radio0 seems broken and does not seem to be communicating at al. Host or client mode.
  2. Devices connected to either radio1 or 2 do not seem to be able to get a ipv4 address. ipv6 seens to work.
  3. Network forwarding between WAN firewall and LAN firewall thus devices on LAN are not getting network to the outside world.
  4. It seems like the power output from the radios are low. I am comparing it to my 1 factory flashed node which seems to have at least 3x the range.

Thanks again for all your work!

119

I will look at it during the weekend; however, that behavior seems strange. Have you done a factory reset?

I only have one V1, but it's working with all 3 radios and devices do get IP v4 addresses (though they are not the authoritative DHCP server).

120

I have tried a factory reset and reflashed the latest build on your github (0.0.4.1). Same results
The DHCP server that im trying to use is hosted on my network gateway and not the nodes. But I have tried the node's DHCP server as well and still not working.
The radio0 is showing up as active but it isnt broadcasting any signal nor does it see any other wifi signal in the area.

121

I have just tried the build for V2 dated 12th March. I used the file called sysupgrade from https://github.com/flipy/openwrt/releases/tag/whw03v2-0.0.4 and applied it to this v2 unit at /fwupdate.html

The kernel reports a build date of Mon Mar 8 11:46:46 2021 so it is new. Unfortunately it does the same thing with

[    1.048062] ------------[ cut here ]------------
[    1.055671] WARNING: CPU: 0 PID: 1 at drivers/mtd/nand/raw/nand_base.c:5579 nand_scan_with_ids+0x178c/0x1790
[    1.060524] No oob scheme defined for oobsize 0
[    1.070308] Modules linked in:
[    1.074553] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.102 #0
[    1.077675] Hardware name: Generic DT based system
[    1.083858] [<c030e544>] (unwind_backtrace) from [<c030afc0>] (show_stack+0x10/0x14)
[    1.088457] [<c030afc0>] (show_stack) from [<c0853218>] (dump_stack+0x94/0xa8)
[    1.096352] [<c0853218>] (dump_stack) from [<c03213ac>] (__warn+0xbc/0xd8)
[    1.103379] [<c03213ac>] (__warn) from [<c032144c>] (warn_slowpath_fmt+0x84/0x94)
[    1.110239] [<c032144c>] (warn_slowpath_fmt) from [<c0659d04>] (nand_scan_with_ids+0x178c/0x1790)
[    1.117796] [<c0659d04>] (nand_scan_with_ids) from [<c06606a0>] (qcom_nandc_probe+0x518/0x934)
[    1.126649] [<c06606a0>] (qcom_nandc_probe) from [<c0627e60>] (platform_drv_probe+0x34/0x70)
[    1.135156] [<c0627e60>] (platform_drv_probe) from [<c06264d8>] (really_probe+0x1f0/0x358)
[    1.143748] [<c06264d8>] (really_probe) from [<c0626a28>] (device_driver_attach+0x58/0x60)
[    1.151819] [<c0626a28>] (device_driver_attach) from [<c0626a88>] (__driver_attach+0x58/0xcc)
[    1.160067] [<c0626a88>] (__driver_attach) from [<c0624a2c>] (bus_for_each_dev+0x68/0x8c)
[    1.168660] [<c0624a2c>] (bus_for_each_dev) from [<c06259b0>] (bus_add_driver+0x1c8/0x1d8)
[    1.176817] [<c06259b0>] (bus_add_driver) from [<c0627010>] (driver_register+0x74/0x108)
[    1.184978] [<c0627010>] (driver_register) from [<c0302764>] (do_one_initcall+0x84/0x1d8)
[    1.193231] [<c0302764>] (do_one_initcall) from [<c0b00fcc>] (kernel_init_freeable+0x1c4/0x26c)
[    1.201303] [<c0b00fcc>] (kernel_init_freeable) from [<c0868f7c>] (kernel_init+0x8/0x114)
[    1.209806] [<c0868f7c>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[    1.218132] Exception stack(0xdf43bfb0 to 0xdf43bff8)
[    1.225596] bfa0:                                     00000000 00000000 00000000 00000000
[    1.230722] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.238883] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    1.247090] ---[ end trace c7df6a2e882db4d6 ]---
[    1.253486] 8<--- cut here ---
122

Hi [flipy],

would it be possible to use the WHW03_V1 Image for the WHW01_V1 as well?
I have some WHW03 as well as WHW01 and would like to use OpenWRT on all of them.

I have flashed one of my WHW03_V1 with your image and it's working fine except the WiFi range and Radio 0 as mentioned before. The range is far less than stock Firmware and radio 0 is not active. Is there anything I could tweak to improve it?

Best regards
Björn