On 14/10/2021 14:01, Robert Marko wrote:
On Thu, 14 Oct 2021 at 13:54, Christian Lamparter <chunkeey@xxxxxxxxx> wrote:
On 10/10/2021 00:17, Robert Marko wrote:
Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
BDF-s to be extracted from the device storage instead of shipping packaged
API 2 BDF-s.
This is required as MikroTik has started shipping boards that require BDF-s
to be updated, as otherwise their WLAN performance really suffers.
This is however impossible as the devices that require this are release
under the same revision and its not possible to differentiate them from
devices using the older BDF-s.
In OpenWrt we are extracting the calibration data during runtime and we are
able to extract the BDF-s in the same manner, however we cannot package the
BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
the fly.
This is an issue as the ath10k driver explicitly looks only for the
board.bin file and not for something like board-bus-device.bin like it does
for pre-cal data.
Due to this we have no way of providing correct BDF-s on the fly, so lets
extend the ath10k driver to first look for BDF-s in the
board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin
If that fails, look for the default board file name as defined previously.
Signed-off-by: Robert Marko <robimarko@xxxxxxxxx>
---
As mentioned in Robert's OpenWrt Pull request:
https://github.com/openwrt/openwrt/pull/4679
It looks like the data comes from an mtd-partition parser.
So the board data takes an extra detour through userspace
for this.
Maybe it would be great, if that BDF (and likewise pre-cal)
files could be fetched via an nvmem-consumer there?
(Kalle: like the ath9k-nvmem patches)
Christian, in this case, NVMEM wont work as this is not just read from
an MTD device, it first needs to be parsed from the MikroTik TLV, and
then decompressed as they use LZO with RLE to compress the caldata
and BDF-s.
For more context here (it's unrelated to the patch):
There is more custom code than just the mtd splitter.
I do fear that this could be turning into a dreaded "separation between
mechanism vs policy"-proxy discussion with that in-kernel LZOR
decompressor/extractor and the way that the board-data then has be
rerouted through user-space back to ath10k.
---
As for the proposed feature: Yeah, back in 2017/2018-ish, I would have
really loved to have this "load separate board-1 based on device-location".
Instead the QCA4019's board-2.bin is now bigger than the device's
firmware itself. From what I can see, there are also more outstanding
board-2.bin merge requests too, though some those are updates.
Cheers,
Christian
