| Message ID | 5549F827.1010809@dd-wrt.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 6 May 2015 at 13:16, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote: > Am 06.05.2015 um 13:06 schrieb Michal Kazior: >> >> On 6 May 2015 at 12:39, Sebastian Gottschall <s.gottschall@dd-wrt.com> >> wrote: >>> >>> Hello >> >> Hi, >> >> >>> I recently stumbled across a problem in ath10k. while developing on >>> embedded >>> wireless routers >>> i found a device which uses a ar988x card using a card embedded board >>> eeprom. the problem is there is no way to override >>> the cards hardware/mac address, which is required on that device since it >>> uses just a fake mac on that board data. >> >> If device contains valid EEPROM data then both calibration and mac >> address is read using OTP. In that case a mere fake board template >> binary is used by the driver (the default board.bin). > > the problem is that the board.bin is never used. i modified the board.bin to > change the mac address, but it shows no effect Hmm.. I guess this implies OTP has overwritten the board template provided by ath10k - which is normal. This means there's at least some valid EEPROM data on the device. >> If device contains no valid EEPROM, which is the case for many routers >> out in the wild e.g. TP-Link Archer C5/C7, you must provide a complete >> board data. On routers this data is often stored on NAND/Flash >> partitions. OpenWRT does handle this and extracts calibration data >> file. If you fail to provide that and attempt to use the default >> board.bin you'll get hardcoded mac and Tx/Rx performance will be very >> poor most likely. > > i'm aware of that. i handle that correct for such devices. > but the dlink DIR862 and DIR866 using full equiped ar988x cards with valid > eeprom >> >> >> If ath10k assigns 00:03:07:12:34:56 mac address to the interface then >> you've most likely provided a fake board template and the device >> doesn't have a valid EEPROM data. Are you using skip_otp module >> parameter by any chance or other hacks/custom patches on ath10k? > > i just use the openwrt patch which allows to override invalid otp data using > the board.bin. > this works for device likes the archer c7. > but board.bin is not used for > valid otp data. It is used. The mere fact that it's overwritten is a proof of that. OTP by design does overwrite provided board data in device memory since it uses it only as a template. The template mac may suggest that calibration data isn't complete and mac address is stored out-of-band somewhere else - no idea where though. Another problem may be OTP program itself. What firmware did you try to run with ath10k and the device you have? 10.1? 10.2? 10.2.4? Perhaps OTP doesn't recognize the particular device board sold in these D-Link routers. You could try extracting qca988x firmware from the proprietary router software blob and use that with ath10k to see if it's OTP/firmware related problem. You can check other threads on this mailing list to see how to assemble ath10k firmware blobs. Micha?
Am 06.05.2015 um 13:32 schrieb Michal Kazior: > On 6 May 2015 at 13:16, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote: >> Am 06.05.2015 um 13:06 schrieb Michal Kazior: >>> On 6 May 2015 at 12:39, Sebastian Gottschall <s.gottschall@dd-wrt.com> >>> wrote: >>>> Hello >>> Hi, >>> >>> >>>> I recently stumbled across a problem in ath10k. while developing on >>>> embedded >>>> wireless routers >>>> i found a device which uses a ar988x card using a card embedded board >>>> eeprom. the problem is there is no way to override >>>> the cards hardware/mac address, which is required on that device since it >>>> uses just a fake mac on that board data. >>> If device contains valid EEPROM data then both calibration and mac >>> address is read using OTP. In that case a mere fake board template >>> binary is used by the driver (the default board.bin). >> the problem is that the board.bin is never used. i modified the board.bin to >> change the mac address, but it shows no effect > Hmm.. I guess this implies OTP has overwritten the board template > provided by ath10k - which is normal. This means there's at least some > valid EEPROM data on the device. thats what i said. in original LSDK there is a function to change the hw address. but the ath10k firmware doesnt seem to provide such a command beside this a setting for changing ack timing would be usefull which is possible with lsdk as well. otherwise long range device (i got some request for porting such devices) are not able to establish any connection. the ack timing register is combined with cts and rts timing within the card own registers (i found that out while reviewing some old firmware sourcecode) > > >>> If device contains no valid EEPROM, which is the case for many routers >>> out in the wild e.g. TP-Link Archer C5/C7, you must provide a complete >>> board data. On routers this data is often stored on NAND/Flash >>> partitions. OpenWRT does handle this and extracts calibration data >>> file. If you fail to provide that and attempt to use the default >>> board.bin you'll get hardcoded mac and Tx/Rx performance will be very >>> poor most likely. >> i'm aware of that. i handle that correct for such devices. >> but the dlink DIR862 and DIR866 using full equiped ar988x cards with valid >> eeprom >>> >>> If ath10k assigns 00:03:07:12:34:56 mac address to the interface then >>> you've most likely provided a fake board template and the device >>> doesn't have a valid EEPROM data. Are you using skip_otp module >>> parameter by any chance or other hacks/custom patches on ath10k? >> i just use the openwrt patch which allows to override invalid otp data using >> the board.bin. >> this works for device likes the archer c7. >> but board.bin is not used for >> valid otp data. > It is used. The mere fact that it's overwritten is a proof of that. > OTP by design does overwrite provided board data in device memory > since it uses it only as a template. > > The template mac may suggest that calibration data isn't complete and > mac address is stored out-of-band somewhere else - no idea where > though. > > Another problem may be OTP program itself. What firmware did you try > to run with ath10k and the device you have? 10.1? 10.2? 10.2.4? > Perhaps OTP doesn't recognize the particular device board sold in > these D-Link routers. latest firmware-5.bin so 10.2.4 > > You could try extracting qca988x firmware from the proprietary router > software blob and use that with ath10k to see if it's OTP/firmware > related problem. You can check other threads on this mailing list to > see how to assemble ath10k firmware blobs. i may try this, but i dont know if its compatible with ath10k. it has no the same format as ath10k, so i need to regenerate something like that and the api which is used, is unknown > > > Micha? >
--- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -387,9 +387,14 @@ static int ath10k_download_and_run_otp(s ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot otp execute result %d\n", result); - if (!skip_otp && result != 0) { - ath10k_err(ar, "otp calibration failed: %d", result); - return -EINVAL; + if (!skip_otp) { + if (result == 2) { + ath10k_warn(ar, "otp stream is empty, using board.bin contents"); + return 0; + } else if (result != 0) { + ath10k_err(ar, "otp calibration failed: %d", result); + return -EINVAL; + }