You can question all you want, this is a public forum after all, but you keep repeating the same thing over and over like "Its almost the same", that means nothing except that the basic structure is the same, meaning the format being used to encode the humanly readable format into a binary one is the same for caldata and BDF.
Since most of these values are u8, and some u16 and u32 you can see how its 96.5% translates into its rather different.
And yeah, the answer that the exact field values are under NDA is correct, all of the tooling to convert to humanly readable text and back, along with some basic descriptions are under NDA from QCA and nobody can share those even if they have them.
Ideally, somebody would implement such a mechanism for on-the-fly BDF reload according to exact region but the same was true even for ath10k and there was no movement on it.
Usually ETSI or FCC BDF-s are used as they cover most of the world when it comes to compliance as a lot of countries follow FCC or ETSI rules.
With bdwlan_rev1.bin I get exactly the same symptoms as with ipq-wifi-buffalo_wxr-5950ax12, broken 5G radio RX, clients can only connects from ~20cm away, signal is a total disaster.
With bdwlan_rev2.bin everything just works, great connection speeds regardless of the clients distance. Works as good as "fake news" BDF found in device's ART
I dont know how many times I need to repeat, ART does not contain BDF-s, it only contains caldata, I have 10 or so ipq807x and ipq60xx and none ships BDF in ART.
You discovered the same it seems, if there is a newer BDF it can be submitted as update.
Yeah, even though bdwlan_rev2.bin works on my WXR-6000AX12P, I have a feeling that it may fail on when tested against WXR-5950AX12. @musashino can you please test it on your device?
Since I can not verify the binary data that I can not possibly understand myself, attached here are the screenshots of the actual diff between the OAM bdwlan_rev2.bin I've just confirmed working and the data found in ART mtd, just for reference. Other than header checksum & what's on the screenshots, the rest of the data is identical.
Again, I apologize in advance, no intent to annoy anyone here with false claims, check it if you care or just ignore it if you don't. I just need a closure m(_ _)m
Did you see and understand @musashino's post here? The OEM firmware uses rev1 for the WXR-5950AX12 and rev2 for the WXR-6000AX12P. And it specifies where the caldata comes from (mtd) and where the BDF comes from (file system).
Obviously, the most significant part of the diff is on the screenshots. The only thing not on the screenshots is the header checksum, just 2 or 3 bytes.
the bdf and art is exactly the same format and structural content. the bdf you are talking about is just the basic generic data for the device, but the same data is reflected by the art caldata in exactly the same format but with vendor and region specific settings like power settings and device flags. using board-2.bin makes only sense if art is not available because using a wrong boarddata (2.4 for 5 ghz etc) will fry the device. the board-2.bin file is only present in ath11k and is not used by the qcom propertiery driver. the original driver uses only the art data or hardcoded files by the vendor. the generic board files provided by qcom together with the firmware files are only made for reference designs
there is only one problematic issue. the board data format may be different depending on the firmware version. so a art or board file made for firmware 2.4 in the vendor firmware may not be compatible with 2.9
The propriatery driver also uses BDF-s, they are just not wrapped into the API-2 aka board-2.bin and like you said unfortunately they are often incompatible with the newer FW
its possible to convert them. qca provided descriptions of the format. its just little bit weired provided as plain text files. the format itself is identical over all firmwares but they added new fields which are reserved before. the default values for these fields are provided too. so a tool must be written which replaces these undefined fields with the new default values usually. i thought already about that. the point is the current bdf files provided by openwrt are provided based on any undefined firmware. (or am i wrong?).
i did some experiments just today. the whole bdf collection in openwrt cannot be used. best way is to use the provided board-2.bin's from the upstream repository. if they are at least compatible with 2.6 firmware series, they will work with up to 2.12 too. but if its lower (like 2.2 - 2.5 which is common for most factory bdf's) they simply will fail to work and result in strange behaviour
Thanks for the insight, I'm glad I ain't gone completely insane.
So "BDF" is a generic device data, not containing any board revision or region specific calibration?
And then what is in the art (at least for these newer buffalo devices) is extending "BDF" with calibration data specific for a board & antennae design, as well as the region?
Interesting. Are these "BDF" & factory art blobs versioned in any way, so that one can figure out which FW version they would work against? You said in previous post that QCA provided description for the format, any source?
Also, any ongoing discussions about which ath11k firmware version would end up in the next OWRT release? (cc @robimarko)
both. and it has nothing todo with the tool you posted. and i know the format. the problem is that its based on nda related material i have from qcom. converting here means that the older bdf and calibration data has missing values in it for newer firmwares. these missing values need to be adjusted and filled in. without doing that effects like weak signal, bad noise values etc. may happen. i was able also to reproduce such behaviour on one of my devices. using the factory bdf file it simply did not work and wasnt able to establish any connection. using a modified recent bdf it works immediatly.
