This is from openwrt, I have not actually soldered the UART pins to check from the stock firmware, I only extracted the image from an older variant and looked around the filesystem:
Ya, as you can see the mtd9 partition is filled with ff ff ff ff ff only....
The layout scheme of openwrt is pre-defined, so we need to get the partition layout of the original firmware in order to find out where the calibration (art) partition is.
Dumping /dev/mtd10 with openwrt booted yields 128k of data (0xfe0000-0x1000000), and what looks like the magic I see for the first 2 bytes of other art partitions at 0x5000 I have inspected:
However, the driver doesn't load when I try to use that for pre-cal-pci-0000:00:00.0.bin when I patched 11-ath10k-caldata to read from there, nor does it load if I indicate that as cal-pci-0000:00:00.0.bin.
Another interesting note:
mtd9:0x1000 looks like ath9 data as is mtd10:0x11000
my router also shows:
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)
but my art partition starts at 0xfd0000 , so i dont think the bootargs actually corresponds to the partition layout
I think I screwed up the first time I tried it and left some files in /lib/firmware from other attempts, after clearing everything out and using that patch, it does function properly, the radio signal and link characteristics do not seem to work quite as well as with boardData_2_0_QCA9888_5G_Y9582.bin:
mtd:0xff5000:
client signal @ 2m distance: -54 dBm
boardData_2_0_QCA9888_5G_Y9582.bin:
client signal @ 2m distance: -42 dBm
The other thing that puzzles me is that I don't see any bash scripting in the stock firmware trying to extract that range from the mtd, however it is likely buried in the qsdk driver they are using in binary form.
The closed source driver in the stock firmware and read the art partition directly, so it does not need to extract the data from mtd.
If you can make sure this is working, can you open a pull request? I am not sure how OpenWrt maintainers are going to deal with this though. We need some scripts to select where to load the art data. (without breaking the working wifi on some of the DIR842)
Personally I think the better approach would be to go against the decree in https://openwrt.org/docs/guide-developer/defining-firmware-partitions and instead use the flash layout specified in the u-boot env to maximize compatibility, however we would need to collect a sufficient set of u-boot env samples to determine that we never accidentally overwrite art.
Can you post the u-boot env boot flags from your c1 device?
Interesting. I would be curious to see what is at 0xff0000, 0xff1000 and 0xff5000 for comparison.
I haven’t found anywhere in flash that contains a model number or serial that the stock firmware could be using to detect. They use a single image for all 3 models so I would like to figure out how the vendor expects this to work with their own firmware.
It would also be interesting to compare serial/model numbers over PM. Mine at least has a second sticker covering the stock label. I’ll dig it out of the closet tonight to take a look.