So, update on today.
I fixed 2.4Ghz (wrong cal data) and it works great.
5Ghz on the other hand... it works, but I get almost no range.
As if the antennas aren't there.
Could be a hardware issue... but I'm not sure.
I did try the normal ath10k firmware, but there was no change.
As You've got multiply board files, before we go into details, check vendor scripts in /lib/wifi dir. These load particular board file on specific circumstances (i.e. different country), it might influence Your decision to pack single board file or multiply ones.
In OpenWrt firmware there's upstream board-2.bin, for simplicity download it from here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/ath10k/QCA9984/hw1.0/board-2.bin. After extracting it with ath10k-bdencoder You'll get multiply board files and board-2.json file. Now compare the *.bin board files checksum with the vendor ones, You'll see at least two matching with vendor 2G board files. That would explain why 2.4GHz WiFi works fine.
Now lets go back to providing the right board files for the device. After opening board-2.json file, You'll see the structure of names and data pairs. Trim that file to Your needs, important is that the names record has a proper name: bus this one usually has pci bmi-chip-id this one usually is 0 bmi-board-id this one varies, usually it's a pcie slot number, so 0 or 1 variant is a string which will let the loader know which board file to load (no spaces), for example: Nokia-Airscale-WI4A-AC440i
In data record point to the actual board file You want to pack.
Supply the json file to ath10k-bdencoder to pack the board files. Now check the OpenWrt commit from my previous post how to integrate it in ipq-wifi package. Remember to specify also proper variant in dts.
Thank you.
I did already compare hashes yesterday and the ones loaded by the OEM firmware doesn't match any known hash.
But, the board-2.bin (from OpenWRT) does match the following files: 9ec32463f7a623ecc4624ba159594d1b ./lib/firmware/QCA9984/hw.1/boardData_QCA9984_CUS240_2G_v1_004.bin 4399f3b52c400e81723b463ae082be74 ./lib/firmware/QCA9984/hw.1/boardData_QCA9984_CUS240_2G_3x3_v1_010.bin
Looking at the fw_checksums provided by the driver, the 2.4Ghz radio loads the data for board-id=2,
(9ebfe300dfb8959fb76b15659935e7aa), should I still use the OEM board data for that radio, despite it being happy with that one?
Looking at the fw_checksums provided by the driver, the 2.4Ghz radio loads the data for board-id=2,
(9ebfe300dfb8959fb76b15659935e7aa), should I still use the OEM board data for that radio, despite it being happy with that one?
Loading the OEM board data is preferred, since that was possibly used for certification. Check vendor /lib/wifi scripts, maybe You can deduce from there what board data was loaded depending on circumstances. Some time ago I did device which loaded different file, depending on certification institution (/lib/wifi/darkmok.sh vendor script), and I packed all of them, but in dts, used the one covering most countries (https://git.openwrt.org/47306d47ef18).
I might spend some time trying to get it working, but it's probably not worth the effort.
The OEM firmware had the SD card nodes disabled, so it was probably never meant to work.
Plus it's locked behind a hollow Torx security bit.
Yeah, the vendor dts is just a copy of the default dts in regards to the SD card portion.
I tried different settings but everything just errors out.
So, for now I'm giving up on the SD card reader.