OpenWrt/LEDE Project

Same here.

On another note: i also have an Archer C7 v1.1 with CC (15.05.1) installed. But I can't get the wireless working. There is no wireless option under the network tab in Luci and the "wireless detect/config" command via ssh does nothing. Can you give me any pointers on this if you were able to get it working?

I'm not sure if this is the same problem, but installing the latest release (18.06.1) or snapshot (2018/08/23) appears to brick TP-Link Archer C7 v1.0 as well. See https://forum.openwrt.org/t/archer-c7-v1-0-crashes-on-boot/19784 However, the Dec 2017 snapshot mentioned above boots OK.

I confirm the boot loop problem on 18.06.1. Safe mode works on 18.06.1. I pulled the 5G radio card and the 18.06.1 boots. I speculate that selected radio support could be removed from the build, and it would boot and work correctly with reduced capability. Lets move this to status "confirmed."

Hey,

I also do own a C7 V1.0. But I was able to score a QCA9880 v2 for it,
since the V1.0 does have a standard minipcie slot.

As for the problem. Both Archer C7 V1(.0 and .1) and C7 V2 use the same
boardname identifier "archer-c7". So the 11-ath10k-caldata extraction script in:

target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata

tries to extract the cal-data from the ART partition in the same way.
This works fine on the V2, but on my V1 the ART-partition does not
have any cal-data at offset 20480. It's full of 0xff at that point.
And this is probably why the ath10k driver goes south and crashes,
it doesn't validate what's inside the cal-data files.

The problem is fixed in the upcoming ath79 Archer C7 V1.(0/1) though.

I forked the 18.06.1 branch, dropped the ath10k support from the archer-c7-v1 configuration, and produced an image that disables the 5 GHz radio but otherwise seems to run ok.

I submitted a pull request. My branch is available at

https://github.com/a-mcintosh/openwrt/tree/archer-c7-v1
git@github.com:a-mcintosh/openwrt.git

And this is probably why the ath10k driver goes south and crashes,
it doesn't validate what's inside the cal-data files. 

this is the cause of pci driver crash? is there any revision of ath10k driver and firmware that works, even if it includes patching - based on what i read there is?

this is the cause of pci driver crash? is there any revision of ath10k driver and firmware that works, even if it includes patching - based on what i read there is?

Sort of. The offending upstream patch is:

commit 1a7fecb766c83dace747f42b25bbb544b00a0163
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Sat Jan 24 12:14:48 2015 +0200

    ath10k: reset chip before reading chip_id in probe

It was already bisected and reported earlier (much much earlier).
There probably need a "stronger" incentive for QCA to fix it though.

so, this patch should be reverted? what about firmware version, there is no hw1.0 fw available on any of the git sources. extracted firmware binary from tp-link firmware should work? or should i try use hw2.0 binary?

Look, TP-Link and Qualcomms are Companies. You should talk to their customer services about it too. But be advised: Last time I checked (and got a good answer!): the "recommended" solution was to fork over money for one of the QCA9880 v2 minipcie cards or stick with their original firmware: "Since it's working just _fine_™".

Sure you can do that to save yourself the required hours/days/months/years which would be necessary to get the v1 working. Or you can just ditch the v1 card and go for something else. I would suggest mediatek just to say "Thank you". But what do I know, right?!

I've pushed fix https://github.com/ynezz/openwrt/commit/c53173507461678902324394dee7626fed81c264 from https://github.com/openwrt/openwrt/pull/1349 to master yesterday, there are new snapshot images available today:

* http://downloads.openwrt.org/snapshots/targets/ar71xx/generic/openwrt-ar71xx-generic-archer-c7-v1-squashfs-factory.bin

* http://downloads.openwrt.org/snapshots/targets/ar71xx/generic/openwrt-ar71xx-generic-archer-c7-v1-squashfs-sysupgrade.bin

In order to push the fix to openwrt-18.06 stable branch, I would like to get confirmation, that the reported problem is fixed with the snapshot images mentioned above. It would be nice to get `Tested-by: Real Name email@email.com` from at least one person affected by this bug. Thanks!

just came up with better solution: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg45816.html