- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Base system
- Assigned To No-one
- Operating System All
- Severity High
- Priority Very Low
- Reported Version openwrt-18.06
- Due in Version Undecided
-
Due Date
Undecided
- Private
Attached to Project: OpenWrt/LEDE Project
Opened by zless - 06.08.2018
Last edited by Petr Štetiar - 05.04.2019
Opened by zless - 06.08.2018
Last edited by Petr Štetiar - 05.04.2019
FS#1743 - Archer C7 v1.1 is soft bricked with the 18.06 release
Supply the following if possible:
- Device problem occurs on: TP-Link Archer C7 v1.1
- Software versions of OpenWrt/LEDE release, packages, etc.
I tested this on the release version 18.06 and yesterday’s snapshot. (archer-c7-v1-squashfs-factory.bin)
- Steps to reproduce
Install OpenWRT 18.06 from the SSH command line (an older version is already running OK). The device will enter into a reboot loop.
I managed to enter safe mode and downgrade to an archived older version from December 2017 (https://archive.openwrt.org/snapshots/trunk/ar71xx/generic/openwrt-ar71xx-generic-archer-c7-v1-squashfs-factory.bin)
Back in October 2017 I also tried the then stable release from LEDE and it had the same issue (reboot loop).
Closed by Petr Štetiar
05.04.2019 19:43
Reason for closing: Fixed
Additional comments about closing:
05.04.2019 19:43
Reason for closing: Fixed
Additional comments about closing:
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
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:
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