Re: Help me grok the ath(4) device attach code

> On May 30, 2023, at 8:02 PM, Adrian Chadd <adrian@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
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] LDPC transmit/receive enabled
ath0: [HT] 3 RX streams; 3 TX streams
ath0: AR9460 mac 640.2 RF5110 phy 0.0
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000

And the comments in ar9300_eeprom_restore_something() are less faith-inspiring the farther down you read.. I was about to add some printfs there to see when it finally returns, I’ll post what I learn. I’m happy to do any other code modifications or testing you’d suggest as well.

-JN