Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1743 - Archer C7 v1.1 is soft bricked with the 18.06 release #7079

Closed
openwrt-bot opened this issue Aug 6, 2018 · 11 comments
Closed

FS#1743 - Archer C7 v1.1 is soft bricked with the 18.06 release #7079

openwrt-bot opened this issue Aug 6, 2018 · 11 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Aug 6, 2018

zless:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 21, 2018

orkun1675:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 23, 2018

jacobq:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 28, 2018

a-mcintosh:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 29, 2018

chunkeey:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 5, 2018

a-mcintosh:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2019

psyborg:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2019

chunkeey:

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 [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a7fecb766c83dace747f42b25bbb544b00a0163|patch]] is:

commit 1a7fecb766c83dace747f42b25bbb544b00a0163 Author: Michal Kazior 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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2019

psyborg:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2019

chunkeey:

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(tm)".

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?!

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 21, 2019

ynezz:

I've pushed fix ynezz@c531735 from #1349 to master yesterday, there are new snapshot images available today:

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!

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 22, 2019

psyborg:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant