I dont know this is progress or not but i managed to "fool" the bootloader into booting by appending the first 40(h) bytes of the firmware to all 00 00 00....
But doing so messed up the partition scheme and openwrt cant detect rootfs anymore, so i would assume that this is not an ideal solution
Thanks, I tried to add | append-uImage-fakehdr firmware | before | append-kernel , It cant boot as the header checksum is wrong, I think generating the proper uImage header is the only way now?
I used mkimage utilities to generate the uImage header for ther kernel, but for now it doesn't seems to be working, I am figuring out what the problem is.
Image Name: Plsss work
Created: 2019-07-15 7:00:43 UTC
Image Type: MIPS Linux Multi-File Image (lzma compressed)
Data Size: 1834920 Bytes = 1.7 MB
Load Address: 80060000
Entry Point: 80060000
Contents:
Image 0: 1834912 Bytes = 1.7 MB
Verifying Checksum at 0x9f080040 ...OK
Uncompressing Multi-File Image ... Too big uncompressed streamLZMA ERROR 1 - must RESET board to recover
Thanks In advanced
Unfortunately I cant get the ac wifi mac to set correctly,
I can see the correct mac is patched in pre-cal-pci-0000:00:00.0.bin , but the mac address used is not the correct one, but it is not random at every boot.
Maybe you need to use mtd_get_mac_text instead.
Thanks but the result is the same, I can see the correct MAC in hex format in the precal file, but the mac used is still wrong
Maybe it only looks correct. It's a common mistake with d-link. see th difference between mtd_get_mac_ascii and mtd_get_max_text. I wrote the second one.
Just realized I need to delete pre-cal-pci-0000:00:00.0.bin to make it generate a new one, I found something interesting:
with mtd_get_mac_text , the mac address in the pre-cal file is wrong, but it is the same as the mac inside wifi1.caldata I pulled from the original Dlink firmware.
It is not wrong, It is in different format. Note that mtd_get_mac_text() doesn't use $key parameter. Only $offset. All depends on which format the mac is initially stored.
Thanks! I got it
turns out that i should use
ath10kcal_patch_mac_crc
instead of
ath10kcal_patch_mac
That was obvious initially 
Haha, this is all because I didnt remove pre-cal-pci-0000:00:00.0.bin after I changed the 11-ath10k-caldata file, so I was very confused about why the mac address in the pre-cal file didnt change no matter how i edit the 11-ath10k-caldata file.
Thanks for your help!
As you can see this script runs only when there is no extrcted file in /lib/firmware.
Ya, I should read the script more carefully instead of blindly changing things and wasting 2 hours....
These things are tough when you do it the first time. That's why I suggsted to ask for help from people who use all these scripts more frequently.
Once you get it running, it would be worthwhile to check if there is a board-specific board-2.bin file in the OEM firmware. This first popped up with the ipq40xx platform and I ran into it with the QCA9888 on the EA8300. No rush, but worth checking once you get to the point of considering submitting your work upstream. Once you get to that point, I can check through my notes and my EA8300 archive on how to determine of your board is already supported by the upstream board-2.bin file.
Thanks!
Here are the files I found in the original firmware, is it boardData_2_0xxxxxxx.bin ?
ls /firmware/QCA9888/hw.2
athwlan.bin
boarddata_0.bin
boardData_2_0_QCA9888_5G_Y9484.bin
boardData_2_0_QCA9888_5G_Y9690.bin
boardData_2_0_QCA9888_5G_YA841.bin
utf.bin
athwlan.codeswap.bin
boarddata_1.bin
boardData_2_0_QCA9888_5G_Y9582.bin
boardData_2_0_QCA9888_5G_YA105.bin
otp.bin
utf.codeswap.bin
I am now almost ready, just held back by the bootm 9f080000 issue, struggling to fix it.
You'll need to check which of those are actually used by the OEM firmware (dmesg) and then transform them into a form OpenWrt uses (board-2.bin). This addition needs to be submitted upstream (linux-firmware.git).
Thanks!
I found it
wifi1: Selecting board data file name boardData_2_0_QCA9888_5G_Y9582.bin
[ 27.290000] ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=QCA9888/hw.2/boardData_2_0_QCA9888_5G_Y9582.bin
[ 27.310000] ol_transfer_bin_file 4506: downloading file 3, Download data len 12064
So it is Y9582.bin, I will look into how to transform it.
The key to the "magic values" will look something like
[ 13.065801] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:23 crc32 b050e9d6
as I recall. the bmi_id is what you'd need to check and confirm.
The reference that slh gave is the tooling for wrapping and unwrapping the "raw" content of the files.
You can check that those are the "right" files by manually installing them on your device, their content replacing board-2.bin for the QCA9888. It's worth a signal-level / throughput check against the generic as well.
When the time comes, openwrt/package/firmware/ipq-wifi/ is where the "interim hack" goes (ignore the name, it's a bit of legacy at this point).