Glad to hear this, but if I understood right: testing is not done by "cooking" bin's and flashing them in emergency/recovery mode (which accepts "any" firmware)? There shouldn't be a need for tftp.
Sorry if I appear too simple, but: take openwrt from dir-859 (edit: 869 also similar, all revisions?), put qca9888 driver and the hw addresses found in bootlog. And done. It should just work, isn't it?
This is where my limited knowledge and availability of tools ends. Advanced software and hardware is something that I won't be able to help with. I can learn and acquire them, but it takes time and money.
However I am perfectly willing to:
Try and find someone to do a hexdump on the memory, in the process desoldering it and destroying the router.
Mail it in Europe (or even somewhere else not too far away from Romania) via post service, it's dirt cheap.
Risk bricking the device with even the most poorly built firmware, with the poorest of boot tricks stuck-together.
The C2 support has been merged into master. That image should work on C1 as well.
If someone is ready to test, it is quite easy to add official C1 support.
Mainly because the USB on C1 can be modded with some soldering skills. So people wont have to recompile the image if they have a modded C1, they just have to install kmod-usb2
This is not the way it is normally done. Those who can solder USB can also build an image with modified dts.
Otherwise I don't see a reason of having a separate image for c1. We could have one for both c1 and c2 since the only diff is the USB.
Has anyone actually confirmed that GPIO 15 is correct for the power / status LED ?
I'm just wondering why it's constantly on during boot, rather than showing the typical OpenWRT flash pattern to allow for entering failsafe mode.
Also I noticed that 2.4 GHz wifi will use the label mac in OpenWRT (i.e. the same as for LAN), rather than the WAN mac as the stock firmware would do. Is this intended behaviour so that wifi would use the same MAC as LAN?
The version I have seems to load boarddata from the firmware image provided by dlink, not from the art partition. I've got mine mostly working by commenting out the caldata_extract line for this model in /etc/hotplug.d/firmware/11-ath10k-caldata and copying boardData_2_0_QCA9888_5G_Y9582.bin from the vendor firmware to /lib/firmware/ath10k/pre-cal-pci-0000:00:00.0.bin
I spent about 20 minutes reverse engineering qca_ol.ko, but didn't make it far enough to understand what the offset in the structure was for the ID it was mapping in ol_ath_softc_net80211 (this changes based on various compile time flags). Someone who is more familiar with qsdk could probably figure out the image selection fairly quickly.
I'm also not sure what the stance is from openwrt of including boarddata from the vendor directly in the openwrt source tree and what the copyright implications are.
This is from openwrt, I have not actually soldered the UART pins to check from the stock firmware, I only extracted the image from an older variant and looked around the filesystem: