ath10k-firmware: QCA4019 hw1.0: Add GL.iNet GL-B1300 specific BDFs

[Sven Eckelmann]

On Mittwoch, 28. März 2018 08:23:43 CEST Sebastian Gottschall wrote:
> correct me if i'm wrong. but isnt the board data stored in flash memory 
> on these devices like on every other router i know using ath10k chipsets?
> this all sounds a little bit curious for me

The BDF is stored either in the board.bin or board-2.bin on routers which use 
ath10k. Similar files (raw BDFs with other names) exist on devices which use 
the QCA driver. These files don't contain the device specific information (see 
my earlier mail for the things which seem to be device specific). So they are 
basically part of the rootfs.

The device specific information are stored somewhere else on the device. This 
can for example be in the ART or on a dedicated EEPROM [1]. The OTP binary 
(running on the wifi chip) is receiving both files from the driver, combining 
them and adjusting some things here and there. The combined memory region is 
then given to the actual wifi firmware.

Yes, this all is rather complicated and I think was introduced with the QCA 
802.11ac Wave2 chips. This especially ended up be a problem when QCA was only 
providing board-ids for its own reference designs. Unfortunately, these board 
ids are used to identify the BDFs in the board-2.bin. So we had to introduce 
an additional, optional information that we can use to differentiate between 
different BDFs which have the same board-id - the so called (qcom,ath10k-
calibration-)variant.

It could now be that you're statement was actual suggesting something else:

* Why don't you just use the information from ART and load it as cal data 
  instead of pre-cal data?

   - The firmware seems to behave differently when we do that. Maybe the
     "additional modifications" are not done by the OTP in that case. 
     Maybe QCA can tell you more about that.
   - But there are also another things which we will discuss in the next
     point.

* Why don't you load the information from ART and use it as pre-cal and BDF?

  - The BDF can also contain other information than the pre-cal data in the 
    sections which are not copied from the pre-cal data. This happens all
    the time during the development but can also happen later. Maybe this was
    the reason why QCA implemented this mechanism. It is for example planned 
    to update the A42 BDFs in some weeks.


Small (cut-down) story at the end and why we need special BDFs. During the 
initial development of the A42 OpenWrt support, the HW manufacturer told us 
that we should use the official QCA BDFs with some QCA internal code (which 
translate to bmi-board-id 16/17). We did that and noticed that the board was 
consuming a sh*tload of power and performed worse than a dead horse. After 
some attempts to communicate the problem and some first incorrect assumptions 
from both sides (but with help from some brave OSS developers), the HW 
manufacturer told us about his "official" BDFs which were actually not looking 
like the QCA files at all but had the same IDs. Reason for that was the 
removal of the QCA reference design non-SoC radio components and the 
replacement with their own design. This is where the story of the 
(qcom,ath10k-calibration-)variant began (for me).

Kind regards,
	Sven

[1] I just use this here as placeholder for "any kind of non-volatile memory
    which is no the main storage"
-------------- 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/20180328/768cd58f/attachment-0001.sig>