On Wed, Aug 20, 2025 at 12:29 PM Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@xxxxxxxxxxxxxxxx> wrote: > > > > 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. > To clarify: my setup is based on an NXP LS1088A SoC hosting QCN9074 PCIe cards, using the ath11k_pci driver. The cards communicate directly over PCIe, and QRTR/QMI infrastructure is not used or enabled in my system. Therefore, QRTR instance ID clashes are not applicable in my context. Maybe QRTR is only applicable for SoC AHB based integrated WiFi IPs? And I did not use any of the patches [1] and [2]. > 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. > I asked the manufacturers about it and they said that all their pcie wifi cards are with board_id=0xFF and I have to use the provided board-2.bin because of the calibration data, regulatory date, band capability and many other reasons... That's why I had the need to write the patch. > > 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. > Adding DT properties will require patching the driver too to be able to read them. So, I already patched it. Without the need to change the DTS. And as you just said the board id is not programmed... > > 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 > ath11k-bdencoder -i <board-2.bin> and ath11k-bdencoder -e <board-2.bin> did work for the public board-2.bin file and i was able to extract a bin file per board id : bus=pci,qmi-chip-id=0,qmi-board-id=160.bin created size: 131072 bus=pci,qmi-chip-id=0,qmi-board-id=161.bin created size: 131072 bus=pci,qmi-chip-id=0,qmi-board-id=162.bin created size: 131072 bus=pci,qmi-chip-id=0,qmi-board-id=255.bin created size: 131072 bus=pci,qmi-chip-id=0,qmi-board-id=163.bin created size: 131072 bus=pci,qmi-chip-id=0,qmi-board-id=164.bin created size: 131072 but the commands did not work for board-2.bin from WiFi card manufacturers. i noticed that their board-2.bin have the same size as the extracted ones. I tried to run the commands on the extcraced ones and i've got the same error : invalid signature found. This means that their board-2.bin could be integrated to the public board-2.bin. but in my case it is not the solution because of the board_id=0xFF. So, the PCI device address is used to decide which slot will do 2GHz or 5GHz, even if I swap the cards and it's quite useful for me like that. > > 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 > >