From nobody Wed May 31 05:17:19 2023 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QWHZk0V8cz4Y4Qm for ; Wed, 31 May 2023 05:17:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QWHZj4rHNz4FmG for ; Wed, 31 May 2023 05:17:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-4f4b384c09fso6262459e87.3 for ; Tue, 30 May 2023 22:17:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685510252; x=1688102252; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oRLON56D3Fr8Rd9wMKm7GR1sz5nBxYf1//qWyzeJzzY=; b=Xrnd8zilBI4sRgDJBrhPIO9y+pgRKBIhHiHOKaVv4AuuSD7Ot9SpGzbUyql2V7NDlK pK5inxmMvtZ+waU7d2jU42innAQhhipMgYz8uFwYYnO3LsVbv8kFKNzH1hBZMqW8vlAZ cNEbwqmoqgRBuDD72NTjIyT63urfjphEdUVxf2WjLzNay6cnGtspZAMb+j2JKVyiLVaJ vKnkkUmZYqPC74oyp/38/eCByrqqZV3MbhAAIdvWRVIKB/7KrBX674WrF6umUrv2wddN 33th9gAXJ2uUsZ77HYTaZEfOLvIYrvjRiCue8/q9smvwjr87PIe2pR4rC22c/90JWaaS UHYg== X-Gm-Message-State: AC+VfDyL3u7g7Q2mburl4Ke9ApPllEZHZ2Id4O9CREFPF4VSFXLz7NlD mEBgpj0JfS7dcDVbYLCF7zmeZ/COwfiMKhgwG8t7gAA9 X-Google-Smtp-Source: ACHHUZ7JwUWFtubJvGgxHQO3xJ7sH5+QB4Awr9blQ0EnH1mKFKdmbEvPuY6G8vlGHh4M6xvGOTTzfu8RS0j6NOOm+M4= X-Received: by 2002:a2e:828f:0:b0:2af:2466:1c18 with SMTP id y15-20020a2e828f000000b002af24661c18mr2109822ljg.18.1685510251746; Tue, 30 May 2023 22:17:31 -0700 (PDT) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org MIME-Version: 1.0 References: <49AEA1CB-FA85-432F-89D7-8C49B5F3A344@jnielsen.net> <85BF3AB2-2EBF-4398-A507-ABA35505A56C@jnielsen.net> In-Reply-To: From: Adrian Chadd Date: Tue, 30 May 2023 22:17:19 -0700 Message-ID: Subject: Re: Help me grok the ath(4) device attach code To: John Nielsen Cc: "Bjoern A. Zeeb" , "wireless@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000d21add05fcf66f78" X-Rspamd-Queue-Id: 4QWHZj4rHNz4FmG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000d21add05fcf66f78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2023 at 22:12, John Nielsen wrote: > On May 30, 2023, at 10:56 PM, Adrian Chadd wrote: > > On Tue, 30 May 2023 at 20:56, John Nielsen wrote: > >> > On May 30, 2023, at 8:02 PM, Adrian Chadd 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: 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


=
On Tue, 30 May 2023 at 22:12, John Ni= elsen <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&= gt; wrote:
>=C2=A0
> 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.
>=C2=A0
> 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.

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:

ath0: <Atheros AR9= 46x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0 on pci4
ar9300_fl= ash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring= Cal data from EEPROM
Restoring Cal data from Flash
Restoring Cal dat= a from Flash
Restoring Cal data from OTP
ar9300_eeprom_restore_intern= al[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 o= r something? maybe it's asserted and somehow it's mucking up the NI= C?

There is a physical switch and it=E2=80= =99s in the =E2=80=9Cenable=E2=80=9D position.

=C2=A0I wonder wha= t ath9k is doing here? Is there some weird pci based workaround/flag for th= e given NIC PCI id?

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>
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:
=C2=A0 = =C2=A0 =C2=A0 EEPROM Version : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RegDomain1 : =C2=A0 =C2=A0 =C2=A0 =C2= =A0108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RegDomain2 : =C2=A0 =C2= =A0 =C2=A0 =C2=A0 31
=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
=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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow 5GHz : =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A= llow 2GHz : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2=A0 =C2=A0Disa= ble 2GHz HT20 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0= Disable 2GHz HT40 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 = =C2=A0Disable 5Ghz HT20 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2= =A0 =C2=A0Disable 5Ghz HT40 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Big Endian : =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RF Silent : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 45
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0BT option : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Device Cap : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Device Type : =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A05
=C2=A0 Power Table Offset : =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tuning Caps1 : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tuni= ng Caps2 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0Enable Tx Te= mp Comp : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2=A0Enable Tx Vol= t Comp : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0Enable = fast clock : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2=A0 =C2=A0 = =C2=A0Enable doubling : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2= =A0 Internal regulator : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Enable Paprd : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=
=C2=A0 =C2=A0 =C2=A0Driver Strength : =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Quick Drop : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2=A0 =C2=A0Chain mask Reduce := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0Write enable Gp= io : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06
=C2=A0 =C2=A0WLAN Disabl= e Gpio : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
=C2=A0 =C2=A0 =C2=A0= =C2=A0WLAN LED Gpio : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08
=C2=A0= Rx Band Select Gpio : =C2=A0 =C2=A0 =C2=A0 =C2=A0255
=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
=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
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 SW Reg : =C2=A0303972983
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 MacAddress : 44:39:c4:5b:44:4a

I= t also has some calibration and other data in modal_eeprom.=C2=A0

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.

Yeah i'= ;d try that. It'd be nice if I knew that the NIC used OTP or EEPROM tho= ugh.

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 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. :(


-adrian


=
--000000000000d21add05fcf66f78--