From @lucize insight, it isn't a hardware problem, in that it is likely that your hardware is performing as intended. It appears to be that the "public" Linux drivers don't support the 5 GHz chip used in the v1.x revisions of the Archer C7. As a result, OpenWrt can't support it either. The OEM firmware would have drivers from the chip vendor in it, that are almost certainly tied to that older kernel and can't be "updated" by anyone but the chip vendor.
Edit: "Good" news is that, at least here, Archer C7 v2 units can be commonly had on the used market for US $40 or less, if the processing power of that class of device is sufficient for your needs.
Thanks for all of your help. I think part of my confusion has come from trouble finding & interpreting information like that (e.g. lots of pages I was reading were old / archived from before the lede split & merge).
Also, I found that by following this article and using sysupgrade with a "stripped" factory image, I was able to restore the TP-link factory firmware to this device. Perhaps I should have mentioned that the reason I was working with this old device again is that I recently decommissioned it from production and wanted to put it to more casual use, hence returning to OEM stock firmware is an acceptable end-state. I look forward to trying the latest OpenWRT release on newer hardware versions of this device (love that the USB host makes it possible to overlay a much larger file system).
Uninstall the ath10k driver and firmware (CT) and then install the ath10k driver and firmware ("standard"), then reboot. You should be able do it "live", as long as you're not connected over the impacted radio. (Might be able to do it over the ath10k interface, but I would do anything like this with wired access.)
A patch to ./target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts might remove the device from the device tree, so it might not be probed for a driver. You should also be able to "blacklist" the driver, though I've not done that under OpenWrt myself.
yes I was also thinking on opkg remove kmod-ath10k on failsafe mode - but the problem is, that the jffs2 partition is never get formatted and mount_root displays only
jffs2 not ready yet, using temporary tmpfs overlay
no, the problem it, that the device reboots every time (look above, what jacobq has written)
on the normal boot the device crashes and loops forever. Thats why I want to disable the 5GHz wifi module on failsafe mode.
yes - to build a own firmware image is an option - but a very long process (for me, because I am not familiar with it)
and no - failsafe is working - I have already written that I am able to boot into it.
I like the idea, to just disable / remove the module from the original image - on failsafe mode.
The only thing which is needed - to manually format / prepare the jffs partition
I can only guess, as I'm not a dev on the project. As I recall, when the Archer C7 came out in 2013, it looked very exciting to be able to upgrade my 4300, based on reviews. Seeing that it didn't support 5 GHz under OpenWrt and only had 8 MB flash, it wasn't step up, so I didn't buy it. The v2 came out about a year later, fixing several bugs with the v1, providing a then-spacious 16 MB of flash, and 5 GHz support.
My guess is that there aren't many v1s out there among the OpenWrt community, and even fewer represented in the development community. It is already challenging (OK, humanly impossible) to test across the hundreds of devices that OpenWrt supports. Very often, a representative device is tested for a wide range of devices on the same "target". A five-year-old, quickly superseded, obsolete, partially unsupported device wouldn't be on the top of my list to test, even if I had one on hand.
If you feel motivated, you could look into how the build system works and propose a patch to the ath79 target. If you feel less motivated, filing a bug report would be a reasonable step.
I'd suggest to provide a patch/ pull request implementing that change - obviously neither ath10k, nor ath10k-ct can work with the factory installed QCA9880-AR1A wlan card, so there's no reason not to merge a corresponding patch (and for those users who did the only sensible thing of replacing the card with something supported, using opkg to install the necessary packages isn't too much of an inconvenience). Just to be clear, ath10k/ ath10k-ct mustn't crash in the presence of a QCA9880-AR1A radio, but that's an orthogonal issue.
just got one recently, the problem seems to be with pci driver. tried to build trunk from 6 years ago when the development started and got irq fallback to legacy, need to spend some time patching pci driver to operate in msi or msi-x irq mode and see from there where the problem continues. maybe the bootloader is bugged too so i might give a try building pepe2k's u-boot first.