OpenWrt support for Linksys MX8500

lytr · March 12, 2024, 1:15pm

@Ansuel Could you take a look at this BDF file: https://github.com/testuser7/firmware_qca-wireless/blob/mx8500-dev/board-linksys_mx8500.qcn9074?

I have removed regdomain and updated regdb (7 KB regdb replaced by 10 KB regdb and remaining data moved).
I'm able to start radio but there is no transmission:

phy2-ap0  ESSID: "6g"
          Access Point: **:**:**:**:**:**
          Mode: Master  Channel: 33 (6.115 GHz)  HT Mode: HE80
          Center Channel 1: 39 2: unknown
          Tx-Power: 10 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -104 dBm
          Bit Rate: unknown
          Encryption: WPA3 SAE (CCMP)
          Type: nl80211  HW Mode(s): 802.11ax
          Hardware: 17CB:1104 17CB:1104 [Qualcomm Atheros QCN6024/9024/9074]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy2

lytr · March 12, 2024, 1:54pm

It seems that even though supports_regdb is set, regdb is not loaded from the file bus=pci,qmi-chip-id=0,qmi-board-id=255,variant=Linksys-MX8500.regdb inside board-2.bin or external regdb.bin.

lytr · March 12, 2024, 2:43pm

I tried writing this way with fixed partition layout but I still get the same crc error:

			partition@13e80000 {
				label = "0:ethphyfw";
				reg = <0x13e80000 0x100000>;
				read-only;

				compatible = "nvmem-cells";
				#address-cells = <1>;
				#size-cells = <1>;

				aqr_fw: firmware@0 {
					/* Skip the QCOM MBN Header of 40 bytes */
					reg = <0x28 0x5f82a>;
				};
			};

[    2.774100] Aquantia AQR114C 90000.mdio-1:08: bad firmware CRC: file 0xffff calculated 0xe266

robimarko · March 12, 2024, 4:19pm

You should be able to dump that NVMEM cell manually, most likely the size or something is not correct and the content being passed is invorrect

lytr · March 12, 2024, 11:00pm

Firmware CRC is 0xcc87. It is loaded correctly from u-boot and from file.
There is something wrong with reading and calculating firmware CRC.

Firmware size is 391170 bytes (0x5f802) and additional 40 bytes (0x28) header.

Partition dump is correct:

root@OpenWrt:/# hexdump -C -n 64 /dev/mtd26
00000000  13 00 00 00 03 00 00 00  00 00 00 00 00 00 00 44  |...............D|
00000010  02 f8 05 00 02 f8 05 00  02 f8 05 44 00 00 00 00  |...........D....|
00000020  02 f8 05 44 00 00 00 00  00 00 00 00 00 00 00 00  |...D............|
00000030  05 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

I have used address instead of size...
It's working now:

[    2.927687] Aquantia AQR114C 90000.mdio-1:08: loading firmware version 'v5.4.B WNC SAQA-L2 070220 15:39:53' from 'NVMEM'
[   14.149115] aquantia_phy_api_ops_init[2241]:INFO:qca probe aquantia phy driver succeeded!

Does the header need to be modified when changing the firmware on a partition?

robimarko · March 13, 2024, 9:11am

If you dont need U-Boot FW loading then you dont need to add the header, its the QCA MBN header for U-Boot only.

lytr · March 13, 2024, 9:26am

There is an issue when firmware is loaded during boot. QCA8075 ports are not working (no transmission, link is detected). After loading firmware in u-boot all ports are working.
So for now I want to load firmware from u-boot.

The header can probably be prepared like this: Adding OpenWrt support for QNAP QHora-301W - #205 by kirdes

robimarko · March 13, 2024, 9:32am

Now this should be investigated, since its Linksys, U-Boot should be available in GPL dump

lytr · March 13, 2024, 9:47am

During boot I get restarts quite often with this error:

[ 5855.192802] pcieport 0000:00:00.0: AER: Multiple Corrected error message received from 0000:00:00.0

Do you have any idea what might be causing it?

robimarko · March 13, 2024, 12:26pm

Sadly no, as I have not seen this before

lytr · March 13, 2024, 1:06pm

I have found the same error in one of your posts: Adding OpenWrt support for Xiaomi AX3600 (Part 1) - #4901 by robimarko

robimarko · March 13, 2024, 1:20pm

That was on IPQ4019 when I was packaging ath11k-pci

lytr · March 13, 2024, 1:23pm

Do you think that this patch is ready to go upstream: OpenWrt support for Linksys MX8500 - #30 by lytr ?
Or maybe it requires more testing.

@Ansuel can you take a look? You recently sent patches to AQR.

robimarko · March 13, 2024, 1:38pm

Check whether 10G is accidentally being advertised as AQR114 is 5G max, and this wont apply upstream directly, needs to be reworked on net-next

lytr · March 13, 2024, 2:31pm

There is +10g: OpenWrt support for Linksys MX8500 - #63 by lytr
So this is incorrect?

robimarko · March 13, 2024, 2:55pm

Yes, as according to the datasheet AQR114 is limited at 5G max.

But, do you have a way to test whether it works at 10G, I wouldnt be surprised if it is just a SW limitation in the end?

lytr · March 13, 2024, 2:57pm

I can only test 2.5GbE.

I have compiled driver with this config:

