Date: Tue, 30 May 2023 23:11:59 -0600 From: John Nielsen <lists@jnielsen.net> To: Adrian Chadd <adrian@freebsd.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, "wireless@freebsd.org" <wireless@freebsd.org> Subject: Re: Help me grok the ath(4) device attach code Message-ID: <BACFD661-E94B-4F50-93EE-91450EBD2212@jnielsen.net> In-Reply-To: <CAJ-VmokL_Kdrgtv3YT6U=yKhr4d-wkba3Vx3AssfY3-iMuBT5Q@mail.gmail.com> References: <49AEA1CB-FA85-432F-89D7-8C49B5F3A344@jnielsen.net> <q921p430-oq56-qo4n-rq49-0o7008pr40n3@yvfgf.mnoonqbm.arg> <E6DF8709-2767-48D3-AED1-D0608F5AABCF@jnielsen.net> <CAJ-VmokUORGzQz6bOhutucy1xTv_1ZwP0vOZN=6vW1wusCLJpg@mail.gmail.com> <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> <CAJ-VmokL_Kdrgtv3YT6U=yKhr4d-wkba3Vx3AssfY3-iMuBT5Q@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
> On May 30, 2023, at 10:56 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>
> On Tue, 30 May 2023 at 20:56, John Nielsen <lists@jnielsen.net <mailto:lists@jnielsen.net>> wrote:
>> > On May 30, 2023, at 8:02 PM, Adrian Chadd <adrian@freebsd.org <mailto: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
>
> 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
[-- Attachment #2 --]
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><blockquote type="cite"><div>On May 30, 2023, at 10:56 PM, Adrian Chadd <adrian@freebsd.org> wrote:</div><div><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Tue, 30 May 2023 at 20:56, John Nielsen <<a href="mailto:lists@jnielsen.net">lists@jnielsen.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">> On May 30, 2023, at 8:02 PM, Adrian Chadd <<a href="mailto:adrian@freebsd.org" target="_blank">adrian@freebsd.org</a>> wrote:<br>><span class="Apple-converted-space"> </span><br>> 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.<br>><span class="Apple-converted-space"> </span><br>> 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.<br><br>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:<br><br>ath0: <Atheros AR946x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0 on pci4<br>ar9300_flash_map: unimplemented for now<br>Restoring Cal data from DRAM<br>Restoring Cal data from EEPROM<br>Restoring Cal data from Flash<br>Restoring Cal data from Flash<br>Restoring Cal data from OTP<br>ar9300_eeprom_restore_internal[4338] No vaid CAL, calling default template<br>ar9300_hw_attach: ar9300_eeprom_attach returned 0<br></blockquote><div><br></div><div>Yeah, this bit right here is the problem. It's not finding a valid calibration.</div></div></div></blockquote><div><br></div><div><blockquote type="cite" style="color: rgb(0, 0, 0);"><div>oh err, is there a wifi enable/disable switch or something? maybe it's asserted and somehow it's mucking up the NIC?</div></blockquote><br class="Apple-interchange-newline"></div><div>There is a physical switch and it’s in the “enable” position.</div><br><blockquote type="cite"><div><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div> I wonder what ath9k is doing here? Is there some weird pci based workaround/flag for the given NIC PCI id?</div></div></div></blockquote><br></div><div>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.</div><div><br></div><div>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:</div><div><div> EEPROM Version : 2</div><div> RegDomain1 : 108</div><div> RegDomain2 : 31</div><div> TX Mask : 3</div><div> RX Mask : 3</div><div> Allow 5GHz : 1</div><div> Allow 2GHz : 1</div><div> Disable 2GHz HT20 : 0</div><div> Disable 2GHz HT40 : 0</div><div> Disable 5Ghz HT20 : 0</div><div> Disable 5Ghz HT40 : 0</div><div> Big Endian : 0</div><div> RF Silent : 45</div><div> BT option : 0</div><div> Device Cap : 0</div><div> Device Type : 5</div><div> Power Table Offset : 0</div><div> Tuning Caps1 : 0</div><div> Tuning Caps2 : 0</div><div> Enable Tx Temp Comp : 1</div><div> Enable Tx Volt Comp : 0</div><div> Enable fast clock : 1</div><div> Enable doubling : 1</div><div> Internal regulator : 0</div><div> Enable Paprd : 0</div><div> Driver Strength : 0</div><div> Quick Drop : 1</div><div> Chain mask Reduce : 0</div><div> Write enable Gpio : 6</div><div> WLAN Disable Gpio : 0</div><div> WLAN LED Gpio : 8</div><div> Rx Band Select Gpio : 255</div><div> Tx Gain : 1</div><div> Rx Gain : 3</div><div> SW Reg : 303972983</div><div> MacAddress : 44:39:c4:5b:44:4a</div><div><br></div><div>It also has some calibration and other data in modal_eeprom. </div></div><div><br></div>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.<br><div>https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath9k?id=528782ecf59f7bab2f1368628a479f49be59b512</div><div><br></div></body></html>
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BACFD661-E94B-4F50-93EE-91450EBD2212>