Builds for Linksys WHW03 V2 + V1

For Developers
83

If you're familiar with compiling your own linux Kernel, you can use the same for OpenWRT.
A starting point could be here.

As a summary, what I do:

  • update and install all packages from feeds
  • run make menuconfig
  • choose IPQ40xx and Linksys WHW03V2 as target
  • select packages LuCi -- ssl with nginx
  • make defconfig -- make sure we're not missing any required configuration for the target
  • make -jX -- where X is the number of threads you want to use for compilation, for instance, in a 1 socket 1 cpu 4 cores with Hyper-Threading, I'd choose -j9
84

Thanks. I hadn't clicked that there was indeed a target defined and didn't fancy guessing everything.

85

Hi @flipy,

Still no luck with the firmware you build. LED stayed purple/pink after I uploaded the firmware. I power-cycled it 15 minute later and it's solid blue. No response to pings.

I'm sorry I can't say any more, as I don't have serial access.

86

If the problem were about the NAND it would surely carry on and eventually complain about the lack of a root filesystem. Isn't the real problem this one about address 8 and isn't that normally the NMI vector ? Sorry I don't have any idea what's really going on.

87

One of the merges from OpenWRT master branch broke my repository -- possibly by wrong file merge.

Anyway, I've updated it and also published a new release that works on my devices.

I'm interested to see the WiFi performance that you get, as I fear the calibration data used by default might need to be changed.

@jms19 your device is slightly different than mine, specifically your NAND chip is different -- mine is a Macronix and yours is a Hynix.
It should not matter as long as it works with the QCOM-NAND.

88

@flipy, unfortunately, the new image doesn't work on my unit. I have the same hardware as @jms19.
I get the sames results as I described last time. Solid pink LED after updating, and solid blue after power-cycle.

89

Interesting, if I can get the output of @jms19 I'll try to dig a little bit more.

@jmceleney which release did you try?
Just uploaded 0.0.3.1 that includes a missing package but it would not have prevented to be installed.

It might be that the factory software does not perform a valid installation.
Which version do you have?
I might try to flash one of the partitions with a factory image and test myself.

90

@flipy This is the firmware and model I'm using: 2.1.8.192419 - WHW03v2.
I'll try downgrading to a much older firmware and then try the install again.

91

@flipy I downgraded to the Linksys firmware 2.1.10.197424 first, and then tried your 0.0.3 factory file again. Same results as last time. I'll try your 0.0.3.1 next, but I doubt that the wpad package will make the difference.

92

Just tested on one device and it did work.
Default configuration requires to connect to the rightmost RJ-45 connector to be able to access LuCi, which is on IP 192.168.1.1.

If that still does not work, I'll need a debug OEM boot log and OpenWRT failed boot log.

93

@flipy Can we compare U-Boot variables just in case there's some difference there ? If you do not have serial access then comparing just kernel commandline and partitioning would be useful

altkern=a800000
auto_recovery=yes
baudrate=115200
boot_part=1
boot_part_ready=3
bootcmd=if test $auto_recovery = no; then bootipq; elif test $boot_part = 1; then run bootpart1; else run bootpart2; fi
bootdelay=2
bootpart1=set bootargs $partbootargs && nand read $loadaddr $prikern $kernsize && bootm $loadaddr
bootpart2=set bootargs $partbootargs2 && nand read $loadaddr $altkern $kernsize && bootm $loadaddr
ethact=eth0
fdt_high=87000000
flash_type=2
flashimg=tftpboot $loadaddr $image && nand erase $prikern $imgsize && nand write $loadaddr $prikern $filesize
flashimg2=tftpboot $loadaddr $image && nand erase $altkern $imgsize && nand write $loadaddr $altkern $filesize
image=nodes_v2.img
imgsize=a100000
ipaddr=192.168.1.11
kernsize=d00000
loadaddr=81000000
machid=8010006
maxpartialboots=3
partbootargs=init=/sbin/init rootfstype=ubifs ubi.mtd=rootfs root=ubi0:ubifs rootwait rw
partbootargs2=init=/sbin/init rootfstype=ubifs ubi.mtd=alt_rootfs root=ubi0:ubifs rootwait rw
prikern=700000
serverip=192.168.1.236
stderr=serial
stdin=serial
stdout=serial
94

Could you try loading the DTS with the instructions I tried here?
Need to change the mmc command to mtd/raw.

I suspect yours is a new revision and hence it is not detected.

95

While I continue to scratch my head here is a tar.bz2 of the /proc/device-tree from the device booted into official firmware.

https://1drv.ms/u/s!ArypLhF63jKWhKQ52Qc5Nn6zkdMeBA?e=dItqv3

