Problems loading ath9k (ar93xx) calibration data

Problems loading ath9k (ar93xx) calibration data

[Kristian Evensen]

Hello,

I am currently trying to bring up a ramips-based board with a built-in
wifi based on ar93xx. The wifi does not have an eeprom, instead the
calibration data is stored on the flash storage. I have set the
"qca,no-eeprom" option in the node in the dts, extracted the
calibration data and stored it in a file with the correct name in
/lib/firmware. The content of calibration data file can be seen here:
https://pastebin.com/zF6cRetV

I can see that the firmware file is loaded when I boot my board, but
initialization of the wifi device fails. The error message I get is:

[   12.314349] bus=0x1, slot = 0x0, irq=0xff
[   12.318839] ath9k 0000:01:00.0: Direct firmware load for
ath9k-eeprom-pci-0000:01:00.0.bin failed with error -2
[   12.328932] ath9k 0000:01:00.0: Falling back to user helper
[   12.424131] ath: phy0: both bands are disabled
[   12.428713] ath: phy0: Unable to initialize hardware;
initialization status: -22
[   12.436127] ath9k 0000:01:00.0: Failed to initialize device
[   12.441890] ath9k: probe of 0000:01:00.0 failed with error -22

When looking into the content of the eeprom-file, I see that the byte
matching opFlags has the value 0x08. Based on my understanding of the
driver, the only valid values are 0x1, 0x2 and 0x3.

Considering that the next byte has the value 0x1, I suspect the issue
might be related to endianess. However, I haven't found a way to
trigger an endianess-conversion when the calibration data is read for
file. Is there something I am missing or is this not supported?

Could endianess be an explanation for the error I am seeing, or are
there other things in the calibration data the looks like it could
cause problems as well?

Thanks in advance for any help.

BR,
Kristian

Re: Problems loading ath9k (ar93xx) calibration data

[Kristian Evensen]

Hello again,

On Sun, Jul 21, 2019 at 3:10 PM Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Considering that the next byte has the value 0x1, I suspect the issue
> might be related to endianess. However, I haven't found a way to
> trigger an endianess-conversion when the calibration data is read for
> file. Is there something I am missing or is this not supported?
>
> Could endianess be an explanation for the error I am seeing, or are
> there other things in the calibration data the looks like it could
> cause problems as well?

I took a second look at the ath9k-driver and see that 0x1 is the value
of AR5416_OPFLAGS_11A, which sets the CAP_5GHz flag. My card is only
2.4 GHz, so then I guess the endianess-theory was wrong.

BR,
Kristian