On 8/20/2025 2:03 PM, Balsam Chihi wrote:
On Wed, Aug 20, 2025 at 10:03 AM Vasanthakumar Thiagarajan
<quic_vthiagar@xxxxxxxxxxx> wrote:
On 8/19/2025 2:20 PM, Balsam Chihi wrote:
Hello,
I Have a question on the same subject but not related to the bug.
I have many identical PCIe WiFi cards on the system and I need to load
a different board-2.bin on each one (1 adapter per frequency band).
So you are using multiple pcie devices at the same time in a system
with ath11k? Wondering if you are using any private patches to address
QRTR instance id clash issue [1][2].
I'm not aware of any issue of QRTR instance id clash.
Then better take [1] for proper functioning with multiple pcie devices.
The other one requires a new firmware feature flag.
Is there any kernel built-in solution for that?
I could not find any, so I had to create a patch that loads a
different board-2.bin for each card based on the pci device address.
Current board data selection for QCN from board-2.bin is based on pci+chip-id+board-id
combination, not based on pci device address. You can find the chip-id and board-id in the
debug during QMI boot stage. Then you can use ath11k-bdencoder [3] to encode those
board data binaries into board-2.bin. This way you can package all the needed board
specific binaries for a hardware into a single board-2.bin. Ath11k board data file
load logic uses chip-id and board-id to download the right board data for the given
hardware variant.
I have multiple PCIe WiFi adapters based on QCN9074 from different
manufacturers.
The problem is that I could not distinguish between them at the system level.
All have 0xFF as board ID.
Hmmm, ideally it should have a valid board-id other than 0xff.
So, when loading the default board-2.bin they behave the same way.
When I contacted the manufacturers they sent me board-2.bin for each
configuration :
2x2, 4x4, 2.4Ghz, 5GHz... (maybe calibration data and more?)
The default board-2.bin for board ID 0xFF does not support all bands.
My requirement is to have 2.4Ghz band on slot 1 and 5Ghz band on slot 2.
I can not think of the cleaner solution when board-id is not programmed.
If you can make changes to ath11k driver and your system has device-tree,
may be you can add a hack to pass board-id/chip-id through dt (new dt properties)
to driver. In any case, you need to encode all your board data binaries into
one board-2.bin to enable auto download of the right board data into firmware.
So the patch reads from rootfs a text file named with the pci device address,
the path to the custom board-2.bin.
P.S. : qca-swiss-army-knife did not succeed in decoding the custom
board-2.bin files.
I that encoded binary with TLV for each board data or it is board data
binary itself. You can run ath11k-bdencoder -i <board-2.bin> to
get the information about the board-2.bin. You can use ath11k-bdencoder -e <board-2.bin>
to extract the board binaries and json used to package the board-2.bin
Vasanth
[1] https://patchwork.kernel.org/project/linux-wireless/list/?series=692423&state=*&order=date
[2] https://lore.kernel.org/all/20230111170033.32454-1-kvalo@xxxxxxxxxx/
[3]
https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath11k/ath11k-bdencoder
