> On May 30, 2023, at 10:56 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>
> On Tue, 30 May 2023 at 20:56, John Nielsen <li...@jnielsen.net
> <mailto:li...@jnielsen.net>> wrote:
>> > On May 30, 2023, at 8:02 PM, Adrian Chadd <adr...@freebsd.org
>> > <mailto:adr...@freebsd.org>> wrote:
>> >
>> > Err, if it's coming up w/ that MAC then it's not finding and attaching
>> > right to the OTP/EEPROM calibration information. That's the big red flag
>> > that it in general won't work correctly.
>> >
>> > Can you provide the rest of the ath_hal messages? I'd like to see what
>> > it's saying during boot around it checking the EEPROM/OTP contents. It's
>> > possible there's some work around required for this NIC.
>>
>> He speaks! Thanks for taking the time. I just realized that ath_hal_printf
>> doesn’t prepend “ath%d” so I’ve been missing those messages when grep-ing.
>> Here’s the whole snippet:
>>
>> ath0: <Atheros AR946x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0 on pci4
>> ar9300_flash_map: unimplemented for now
>> Restoring Cal data from DRAM
>> Restoring Cal data from EEPROM
>> Restoring Cal data from Flash
>> Restoring Cal data from Flash
>> Restoring Cal data from OTP
>> ar9300_eeprom_restore_internal[4338] No vaid CAL, calling default template
>> ar9300_hw_attach: ar9300_eeprom_attach returned 0
>
> Yeah, this bit right here is the problem. It's not finding a valid
> calibration.
> oh err, is there a wifi enable/disable switch or something? maybe it's
> asserted and somehow it's mucking up the NIC?
There is a physical switch and it’s in the “enable” position.
> I wonder what ath9k is doing here? Is there some weird pci based
> workaround/flag for the given NIC PCI id?
That was the first breadcrumb BZ threw me but I can’t find anything. There are
some .driver_data hints for adjacent subdevice IDs but none for this one (Dell
0x020d) in either FreeBSD or Linux that I could find.
The kernel on the Arch Linux USB I have handy doesn’t appear to have been
compiled with CONFIG_ATH_DEBUG but here’s what it has in
/sys/kernel/ieee80211/phy0/ath9k/base_eeprom:
EEPROM Version : 2
RegDomain1 : 108
RegDomain2 : 31
TX Mask : 3
RX Mask : 3
Allow 5GHz : 1
Allow 2GHz : 1
Disable 2GHz HT20 : 0
Disable 2GHz HT40 : 0
Disable 5Ghz HT20 : 0
Disable 5Ghz HT40 : 0
Big Endian : 0
RF Silent : 45
BT option : 0
Device Cap : 0
Device Type : 5
Power Table Offset : 0
Tuning Caps1 : 0
Tuning Caps2 : 0
Enable Tx Temp Comp : 1
Enable Tx Volt Comp : 0
Enable fast clock : 1
Enable doubling : 1
Internal regulator : 0
Enable Paprd : 0
Driver Strength : 0
Quick Drop : 1
Chain mask Reduce : 0
Write enable Gpio : 6
WLAN Disable Gpio : 0
WLAN LED Gpio : 8
Rx Band Select Gpio : 255
Tx Gain : 1
Rx Gain : 3
SW Reg : 303972983
MacAddress : 44:39:c4:5b:44:4a
It also has some calibration and other data in modal_eeprom.
There is this commit in ath9k which mentions an alternative EEPROM address, but
I’m not sure if that’s relevant. From what I can tell the probe should succeed
at the normal base_address 0x3ff instead of needing to try the “4k” one 0xfff.
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath9k?id=528782ecf59f7bab2f1368628a479f49be59b512
