I was trying to get a stable ath79 build working on my TL-WR741ND device. A 19.07-SNAPSHOT build comes up fine, but doesn't have wifi showing anywhere.
After looking around a bit I found this:
root@OpenWrt:~# dmesg|grep -i ath
[ 0.000000] SoC: Atheros AR7240 rev 2
[ 0.841973] switch0: Atheros AR724X/AR933X built-in rev. 2 switch registered on mdio-bus.0
[ 0.903884] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii
[ 1.259748] eth1: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[ 18.495173] ath9k 0000:00:00.0: Direct firmware load for ath9k-eeprom-pci-0000:00:00.0.bin failed with error -2
[ 18.505386] ath9k 0000:00:00.0: Falling back to user helper
[ 20.429262] firmware ath9k-eeprom-pci-0000:00:00.0.bin: firmware_loading_store: map pages failed
[ 20.439346] ath: phy0: Unable to load EEPROM file ath9k-eeprom-pci-0000:00:00.0.bin
[ 20.447053] ath9k 0000:00:00.0: Failed to initialize device
[ 20.452816] ath9k: probe of 0000:00:00.0 failed with error -22
If I change the build target to same device on ar71xx then wifi does work, and the logs look healthier:
root@OpenWrt:~# dmesg|grep -i ath
[ 0.000000] SoC: Atheros AR7240 rev 2
[ 1.675099] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[ 2.315693] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii
[ 18.998208] ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
[ 19.005385] ath: phy0: Enable LNA combining
[ 19.011048] ath: EEPROM regdomain: 0x0
[ 19.011057] ath: EEPROM indicates default country code should be used
[ 19.011063] ath: doing EEPROM country->regdmn map search
[ 19.011087] ath: country maps to regdmn code: 0x3a
[ 19.011096] ath: Country alpha2 being used: US
[ 19.011103] ath: Regpair used: 0x3a
[ 19.032719] ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xb0000000, irq=40
Presumably if the wifi device can be found and configured on ar71xx it should also be there on ath79? The change is more about configuraton that capability isn't it?
If so, is the hardware management code the same across ar71xx and ath99, and hence this is likely to be fixable by some configuration / description change in the platform dts files such as PCI references, MTD partition layouts, where magic numbers are found, etc? Or is there a bigger difference between in the device handling code that might take me into the the wireless device management code?
Looks like the firmware file is missing from the build:
loading /lib/firmware/updates/4.14.214/ath9k-eeprom-pci-0000:00:00.0.bin failed with error -2
loading /lib/firmware/updates/ath9k-eeprom-pci-0000:00:00.0.bin failed with error -2
loading /lib/firmware/4.14.214/ath9k-eeprom-pci-0000:00:00.0.bin failed with error -2
loading /lib/firmware/ath9k-eeprom-pci-0000:00:00.0.bin failed with error -2
Direct firmware load for ath9k-eeprom-pci-0000:00:00.0.bin failed with error -2
root@OpenWrt:~# find /lib/firmware -type f
/lib/firmware/regulatory.db
If memory serves me right ath9k doesn't need any firmware, so I'm not sure what's going on here. I have a newer QCA based device (UniFi AC AP Pro) that has a SoC provided ath9k radio, and there's nothing in /lib/firmware/ except for the ath10k blobs for the AC radio.
root@WN604-A:~# find /lib/firmware -type f
/lib/firmware/regulatory.db
/lib/firmware/ath9k-eeprom-pci-0000:00:00.0.bin
I'll try and track down where the EEPROM file comes from. I vaguely recall seeing a script to create it being pat of the device set check-in. Maybe it isn't being called correctly.
That is the extracted (from ART and often patched, to contain the correct MAC address) wifi calibration data, it must be present (and valid), but is not really firmware (just treated as such, to pass it to the kernel).
/etc/hotplug.d/firmware/10-ath9k-eeprom is the script I found, but looks like it depends on the firmware file already being know as a the place to load calibraton data for.
I copied the /lib/firmware/... file from my WN604 device to the WR741ND and it made wifi come to life.
I'll keep looking at what is same / different on the two. Back to my original Q, is this likely to be DTS driven or will I need to look somewhere else?
Correct, it's supposed to extract ART under firstboot conditions, patch it with the correct MAC address and write it to /lib/firmware/ (so it can be re-used by future reboots). Keep in mind that this wifi calibration data is device specific, necessary to offset manufacturing variations - while using a different calibration data might bring the interface up, it will be running out of spec (resulting in problems and legal issue (technically you lose certification and can be fined)).
First line of that script is [ -e /lib/firmware/$FIRMWARE ] && exit 0, so something else is supposed to have created the base file for patching. Next line (. /lib/functions/caldata.sh) aims to load some scripts, but they aren't there. Perhaps that is also needed by whatever is trying to create the "firmware" file.
A first_boot to clear away my dabblings followed by copying caldata.sh into place from the WN604 also gets wifi operational. So now I have to figure out why that script wasn't there.
I'll see if I can work out the difference between the WN604 and WR741 configs that might be causing it.
EDIT: Just relalised my WN604 build is from ~8 months or so ago so not necessarily a good comparison at HEAD of the branch. I'll see if a 19.07.X tag from around then works for the WR741. Just building 19.07.3...
On further inspection it seems I may have some ath9 related files from master in my 19.07 branch, prob from where I applied a patch I had a week or so ago but didn't stash it when moving to other branches. Just trying to untangle it all. I'll wipe and recreate the workarea if needed.
# add openwrt tree to list of remote trees
git remote add openwrt https://github.com/openwrt/openwrt.git
# fetch HEAD of all remote trees
git fetch
# new branch based on SNAPSHOT-19.07 with the same name
git branch --track openwrt-19.07 openwrt/openwrt-19.07
# switch to the new branch and update (git pull by itself requires tracking)
git checkout openwrt-19.07
git pull
or
git pull openwrt openwrt-19.07
# run make clean and build like usual
Thanks. I did a version of that in the end and all is well.
The thing that masked the problem (for me, maybe not those more familar with git) was that a git status showed the folder name (./blah/blah/base-files/blah/) where the "bad" files were as untracked (insert correct git phrase here) but not the actual files, so I missed them until I started spotting unusual timestamps on files in my build tree, inconsistensices that I couldn't explain in commits in the tree vs the files I had.
All good now - trimmed down 19.07-SNAPSHOT running happily on my WR741ND .
.