static int aqr111_config_init(struct phy_device *phydev)
{
	/* AQR111 reports supporting speed up to 10G,
	 * however only speeds up to 5G are supported.
	 */
	phy_set_max_speed(phydev, SPEED_5000);

	return aqr107_config_init(phydev);
}

but I don't see any difference:

root@OpenWrt:/# mdio 9* mmd 8:1
CTRL1(0x00): 0x2040
  flags: -reset -low-power -remote-loopback -local-loopback
  speed: 10g

STAT1(0x01): 0x0082
  capabilities: -pias -peas +low-power
  flags:        +fault -link

DEVID(0x02/0x03): 0x31c31c22

SPEED(0x04): 0x6031
  capabilities: -400g +5g +2.5g -200g -25g -10g-xr -100g -40g -10g/1g -10 +100
                +1000 -10-ts -2-tl +10g

DEVS(0x06/0x05): 0xe000009a
  devices: +vendor2 +vendor1 +c22-ext -power-unit -ofdm -pma4 -pma3 -pma2 -pma1
           +aneg -tc -dte-xs +phy-xs +pcs -wis +pma/pmd -c22

CTRL2(0x07): 0x0009
  flags: -pias -peas
  type:  10g-t

STAT2(0x08): 0xb701
  capabilities: +tx-fault +rx-fault +ext-register +tx-disable +local-loopback
                -10g-sr -10g-lr -10g-er -10g-lx4 -10g-sw -10g-lw -10g-ew
  flags:        +present -tx-fault +rx-fault

EXTABLE(0x0B): 0x40fc
  capabilities: -10g-cx4 -10g-lrm +10g-t +10g-kx4 +10g-kr +1000-t +1000-kx
                +100-tx -10-t -p2mp -40g/100g -1000/100-t1 -25g -200g/400g
                +2.5g/5g -1000-h

PKGID(0x0E/0x0F): 0x31c31c22

root@OpenWrt:/# mdio 9* mmd 8:3
CTRL1(0x00): 0x2040
  flags: -reset -loopback -low-power -lpi-clock-stop 
  speed: 10g

STAT1(0x01): 0x0082
  capabilities: -lpi-clock-stop +low-power
  flags:        -rx-lpi-recv -tx-lpi-recv -rx-lpi-ind -tx-lpi-ind +fault -link

DEVID(0x02/0x03): 0x31c31c22

SPEED(0x04): 0x00c1
  capabilities: -400g -200g +5g -2.5g -25g -100g -40g -10-ts/2-tl +10g

DEVS(0x06/0x05): 0xe000009a
  devices: +vendor2 +vendor1 +c22-ext -power-unit -ofdm -pma4 -pma3 -pma2 -pma1
           +aneg -tc -dte-xs +phy-xs +pcs -wis +pma/pmd -c22

CTRL2(0x07): 0x0003
  type: 10g-t

STAT2(0x08): 0xbc09
  capabilities: +5g-t +2.5g-t -25g-t -25g-r -40g-t -100g-r -40g-r +10g-t -10g-w
                -10g-x +10g-r
  flags:        +present +tx-fault +rx-fault

PKGID(0x0E/0x0F): 0x31c31c22

robimarko · March 13, 2024, 4:10pm

Unplug the cable and check with ethtool what is advertised as supported, as that is what is being limited, we cannot remove the PHY advertising 10G in its registers

lytr · March 13, 2024, 5:40pm

It seems to be correct now:

root@OpenWrt:/# ethtool wan
Settings for wan:
	Supported ports: [  ]
	Supported link modes:   100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        1000baseKX/Full
	                        2500baseT/Full
	                        5000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        1000baseKX/Full
	                        2500baseT/Full
	                        5000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Auto-negotiation: on
	Port: Twisted Pair
	PHYAD: 8
	Transceiver: external
	MDI-X: Unknown
	Link detected: no

lytr · March 14, 2024, 12:10am

Sometimes the restart happens without any errors in the logs:

[    9.343060] urngd: v1.0.2 started.
[    9.368185] PPP generic driver version 2.4.2
[    9.368959] NET: Registered PF_PPPOX protocol family
[    9.377376] ath11k c000000.wifi: ipq8074 hw2.0
[    9.377408] ath11k c000000.wifi: FW memory mode: 0
[    9.380967] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[    9.385560] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[    9.737163] remoteproc remoteproc0: remote processor cd00000.q6v5_wcss is now up
[    9.739421] ath11k_pci 0000:01:00.0: BAR 0: assigned [mem 0x20400000-0x205fffff 64bit]
[    9.743700] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[    9.751769] ath11k_pci 0000:01:00.0: MSI vectors: 16
[    9.757539] ath11k_pci 0000:01:00.0: qcn9074 hw1.0
[    9.762724] ath11k_pci 0000:01:00.0: FW memory mode: 2

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.3.1-00163
S - IMAGE_VARIANT_STRING=HAACANAZA
S - OEM_IMAGE_VERSION_STRING=CRM
S - Boot Config, 0x000002e5
B -       201 - PBL, Start
B -      2736 - bootable_media_detect_entry, Start
B -      3443 - bootable_media_detect_success, Start
B -      3447 - elf_loader_entry, Start

Could this be a problem with loading the ath11k ahb and pci drivers at the same time?