WiFi calibration data for ath10k

Hi, I just had a problem and managed to solve it by putting together information found in several threads on the forum, mainly
Now, I have an idea for an improvement and I'd like to know if this would work.

After installing OpenWrt 19.07.5 on an Asus RT-AC58U router (it uses an IPQ4018 SoC), WiFi was not working. It has two radios using the ath10k driver and it turns out that it needs some calibration data, stored in a dedicated flash partition. In my case, that partition was damaged somehow, but I could recover it because the router has a 2nd identical paritition, which was still good.

Now, as I understand it, at some point during the start-up process this happens:

  • the script /etc/hotplug.d/firmware/11-ath10k-caldata is run and copies the flash calibration data into /lib/firmware/ath10k/pre-cal-ahb-a000000.wifi.bin by running
    ath10kcal_ubi_extract "Factory" 4096 12064
    (and something similar for the 2nd radio)
  • the actual copying is done with
dd if=/dev/$ubi of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count 2>/dev/null || \
				ath10kcal_die "failed to extract from $ubi"
  • later on, the ath10k driver loads the /lib/firmware/ath10k/pre-cal-ahb-a000000.wifi.bin file
    In my case, as the partition was broken, the file was created with 0 length, leading to the WiFi problem. And I could see that the dd command fails when I tried it myself.

So, 1st question: that error message of ath10kcal_die, is it logged somewhere? It would have helped a little to see it.
And 2nd: would it be possible to update the script to also try extracting the calibration data from the 2nd partition (Factory2) in case the first one fails?

  1. something would be logged in the kernel, but maybe not that specific message. It is also likely that it was "extracted" successfully but the data itself is damaged.

  2. that's a good idea but not sure how it would be implemented, you're welcome to test changes to the scripts and file a pull request on github if it works

I have a dmesg log saved from when I had the problem, but the only error I see in there comes up later, after the dd copying, when the driver tries to load the firmware files.
I had read the log via the serial port, and there I could see that the bootloader itself detects this:

Read 0x1f000 bytes from volume [Factory] offset 0x0 to 86ec0ce0
damaged volume, update marker is setRead data fail at 0x0
Read 0x1f000 bytes from volume [Factory2] offset 0x0 to 86ec0ce0
EEPROM set 1: OK (version 13)
Read 0x1f000 bytes from volume [Factory2] offset 0x0 to 86ee2f58
Select EEPROM set 1 at offset 0x1f000.

I agree that a pull request would be the right thing to do. Unfortunately I do not have so much time to try it and test it right now, so I hoped that a developer involved with this platform could say something about the idea. Those scripts also apply to several devices based on IPQ4018, and somebody more knowledgeable could be able to implement a fix for several of them.
Anyway, I keep this in mind for some days with more free time.