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.
@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.
@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.
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.
@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
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.
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
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.
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 ?
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
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.
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.
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.
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.
As promised, here's reassembled rebaseable branch: https://github.com/angdraug/openwrt/tree/linksys-whw03v2
Notable differences from the tip of whw03v2:
An image built from this branch yields exact same outcome as before: device won't boot.
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.
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?
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 ?
I have Linksys VLP01. will this work for that?
Thank you very much! 
Use this for the VLP01, which is identical to the WHW01.