QCA4019: calibration files and board files

[Sven Eckelmann]

Thanks for the insights

On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
[...]
> * 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.

    model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1";
    compatible = "qcom,ipq40xx-apdk01.1", "qcom,ipq40xx";

This is actually how the board (unfortunately) still identifies itself
and selects the device tree according to this compatibility string.

> * 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;

It is using IDs which are already available in the board-2.bin. They are the 
same ids which are already used in all the board-2.bin files from Christian 
Lamparter ("bus=ahb,bmi-chip-id=0,bmi-board-id=16" + "bus=ahb,bmi-chip-
id=0,bmi-board-id=17"). They all have the same IDs but different content. This 
was the problem I saw the first time and which confused me a lot.

At 0:ART 0x1000 I saw:

    refDesignId = 0x10, 
    customerId = 0x0, 
    projectId = 0x0, 

At 0:ART 0x5000 I saw:

    refDesignId = 0x11, 
    customerId = 0x0, 
    projectId = 0x0, 

> [17:33:44] <adri> how big is the precal data block?
> [17:33:49] <adri> in bytes?
> [17:36:22] <adri> there, responded


Btw. it looks to me that the calibration data in the 0:ART is exactly 12064 
bytes long. Just because you've asked about it in #ath10k. There is something 
else at 0x9000 which is 12500 bytes long - no idea what this could be.

> [17:36:32] <adri> the TL;DR is - the BMI IDs aren't freaking unique between
> vendors too :(

So I would guess that the manufacturer should have allocated new IDs and set 
them in the pre-cal parts of the ART partition (but only when they use a 
different reference board.bin). But I am a little bit confused that it is 
called refDesignId (which seems to suggest that 16/17 are referencing the 
DK01.1-C1 somehow). And I am also currently unsure if customerId or projectId 
should end up as ATH10K_BMI_CHIP_ID_FROM_OTP (bmi-chip-id). A quick test 
(modifying these values in the ART) showed that they are basically ignored and 
chip-id stayed at 0 (changing the refDesignId seemed to work).

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

Hm, looks like we also have to poke the manufacturer and QCA about this.

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

Yes, this was what I would expect from the OTP data. See below regarding my 
guess regarding the pre-cal 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.

You are talking about (possibly) shaving off the board-2.bin loading? This is 
at least what I would have expected when looking at the QCA988x based boards 
with calibration data in the flash. But this would not explain why Christian 
Lamparter (which seems to have pre-cal data in the flash of the AC58U) had do 
exchange his board-2.bin to get the board working.

Let us ask Raja Mani about it (who implemented it for ath10k [1]). It looks to 
me that point 4 in his commit message is talking about 
ath10k_download_and_run_otp in ath10k_core_pre_cal_config. And the device will 
just copy parts of the pre-calibration data over the board(-2).bin data. So it 
would count as a diff and therefore requires the correct board-2.bin. So each 
board.bin would require an own id (bad idea - really bad idea when we only 
have 1 byte for bmi-board-id and a lot of vendors with their own board.bin 
files).


Kind regards,
	Sven

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?
id=3d9195ea19e4854d7daa11688b01905e244aead9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: art.xz
Type: application/x-xz
Size: 14184 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20170131/e84111eb/attachment-0001.xz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20170131/e84111eb/attachment-0001.sig>