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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > On May 31, 2023, at 1:52 PM, John Nielsen <lists@jnielsen.net> wrote: > >> On May 30, 2023, at 11:17 PM, Adrian Chadd <adrian@freebsd.org> wrote: >> >> 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: >>>> >>>> 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. >>> >>> [snip] >>> 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 >> >> 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. :( > > The 4k EEPROM read didn’t work. But I did notice that where it says it’s restoring Cal data from OTP it actually just does an EEPROM read again. Shouldn’t 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/ar9300_eeprom.c#n4292 > > Otherwise it doesn’t use the 0x14000 (0x30000 for some cards) OTP offset as a starting point. I’d love to know if I’m up in the night about my theory above about the OTP call not actually happening. In the meantime I’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 [-- 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 31, 2023, at 1:52 PM, John Nielsen <lists@jnielsen.net> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><div 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;"><blockquote type="cite"><div>On May 30, 2023, at 11:17 PM, Adrian Chadd <adrian@freebsd.org> wrote:</div><div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 30 May 2023 at 22:12, 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;"><div><div><blockquote type="cite"><div>On May 30, 2023, at 10:56 PM, Adrian Chadd <<a href="mailto:adrian@freebsd.org" target="_blank">adrian@freebsd.org</a>> wrote:</div><div><br style="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="gmail_quote" style="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="ltr" class="gmail_attr">On Tue, 30 May 2023 at 20:56, John Nielsen <<a href="mailto:lists@jnielsen.net" target="_blank">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> </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’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"><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’s in the “enable” position.</div><br><blockquote type="cite"><div><div class="gmail_quote" style="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’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>[snip]</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><a href="https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath9k?id=528782ecf59f7bab2f1368628a479f49be59b512" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath9k?id=528782ecf59f7bab2f1368628a479f49be59b512</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="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="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’t work. But I did notice that where it says it’s restoring Cal data from OTP it actually just does an EEPROM read again. Shouldn’t this line be a call to ar9300_otp_read() instead of ar9300_eeprom_restore_internal_address()?</div><div 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;"><br></div><div 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;"><a href="https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c#n4292">https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c#n4292</a></div><div 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;"><br></div><div 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;">Otherwise it doesn’t use the 0x14000 (0x30000 for some cards) OTP offset as a starting point.</div></div></blockquote></div><br><div>I’d love to know if I’m up in the night about my theory above about the OTP call not actually happening. In the meantime I’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.</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>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CEDC118-5FCA-434D-B7F7-B0C4A7AC3ACC>