Date: Wed, 31 May 2023 13:52:55 -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: <5264D290-EB82-4D24-A812-85E3E6B5C88E@jnielsen.net> In-Reply-To: <CAJ-VmonEoAGTN6XcDZQeU6Z=pcZiD-qNhPMYm%2BEXhiVbotwYcw@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> <BACFD661-E94B-4F50-93EE-91450EBD2212@jnielsen.net> <CAJ-VmonEoAGTN6XcDZQeU6Z=pcZiD-qNhPMYm%2BEXhiVbotwYcw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_C8BA0CC5-1187-4926-8F88-FF63B1972285 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 30, 2023, at 11:17 PM, Adrian Chadd <adrian@freebsd.org> wrote: >=20 > On Tue, 30 May 2023 at 22:12, John Nielsen <lists@jnielsen.net = <mailto:lists@jnielsen.net>> wrote: >>> On May 30, 2023, at 10:56 PM, Adrian Chadd <adrian@freebsd.org = <mailto:adrian@freebsd.org>> wrote: >>>=20 >>> 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: >>>> >=20 >>>> > 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. >>>> >=20 >>>> > 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. >>>>=20 >>>> 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=99= ve been missing those messages when grep-ing. Here=E2=80=99s the whole = snippet: >>>>=20 >>>> 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 >>>=20 >>> Yeah, this bit right here is the problem. It's not finding a valid = calibration. >>=20 >>> oh err, is there a wifi enable/disable switch or something? maybe = it's asserted and somehow it's mucking up the NIC? >>=20 >> There is a physical switch and it=E2=80=99s in the =E2=80=9Cenable=E2=80= =9D position. >>=20 >>> I wonder what ath9k is doing here? Is there some weird pci based = workaround/flag for the given NIC PCI id? >>=20 >> That was the first breadcrumb BZ threw me but I can=E2=80=99t 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. >>=20 >> The kernel on the Arch Linux USB I have handy doesn=E2=80=99t appear = to have 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 >>=20 >> It also has some calibration and other data in modal_eeprom.=20 >>=20 >> 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. =46rom = 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/drive= rs/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628a479f49be59b512 >=20 > Yeah i'd try that. It'd be nice if I knew that the NIC used OTP or = EEPROM though. >=20 > 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. :( The 4k EEPROM read didn=E2=80=99t work. But I did notice that where it = says it=E2=80=99s restoring Cal data from OTP it actually just does an = EEPROM read again. Shouldn=E2=80=99t this line be a call to = ar9300_otp_read() instead of ar9300_eeprom_restore_internal_address()? = https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar930= 0_eeprom.c#n4292 Otherwise it doesn=E2=80=99t use the 0x14000 (0x30000 for some cards) = OTP offset as a starting point. -John --Apple-Mail=_C8BA0CC5-1187-4926-8F88-FF63B1972285 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;"><div><blockquote type=3D"cite"><div>On May 30, 2023, = at 11:17 PM, Adrian Chadd <adrian@freebsd.org> = wrote:</div><div><div dir=3D"ltr"><br><div class=3D"gmail_quote"><div = dir=3D"ltr" class=3D"gmail_attr">On Tue, 30 May 2023 at 22:12, John = Nielsen <<a = href=3D"mailto:lists@jnielsen.net">lists@jnielsen.net</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 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:12px;font-style:normal;font-varia= nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text= -indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-d= ecoration:none"><div class=3D"gmail_quote" = style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia= nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text= -indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-d= ecoration: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_quote" 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 href=3D"mailto:adrian@freebsd.org" = target=3D"_blank">adrian@freebsd.org</a>> = wrote:<br>><span> </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> </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=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:<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=3D"cite" style=3D""><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></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-varia= nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text= -indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-d= ecoration: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=E2=80=99t 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=E2=80=99t appear 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> = 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=E2=80=99m not = sure if that=E2=80=99s relevant. =46rom 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 = href=3D"https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/comm= it/drivers/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628a479f49be5= 9b512" = target=3D"_blank">https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/at= h.git/commit/drivers/net/wireless/ath/ath9k?id=3D528782ecf59f7bab2f1368628= a479f49be59b512</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 = though.</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 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. = :(</div></div></div></div></blockquote></div><br><div>The 4k EEPROM read = didn=E2=80=99t work. But I did notice that where it says it=E2=80=99s = restoring Cal data from OTP it actually just does an EEPROM read again. = Shouldn=E2=80=99t this line be a call to ar9300_otp_read() instead of = ar9300_eeprom_restore_internal_address()?</div><div><br></div><div>https:/= /cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eepro= m.c#n4292</div><div><br></div><div>Otherwise it doesn=E2=80=99t use the = 0x14000 (0x30000 for some cards) OTP offset as a starting = point.</div><div><br></div><div>-John</div><div><br></div></body></html>= --Apple-Mail=_C8BA0CC5-1187-4926-8F88-FF63B1972285--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5264D290-EB82-4D24-A812-85E3E6B5C88E>