QCA4019: calibration files and board files

[Adrian Chadd]

[snip]

hi!

ok, so here's what's going on behind the scenes.

* I can't talk about what Christian did, where he got the board data
from, etc, etc. You mentioned a DK style board, but didn't say which.
* For example, the ath10k in the "official" QSDK software reference
platform doesn't work out of the box on DK07, because the BMI IDs
aren't in the default IPQ4017 config (eg DK07 can be 2G/5G/pcie or
5G/5G/pcie, depending!)
* .. and the cascade/besra NICs that ship in the DK07 reference boards
also don't exist in the ath10k board-2.bin file because again they're
boards whose BMI IDs aren't shipped;
* .. so, after chatting with QCA as a customer, I discovered which
board.bin template files I needed from their firmware release to match
the boards that we have, and I built custom board-2.bin files with the
relevant stuff, and it works.

Each board data is custom for the board layout / part selection - it's
a template that is used during calibration. The data in OTP is just a
diff against the board template  (board.bin / board-2.bin.) The data
in /flash/ on ath9k is the whole calibration block; but in OTP for
ath9k is just the diff against a template. I don't recall what
happened for ath10k and it's too early for me (read: not enough
coffee) to read the source to see if the ath10k board data is the
same.

If people aren't using unique BMI IDs (which is another question we
have for QCA) then it's possible you don't have enough information to
"know" which board data to use, so it has to be overridden by a custom
package. We do this at work for our own boards as well - they're
sufficiently different to a reference board that indeed we need to
"know".

Now, the reason for pre-loading the calibration data is because it's
needed early in the boot process so the firmware/driver has some idea
of what the hardware is.

So, the driver steps should be:

* If you have a pre-calibration file, you load that in before you kick
the firmware too hard;
* then you read the calibration data /back/ - then the normal firmware
process will fetch the board ID;
* then it loads the board-2.bin matching the board/BMI ID, then
* starts things normally.

Now, I forget if the pre-cal data (and say, data in flash versus data
in OTP) is the whole thing or a diff against the board data. I'd have
to triple-check. The OTP data is certainly just a diff against the
board data.

It's possible they could shave off some of these steps if you have
pre-cal data, but I bet it's done like this to minimise the amount of
special casing going on. Each step may have a special case, but once
you get to the "fetch board ID" step it should continue along
correctly.

HTH,



-adrian