#16589: ATH10k for Tp-Link Archer C7 V2
-----------------------------+-------------------------------------
Reporter: optimizerapp@… | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone: Barrier Breaker (trunk)
Component: packages | Version: Trunk
Resolution: | Keywords:
-----------------------------+-------------------------------------
Comment (by michal.kazior@…):
Replying to [comment:29 anonymous]:
> From what I've read, there are really two options to hack functionality
back in for ath10k;
>
> 1) stop it from bailing out on otp error:
> comment out lines 279-284 of drivers/net/wireless/ath/ath10k/core.c
> add in their place add "return ret;"
> * the actual reason for the failure is not entirely clear, but it
appears that ath10k is trying to look at the pcie card itself for the otp
data, which is actually located in the art partition. This means pretty
much a *complete* failure of otp, but would restore to previous
functionality (bad calibration), which is, realistically, equivalent to
option 2.
This is not entirely correct I believe, see below.
> 2) prevent it from TRYING to run otp:
> Comment out lines 587-589 of the same file.
>
> What is *entirely* unclear (at least to me) is what running otp actually
does, and how it compares to what is apparently the fallback mode of
reading the calibration values from board.bin. In any case, I have been
lead to believe that creating a custom board.bin from the content of the
art partition *should* apply the proper calibration values... however, it
does *NOT* appear that the mac addresses are actually located in the art
partition -- in its place, "00 03 7F 00 00 00"... so... ???
>
> Note that the MAC address from a working openwrt *is* consistent with
the one at the start of board.bin. Maybe code it in manually?
The OTP data on the board doesn't contain board.bin per se. There's not
enough room for one from what I know. It just contains some meta
information saying what board type it is, what mac it has and some
capabilities. The OTP binary itself contains a dozen of board.bin
templates and one is picked based on what is found in the OTP stream on
the board and then it is filled in with other specific bits (e.g. mac
address).
In case of some devices the OTP stream is apparently empty (full of
zeroes) which leads to error 2. In that case the board.bin data provided
from the host is used. The error 2 also prevents mac address from being
set up properly (I infer it's not in the OTP stream but somewhere else as
UART prints have shown these boards know their mac address). That's why
you end up seeing the mac from board.bin template now.
--
Ticket URL: <https://dev.openwrt.org/ticket/16589#comment:30>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
