Archer C7 V1.0 crashes on boot


Use the Image Builder to make an image without kmod-ath10k (ath10k firmware can also be removed).

It appears you have hardware failure in the 5 GHz radio, you're saying that 15.05 doesn't completely crash but still there's no 5 GHz.

Have you tried booting without the PCI card installed? That may cause ath10k to stop in a graceful way so that booting completes.

The C7V2 is a popular model-- one that is commonly recommended for its excellent OpenWrt compatibility. A lot of other people would have complained if there was something wrong with the releases that it wouldn't work on good hardware.

Of course know for sure what version you have (I think the conclusion has been reached that it is V2, this should be shown on the nameplate sticker) and use the matching build.


The OP's device is a V1 with 8 MB flash and apparently the older, unsupported revision of the 5 GHz wireless hardware.

The confusion around V2 is purely in reference to my units and no fault or question of the OP's


How can I be sure there is a hardware problem? I believe it works fine with TP-link factory firmware (used to), but I can't seem to restore factory firmware to confirm. Know any alternative ways to load firmware other than TFTP?

Later when I have time to pull the cover off again and monkey with this I can try booting w/o the 5GHz radio installed, but I think I like the idea of disabling the driver better (though I'm not sure how much effort it will take for me to get the build stuff set up).

BTW, the hardware is definitely v1.0. I bought it new in 2015, so I'm pretty sure no one changed the sticker or guts :wink:


My apologoies...

No worries! I appreciate you taking the time to read my post and share your thoughts. I need all the help I can get.


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.

ath10k does NOT support older QCA98xx hw1.0 chips found, for example, from these devices:

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).


Hi, I have the same problem with OpenWRT 18.06.2
Can the official image not disable the kmod-ath10k for v1 by default?


Or it there a way to disable the ath10k module in recovery mode?


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.)

Edit: Looks like the Archer C7 v1 doesn't have support for its 5 GHz radio.

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


Perhaps an interrupted upgrade? It takes around 30 seconds to reformat the overlay JFFS after initial boot.


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.


See Post 17, above

If you can't boot into failsafe, TFTP loading would be an alternate option


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 try to figure it out with this doc in background -


ok ok - I removed the card - booted -> now the jffs partition got formatted / prepared.

So I could remove the the module and firmware with

opkg remove ath10k-firmware-qca988x
opkg remove kmod-ath10k

this was for sure the fastest way to bring openwrt to the device.

BUT: why the images can not officially build without the module/firmware - so that it can run out of the box.


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.


Support for QCA9880 v1 (-AR1A) and all QCA988x hw1.0 hardware got completely dropped from ath10k driver:


there were attempts before that and looks like it worked: