Date: Tue, 30 May 2023 22:17:19 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Nielsen <lists@jnielsen.net> 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: <CAJ-VmonEoAGTN6XcDZQeU6Z=pcZiD-qNhPMYm%2BEXhiVbotwYcw@mail.gmail.com> In-Reply-To: <BACFD661-E94B-4F50-93EE-91450EBD2212@jnielsen.net> 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> <BACFD661-E94B-4F50-93EE-91450EBD2212@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000d21add05fcf66f78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2023 at 22:12, John Nielsen <lists@jnielsen.net> wrote: > 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> wrote: > >> > 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=E2=80=99t prepend =E2=80=9Cath%d=E2=80=9D so I=E2= =80=99ve been missing those messages >> when grep-ing. Here=E2=80=99s 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 templa= te >> 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=E2=80=99s in the =E2=80=9Cenable=E2=80= =9D 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=E2=80=99t find anythi= ng. 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=E2=80=99t appear to h= ave been > compiled with CONFIG_ATH_DEBUG but here=E2=80=99s 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=E2=80=99m not sure if that=E2=80=99s relevant. From what I= can tell the > probe should succeed at the normal base_address 0x3ff instead of needing = to > try the =E2=80=9C4k=E2=80=9D one 0xfff. > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/driv= ers/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628a479f49be59b512 > Yeah i'd try that. It'd be nice if I knew that the NIC used OTP or EEPROM though. There's known issues with all the Atheros chips (sigh) with how the EEPROM and PCIe bus reset .. interact. (If the bus reset is too short then the EEPROM state machine gets stuck and nothing gets read.) It makes debugging this hard because the NIC itself will work in another device fine, because it's the BIOS/ACPI code. :( -adrian --000000000000d21add05fcf66f78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, 30 May 2023 at 22:12, John Ni= elsen <<a href=3D"mailto:lists@jnielsen.net">lists@jnielsen.net</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div= ><blockquote type=3D"cite"><div>On May 30, 2023, at 10:56 PM, Adrian Chadd = <<a href=3D"mailto:adrian@freebsd.org" target=3D"_blank">adrian@freebsd.= org</a>> wrote:</div><div><br style=3D"font-family:Helvetica;font-size:1= 2px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spaci= ng:normal;text-align:start;text-indent:0px;text-transform:none;white-space:= normal;word-spacing:0px;text-decoration:none"><div class=3D"gmail_quote" st= yle=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant-= caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-ind= ent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decora= tion:none"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 30 May 2023 at 20:= 56, John Nielsen <<a href=3D"mailto:lists@jnielsen.net" target=3D"_blank= ">lists@jnielsen.net</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">> On May 30, 2023, at 8:02 PM, Adrian Chadd <<a h= ref=3D"mailto:adrian@freebsd.org" target=3D"_blank">adrian@freebsd.org</a>&= gt; wrote:<br>><span>=C2=A0</span><br>> Err, if it's coming up w/= that MAC then it's not finding and attaching right to the OTP/EEPROM c= alibration information. That's the big red flag that it in general won&= #39;t work correctly.<br>><span>=C2=A0</span><br>> Can you provide th= e rest of the ath_hal messages? I'd like to see what it's saying du= ring boot around it checking the EEPROM/OTP contents. It's possible the= re's some work around required for this NIC.<br><br>He speaks! Thanks f= or taking the time. I just realized that ath_hal_printf doesn=E2=80=99t pre= pend =E2=80=9Cath%d=E2=80=9D so I=E2=80=99ve been missing those messages wh= en grep-ing. Here=E2=80=99s the whole snippet:<br><br>ath0: <Atheros AR9= 46x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0 on pci4<br>ar9300_fl= ash_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 dat= a from Flash<br>Restoring Cal data from OTP<br>ar9300_eeprom_restore_intern= al[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=3D"cite" styl= e=3D"color:rgb(0,0,0)"><div>oh err, is there a wifi enable/disable switch o= r something? maybe it's asserted and somehow it's mucking up the NI= C?</div></blockquote><br></div><div>There is a physical switch and it=E2=80= =99s in the =E2=80=9Cenable=E2=80=9D position.</div><br><blockquote type=3D= "cite"><div><div class=3D"gmail_quote" style=3D"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;text-decoration:none"><div>=C2=A0I wonder wha= t ath9k is doing here? Is there some weird pci based workaround/flag for th= e given NIC PCI id?</div></div></div></blockquote><br></div><div>That was t= he first breadcrumb BZ threw me but I can=E2=80=99t find anything. There ar= e 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=E2=80=99t app= ear to have been compiled with CONFIG_ATH_DEBUG but here=E2=80=99s what it = has in /sys/kernel/ieee80211/phy0/ath9k/base_eeprom:</div><div><div>=C2=A0 = =C2=A0 =C2=A0 EEPROM Version : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02</div><di= v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RegDomain1 : =C2=A0 =C2=A0 =C2=A0 =C2= =A0108</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RegDomain2 : =C2=A0 =C2= =A0 =C2=A0 =C2=A0 31</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0TX Mask : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03</div><div>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RX Mask : =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A03</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow 5GHz : =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A= llow 2GHz : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>=C2=A0 =C2=A0Disa= ble 2GHz HT20 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2=A0= Disable 2GHz HT40 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 = =C2=A0Disable 5Ghz HT20 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2= =A0 =C2=A0Disable 5Ghz HT40 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div= >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Big Endian : =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RF Silent : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 45</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0BT option : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Device Cap : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</= div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Device Type : =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A05</div><div>=C2=A0 Power Table Offset : =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tuning Caps1 : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tuni= ng Caps2 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0Enable Tx Te= mp Comp : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>=C2=A0Enable Tx Vol= t Comp : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2=A0Enable = fast clock : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>=C2=A0 =C2=A0 = =C2=A0Enable doubling : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>=C2= =A0 Internal regulator : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Enable Paprd : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00= </div><div>=C2=A0 =C2=A0 =C2=A0Driver Strength : =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Quick Drop : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01</div><div>=C2=A0 =C2=A0Chain mask Reduce := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2=A0Write enable Gp= io : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06</div><div>=C2=A0 =C2=A0WLAN Disabl= e Gpio : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00</div><div>=C2=A0 =C2=A0 =C2=A0= =C2=A0WLAN LED Gpio : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08</div><div>=C2=A0= Rx Band Select Gpio : =C2=A0 =C2=A0 =C2=A0 =C2=A0255</div><div>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tx Gain : =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A01</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rx Gain = : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 SW Reg : =C2=A0303972983</div><div>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 MacAddress : 44:39:c4:5b:44:4a</div><div><br></div><div>I= t also has some calibration and other data in modal_eeprom.=C2=A0</div></di= v><div><br></div>There is this commit in ath9k which mentions an alternativ= e EEPROM address, but I=E2=80=99m not sure if that=E2=80=99s relevant. From= what I can tell the probe should succeed at the normal base_address 0x3ff = instead of needing to try the =E2=80=9C4k=E2=80=9D one 0xfff.<br><div><a hr= ef=3D"https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/= drivers/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628a479f49be59b51= 2" target=3D"_blank">https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/= ath.git/commit/drivers/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f136862= 8a479f49be59b512</a></div></div></blockquote><div><br></div><div>Yeah i'= ;d try that. It'd be nice if I knew that the NIC used OTP or EEPROM tho= ugh.</div><div><br></div><div>There's known issues with all the Atheros= chips (sigh) with how the EEPROM and PCIe bus reset .. interact.</div><div= >(If the bus reset is too short then the EEPROM state machine gets stuck an= d nothing gets read.) It makes debugging this hard because the NIC itself w= ill work in another device fine, because it's the BIOS/ACPI code. :(</d= iv><div><br></div><div><br></div><div>-adrian</div><div><br></div><div><br>= </div></div></div> --000000000000d21add05fcf66f78--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonEoAGTN6XcDZQeU6Z=pcZiD-qNhPMYm%2BEXhiVbotwYcw>