the bdf can also contain region data. so the answer is "both"
the bdf is the basic info. the art overwrites missing fields. but both can also be handled in a single file.
1 Like
yes the art and also the bdf has a version information stored in it
offset 59 in bin file contains the boarddata revision.
807x:
offset 559 , 560, 561 contains the bdf template revision
latest is 7, 2, 3
6018:
same as before but offset 495, 496, 497, latest version 1,4,3
qcn9000:
555, 556, 557 , latest version 4, 2, 0
now it could be that the firmare checks for any of these values and may ignore or accept bdf. this is unclear to me right now
for the firmware version. in worst case the firmware must be used which was used for the bdf file. so the answer is "multiple firmwares".
the latest firmware which is available is 2.12. at code linaro its 2.9
but vendors are using 2.2 - 2.4. which are all incompatible from the bdf with newer firmwares
1 Like
Very interesting discussion going on here.
@BrainSlayer RAX120v2 also has a very similar problem to the Buffalo device mentioned here, with atrocious 5G performance in OWRT compared to "stock NETGEAR" or an SWRT port that's built by paldier.
The only way I've been able to get good results out of it is by shoehorning the cal-data from a Linksys MX4200 (the cal-ahb file).
What kind of parsing error could be happening to cause this issue?
this is risky. from what i read from the specs the rax120 is 4x4 + 8x8 + 8x8 but the mx4200 is 2x2 + 2x2 + 4x4
using a wrong file can fry your radio. i already managed to f*ck up device in that way
the main problem i discovered is that sometimes (every 2 or 3rd boot) the radio just has a weak signal (even on mx4200) and today i discovered that the radio just did not work until i rebootet again. very strange. could be also some sort of missing reset procedure or register. still under investigation
Super interesting info, thanks @BrainSlayer 
So, I see this in two different WXR-6000AX12P IPQ807x devices art partitions (partitions are not identical across devices, even though the devices are the same HW revision):
offset value(s) description
------------------------------------------------
0x03b (59) 0x43 (67) DataRev
0x22f (559) 0x070001 (7.0.1) TemplateVer
I guess this means that the data in this device's art contains boarddata v67 as well as BDF v7.0.1, no? This makes device's art data compatible with the latest FW v2.12?
Side thought: maybe it would be good to start documenting a simple compatibility matrix, i.e. which versions of board data are compatible with which versions of firmware...
If you are willing to share more details about the blob structure headers, I will have some time this summer to work on a simple art/BDF/calibration blob data parser, such as dumping the contents and versions of individual datasets inside. And at some point, it could be improved so it could inject new data into the blobs, for the purpose of making old art data compatible with newer firmware versions. Any thoughts on that?
EDIT:
Interestingly, this is what's found on the latest WXR-5950AX12 / WXR-6000AX12x OEM v3.55 image, published June 12th 2024:
cat fw_version.txt
WLAN.HK.2.3-02932-QCAHKSWPL_SILICONZ-1 v2 BUFFALO_BUILD rev3
cat m3_fw.flist
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/m3_fw.b00
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/m3_fw.b01
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/m3_fw.b02
cat q6_fw.flist
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b00
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b01
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b02
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b03
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b04
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b05
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b07
build/ms/bin/8074.wlanfw.eval_v2/PIL_IMAGES/q6_fw.b08
The OEM image contains two sets of FW and board data, one for WXR-5950AX12, bdwlan_rev1.bin / bdwlan.b210 (identical files) and bdwlan_rev2_sky85772.bin
offset value(s) description
------------------------------------------------
0x03b (59) 0x2F (47) DataRev
0x22f (559) 0x050003 (5.0.3) TemplateVer
and one for WXR-6000AX12x, bdwlan_rev2.bin:
offset value(s) description
------------------------------------------------
0x03b (59) 0x43 (67) DataRev
0x22f (559) 0x070001 (7.0.1) TemplateVer
The WXR-5950AX12 versions matches what's in the @lytr 's table ( firmware_qca-wireless repo), and WXR-6000AX12x version matches what's in my device art partition. I don't know what's in the WXR-5950AX12 art partition, perhaps @musashino could take a look (or share a dump)?
If we know what to change, we can do it using such a tool.
Or maybe we can ask Qualcomm to update the BDF files?
For ipq8074 we have such versions in the firmware_qca-wireless repository:
| bdf | DataRev | TemplateVer |
|---|---|---|
| Arcadyan-AW1000 | 49 | 7.0.1 |
| Asus-RT-AX89X | 65 | 7.0.1 |
| Buffalo-WXR-5950AX12 | 47 | 5.0.3 |
| CMCC-RM2-6 | 32 | 5.0.5 |
| Compex-WPQ873 | 65 | 7.1.3 |
| Dynalink-DL-WRX36 | 52 | 7.0.1 |
| Edgecore-EAP102 | 14 | 7.1.4 |
| Edimax-CAX1800 | 48 | 7.0.1 |
| Linksys-MX4200v1 | 59 | 7.0.1 |
| Linksys-MX4200v2 | 73 | 7.1.5 |
| Linksys-MX5300 | 29 | 5.0.4 |
| Netgear-RAX120v2 | 25 | 5.0.5 |
| Netgear-SXK80 | 29 | 7.0.0 |
| Netgear-WAX218 | 40 | 7.0.0 |
| Netgear-WAX620 | 52 | 7.0.1 |
| Netgear-WAX630 | 41 | 7.0.1 |
| prpl-Haze | 14 | 7.1.4 |
| QNAP-301w | 50 | 7.0.1 |
| Redmi-AX6 | 32 | 5.0.5 |
| Spectrum-SAX1V1K | 50 | 7.0.1 |
| TP-Link-EAP660-HD-v1 | 50 | 7.0.1 |
| Wallys-DR8072V01 | 64 | 7.1.3 |
| Xiaomi-AX3600 | 32 | 5.0.5 |
| Xiaomi-AX9000 | 52 | 7.0.1 |
| Yuncore-AX880 | 49 | 7.0.1 |
| ZBT-Z800AX | 52 | 7.0.1 |
| ZTE-MF269 | 49 | 7.0.1 |
| Zyxel-NBG7815 | 25 | 5.0.5 |
| WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 | 91 | 7.2.0 |
1 Like
i have the text file templates with description and also tools to convert them back to bin files. qcom even has tools to convert them from excel. but anyway. these files are part of the qsdk-networking source. which contains all the firmwares. propertiery drivers. firmware headers for wmi and also the calibration data templates and tools.
of course i would be in trouble if i just share the content of it. but maybe you can find some dump somewhere at the internet
you need to find a file named bdwlan.txt which is part of the archive provided by qcom (qca-networking-2024-spf-12-5*)
this file is different for each chipset and has also structural differences. i hope you can manage to find it somewhere. but i can tell you that i plan to write a binpatch tool too based on the information i have, which updates the bdf template version and fills in missing values. once its done i will also publish it as part of dd-wrt source. but i still need to start with it. the amount of data which must be patches is however not that big. i could also imaging that its just required to update the bdf template version
3 Likes
WXR-5950AX12 (ART):
0x3b (59):0x2d (45)0x22f (555):0x050004 (5.0.4)
dump (addr: 0x1000, len: 0x300)
$ hexdump -n $((0x300)) -s $((0x1000)) -C mtd17_ART.bin
00001000 01 00 04 04 00 00 00 00 00 80 c9 5b 18 04 00 03 |...........[....|
00001010 7f 12 34 56 00 03 7f 12 34 57 00 03 7f 12 34 58 |..4V....4W....4X|
00001020 00 03 7f 12 34 59 00 03 7f 12 34 5a 00 03 7f 12 |....4Y....4Z....|
00001030 34 5b 00 00 00 00 00 00 00 00 10 2d 00 00 00 00 |4[.........-....|
00001040 34 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 |4...............|
00001050 00 00 90 01 00 00 02 01 00 00 00 00 00 00 00 00 |................|
00001060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001070 00 00 00 00 00 00 00 00 00 00 00 00 00 60 00 00 |.............`..|
00001080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001180 12 01 11 01 11 01 11 01 35 01 3e 01 3e 01 3e 01 |........5.>.>.>.|
00001190 3b 01 3a 01 3a 01 3a 01 3f 01 37 01 37 01 37 01 |;.:.:.:.?.7.7.7.|
000011a0 3e 01 37 01 37 01 37 01 39 01 3c 01 3c 01 3c 01 |>.7.7.7.9.<.<.<.|
000011b0 37 01 34 01 34 01 34 01 35 01 32 01 32 01 32 01 |7.4.4.4.5.2.2.2.|
000011c0 10 01 1c 01 1c 01 1c 01 1c 01 3c 01 1c 01 1a 01 |..........<.....|
000011d0 00 00 00 00 00 00 00 00 08 00 12 01 11 01 00 00 |................|
000011e0 00 00 35 01 3e 01 00 00 00 00 3b 01 3a 01 00 00 |..5.>.....;.:...|
000011f0 00 00 3f 01 37 01 00 00 00 00 3e 01 37 01 00 00 |..?.7.....>.7...|
00001200 00 00 39 01 3c 01 00 00 00 00 37 01 34 01 00 00 |..9.<.....7.4...|
00001210 00 00 35 01 32 01 00 00 00 00 00 00 00 00 00 00 |..5.2...........|
00001220 01 00 01 01 06 00 00 00 00 00 00 00 00 00 00 05 |................|
00001230 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001300
1 Like
@BrainSlayer do you have any idea regarding that issue or is that maybe even fixed by what you've fixed in ath11k already?
@BrainSlayer Do you have any idea why many qcn9074 6e is a little more problematic compared to ipq807x? From my experience the qcn9074 version with both 5G and 6E combined on a single band, you are able to toggle between those two, is just a mess.
i can say that i'm currently testing my patches and enhancements on ipq5018, ipq6018 and ipq807x mainly i had problems with wifi firmware crashes at the beginning with mbssid configurations. this has been resolved. and i found also alot of other typos and bugs in ath11k. i can say i dont see such a message currently on my test devices and one of these devices is installed in a public area. but the report doesnt look like its based on the nss code which is very different in alot of parts. so hard to say something about that since i dont have this specific device. im testing on linksys mr5500, mx5500, mr7350, dynalink and asus ax89x
the qcn9074 is really much different from ipq807x. you cannot compare it. unfortunatly i dont have a qcn9074 with 6 ghz enabled. so i can only test it on 5 ghz so far. once a see a router with such a card installed i can work on it. but another point could be the strict regulation rules for 6e. so the 6 ghz channel is selected by a external region database maintained by your government or a institution of it. so the channels available and usable are externally provided. you are not free to use any channel you want. this is named AFC. the fun fact is that this AFC database does not exist yet. (or not that i know). but this seems to be a US / FCC area problem only.
Okay, that's interesting. I was not able to load 5G or 6G with the BDF from stock. It just returned legacy and AX as supported and AFC did not work either. But I believe it need some love like Ansuel did on a previous BDF.
Thanks for the information. 
that sounds like you loaded a invalid bdf file. these cards can also be 2.4 ghz only. but if its a real card. like minipcie you need to consider that the card has a own eeprom on board which stores the calibration data. but the default bdf files provided with the firmwares should then just work from scratch
Yeah, invalid is the keyword. Strange when the BDF comes from the stock firmware and they have no issues. But then again, qca is doing something different when loading/setup the radio I recon.
If you are curious, we had this PR with a lot of testing. https://github.com/openwrt/firmware_qca-wireless/pull/43#issuecomment-2141678868 (output from iw).
But in the end, we agreed on just using a BDF that works with 5G for now.
Since you’re also working on ipq5018 (as am I, will continue when I get back from holidays after a few weeks), do you happen to have the offsets for this chipset too?
yes. but for this chipset i need todo some math first since one file is missing. btw. my work on ipq5018 was based on yours. but i fixed alot of code since there where too many broken things in it (clk code, remoteproc, dts etc.) you can check my kernel 6.6 nss source tree to get all changes. shouldnt be too much. so you just need to merge it and your work is finished. only mx2000 is something i cannot test. mx5500 and mr5500 works
edit:
offset for ipq5018 is 491 latest bdf template version in 2.12 firmwares is 3.4.0
the bdf might come from the stock firmware, but then you need also to use the firmware from the stock firmware. since you are using a different one in openwrt
if i follow your link is see that the stock firmware makes use of 2.5 series firmwares. as mentioned before bdf files from that age will not work with 2.9 what is used in openwrt. from my experience you need at least a bdf from 2.6 or newer
I think the offsets for ipq5018 are: 0x1eb 0x1ec 0x1ed
1 Like