To decompile it use a fixed dtc from https://github.com/dgibson/dtc not 1.4.7 which segfaults.

Here is also a good (stock fw) boot log
https://1drv.ms/t/s!ArypLhF63jKWhKQ2hRH6ORDBXDq0IQ?e=uXTydA

96

I had a look at the DTS compiled from the device tree tar.bz2 you provided and looks identical to the one I extracted from the FTD.
Looked at the OEM boot log and looks very similar to the one I also have.

This is tickling my head, so I'll dig a little bit more -- especially when I did try the install the latest build from the factory firmware and had no trouble.

As a temporary solution, could you try to load the ITB thru TFTP from the bootloader?
Ping me if you need further assistance.

97

I've been thinking about versions of things.

The Linksys stock firmware is a 3.14.77 Linux kernel built with gcc version 4.8.3 .

Instead of picking that up, which should be possible with the GPL there has been a lot of effort going into trying to make a v5 Linux with gcc 8 work.

Does the jump in Linux or gcc major version matter ?

Regarding the IPQ4019 I see IPQ40xx/AP-DK07.1-C1 in the boot log.

What revisions of the IPQ4019 do any other products that successfully run OpenWRT use and does it matter ?

98

I have the same problem as @jmceleney: LED solid purple after flashing, solid blue after forced power cycle, device doesn't boot (or at least won't return pings -- I too have no serial access).

My device is a Velop WHW03 v2 (FCC ID Q87-08011). I built my own -factory.bin image from the current HEAD of whw03v2 (commit id 1150e19339).

Output of sysinfo.cgi: https://pastebin.com/ihfqnnZf

99

I have looked at https://downloads.linksys.com/support/assets/gpl/WHW03v2_2.1.13.200188.tgz and compared it to WHW03_v1.1.12.199226.tar.gz

The difference is only a patch 404_MXIC_nand.patch to drivers/mtd/devices/msm_qpic_nand.c and its header file.

I apologise if I am simply catching up with the world while I check whether the patch has in fact been applied to the corresponding source files.

100

Thanks both for testing!

This has been really helpful at least to understand what could change.
AFAIK there are only two revisions of this device, as the Firmware download page on LInksys states.
With the sysinfo we can also see the hw_revision is 2 on your model, so speaking from major hardware differences, there should be none.

AFAIK SoC manufacturers provide a development board to vendors/integrators to play with, and this make references to it.
Vendors such as Linksys might adapt to a different form factor/PCB that could change how all peripherals are interconnected -- one common difference are how are GPIO pins used.

There are many other vendors that work with IPQ4019 -- Habanero, Mikrotik, etc, and it only matters how the design is made to the device.

That might be a hint, although as we can see on the sysinfo or the boot parameters passed related to MTD parts, the partition scheme is the same -- this is one of the most critical aspects to not leave a device inoperable.

I'll dive deep a little bit as it starts to look as they might have introduced a slight change, such as a different NAND chip for which we need to add support for the kernel -- just guessing.
Sad part is that I do not have a revision like yours, so if I make a new test versions, will you be able to test them?

As a side note, I'm learning as I go and I might be wrong/incorrect on some of my assumptions, so please bare with me.

To give you a heads up though, device is working let's say at 80%, although there is one thing that annoys me: WiFi works but I cannot use DFS channels nor expose more channels -- meaning I cannot get a 866 Mbps connection. It could be the device is region locked or that the calibration data in use needs some tweaking.

101

My experience with much the same SLC NAND devices at this level are that they all pretty much the same (given the same footprint) thanks to ONFI. It is more likely that this is the first product that used the NAND interface and they discovered some issues with the SoC driver.

msm_qpic_nand seems to correspond to qcom_nandc in later sources and has functions that feature in the stack trace but everything about the source has been so scrambled so much since Linux 3.14.77 that I cannot be sure let alone tell whether the patch has been applied.

What's on my desk came from John McEleney's desk.

102

Sad part is that I do not have a revision like yours, so if I make a new test versions, will you be able to test them?

Yes, I'll be happy to help you test.

I am also trying to reassemble your changes for v2 on a clean rebaseable branch, in its current shape it's hard to tell which of the changes are intentional and which came from merges back from master. It should also make it easier for you to submit it once it's ready.

WiFi works but I cannot use DFS channels nor expose more channels -- meaning I cannot get a 866 Mbps connection.

I also have MR8300 running OpenWrt snapshot (the plan is to build a mesh of Velops around it), and I think it has the same problem: it wouldn't bring up phy0 on the default channel 100 with DFS, moving it to channel 149 where radar detection is not required fixed that.