Date: Thu, 1 Jun 2023 23:28:07 -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: <8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC@jnielsen.net> In-Reply-To: <5264D290-EB82-4D24-A812-85E3E6B5C88E@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> <CAJ-VmonEoAGTN6XcDZQeU6Z=pcZiD-qNhPMYm%2BEXhiVbotwYcw@mail.gmail.com> <5264D290-EB82-4D24-A812-85E3E6B5C88E@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 31, 2023, at 1:52 PM, John Nielsen <lists@jnielsen.net> wrote: >=20 >> 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 >>> [snip] >>> 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. :( >=20 > 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()? >=20 > = https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar930= 0_eeprom.c#n4292 >=20 > Otherwise it doesn=E2=80=99t use the 0x14000 (0x30000 for some cards) = OTP offset as a starting point. I=E2=80=99d love to know if I=E2=80=99m up in the night about my theory = above about the OTP call not actually happening. In the meantime I=E2=80=99= ll carry on either trying to find/build a Linux kernel with = CONFIG_ATH_DEBUG enabled that I can boot on the laptop (to see which = EEPROM retrieval/check actually succeeds) and/or try to reimplement bits = from the ath9k ar9300_eeprom_restore_internal() to match its behavior on = FreeBSD. ( = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers= /net/wireless/ath/ath9k/ar9003_eeprom.c#n3266 ) Thanks, JN --Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7 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 31, 2023, = at 1:52 PM, John Nielsen <lists@jnielsen.net> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><div = style=3D"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;"><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-width: 1px; border-left-style: solid; = border-left-color: 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-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 = 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 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-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=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"><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-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> 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>[snip]</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 = style=3D"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 = style=3D"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;">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 style=3D"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;"><br></div><div style=3D"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;"><a = href=3D"https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar93= 00/ar9300_eeprom.c#n4292">https://cgit.freebsd.org/src/tree/sys/contrib/de= v/ath/ath_hal/ar9300/ar9300_eeprom.c#n4292</a></div><div = style=3D"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;"><br></div><div = style=3D"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;">Otherwise it = doesn=E2=80=99t use the 0x14000 (0x30000 for some cards) OTP offset as a = starting point.</div></div></blockquote></div><br><div>I=E2=80=99d love = to know if I=E2=80=99m up in the night about my theory above about the = OTP call not actually happening. In the meantime I=E2=80=99ll carry on = either trying to find/build a Linux kernel with CONFIG_ATH_DEBUG enabled = that I can boot on the laptop (to see which EEPROM retrieval/check = actually succeeds) and/or try to reimplement bits from the ath9k = ar9300_eeprom_restore_internal() to match its behavior on = FreeBSD.</div><div>( = https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers= /net/wireless/ath/ath9k/ar9003_eeprom.c#n3266 = )</div><div><br></div><div>Thanks,</div><div><br></div><div>JN</div><div><= br></div></body></html>= --Apple-Mail=_0601CF93-4FB8-43DE-9BAD-B9075B1001E7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC>