[FS#3489] BulletM5 ath9k wlan not detected

OpenWrt Bugs openwrt-bugs at lists.openwrt.org
Sun Dec 13 04:54:01 EST 2020


THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#3489 - BulletM5 ath9k wlan not detected
User who did this - Alexandros C. Couloumbis (acoul)

----------
Hi Russel, 

thank you for the feedback

//Note the pci id at address 0x1a-0x1d (168c:002a). You might look at yours and compare. It looks like that eeprom bin is extracted from offset 0x1000 of the /dev/mtd8 partition. //

I think you really nailed the issue. is your Bullet-M a 2.4GHz version ? mine is a 5GHz

let me summarize so far the issue. 

in my Bullet-M5, ar71xx is working fine. under ath79/trunk though,  ath9k can't load without the [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=e9401a2335cc442bd06209ff7becdd60e940c3de|owl-loader helper]] which apparently does the following "magic:

  dmesg | grep -i pci'\|'awl'\|'ath

  SoC: Atheros AR7240 rev 2
  PCI: CLS 0 bytes, default 32
  switch0: Atheros AR724X/AR933X built-in rev. 2 switch registered on mdio.0
  eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii
  PCI host bridge /ahb/apb/pcie-controller at 180c0000 ranges:
  PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [mem 0x10000000-0x13ffffff]
  pci_bus 0000:00: root bus resource [io  0x0000]
  pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
  pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
  pci 0000:00:00.0: [168c:ff1c] type 00 class 0x020000
  pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
  pci 0000:00:00.0: supports D1
  pci 0000:00:00.0: PME# supported from D0 D1 D3hot
  pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
  pci 0000:00:00.0: BAR 0: assigned [mem 0x10000000-0x1000ffff 64bit]
  ath9k_pci_owl_loader 0000:00:00.0: enabling device (0000 -> 0002)
  ath9k_pci_owl_loader 0000:00:00.0: fixup device configuration
  pci 0000:00:00.0: [168c:002a] type 00 class 0x028000
  pci 0000:00:00.0: reg 0x10: [mem 0x10000000-0x1000ffff 64bit]
  pci 0000:00:00.0: supports D1
  pci 0000:00:00.0: PME# supported from D0 D1 D3hot
  pci 0000:00:00.0: BAR 0: assigned [mem 0x10000000-0x1000ffff 64bit]
  ath9k 0000:00:00.0: enabling device (0000 -> 0002)
  ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
  ath: EEPROM regdomain sanitized
  ath: EEPROM regdomain: 0x64
  ath: EEPROM indicates we should expect a direct regpair map
  ath: Country alpha2 being used: 00
  ath: Regpair used: 0x64
  ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xb0000000, irq=12
  ath: EEPROM regdomain: 0x812c
  ath: EEPROM indicates we should expect a country code
  ath: doing EEPROM country->regdmn map search
  ath: country maps to regdmn code: 0x37
  ath: Country alpha2 being used: GR
  ath: Regpair used: 0x37
  ath: regdomain 0x812c dynamically updated by user

specifically the "magic" is done here:

  dmesg | grep "type 00 class"

  pci 0000:00:00.0: [168c:ff1c] type 00 class 0x020000
  pci 0000:00:00.0: [168c:002a] type 00 class 0x028000

I don't know if this ath79 issue is related to [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f6385f30bd2ef202e526d964c5eebcf2b04d0675|this peculiarity]]

in my ar71xx Bullet-M5:

  dmesg | grep -i pci'\|'awl'\|'ath
  SoC: Atheros AR7240 rev 2
  registering PCI controller with io_map_base unset
  PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [mem 0x10000000-0x13ffffff]
  pci_bus 0000:00: root bus resource [io  0x0000]
  pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
  pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
  pci 0000:00:00.0: [168c:ff1c] type 00 class 0x020000
  pci 0000:00:00.0: fixup device configuration
  pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
  pci 0000:00:00.0: supports D1
  pci 0000:00:00.0: PME# supported from D0 D1 D3hot
  pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
  pci 0000:00:00.0: BAR 0: assigned [mem 0x10000000-0x1000ffff 64bit]
  pci 0000:00:00.0: using irq 40 for pin 1
  PCI: CLS 0 bytes, default 32
  eth0: Atheros AG71xx at 0xb9000000, irq 4, mode:MII
  PCI: Enabling device 0000:00:00.0 (0000 -> 0002)
  ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
  ath: EEPROM regdomain: 0x0
  ath: EEPROM indicates default country code should be used
  ath: doing EEPROM country->regdmn map search
  ath: country maps to regdmn code: 0x3a
  ath: Country alpha2 being used: US
  ath: Regpair used: 0x3a
  ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xb0000000, irq=40

I wonder if the ar71xx "maggic" happens here:
  PCI: Enabling device 0000:00:00.0 (0000 -> 0002)

which is similar to this ath79/owl:

  ath9k_pci_owl_loader 0000:00:00.0: enabling device (0000 -> 0002)


cheers
----------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3489#comment9159

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.



More information about the openwrt-bugs mailing list