OpenWrt support for Linksys MX8500

Thanks, port is working now but with wrong speed (connected to the 1GbE port):

[   72.392441] nss-dp 3a007000.dp6-syn wan: PHY Link up speed: 100
root@OpenWrt:/# ethtool wan
Settings for wan:
	Supported ports: [  ]
	Supported link modes:   100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        10000baseT/Full
	                        1000baseKX/Full
	                        10000baseKX4/Full
	                        10000baseKR/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
	                        10000baseT/Full
	                        1000baseKX/Full
	                        10000baseKX4/Full
	                        10000baseKR/Full
	                        2500baseT/Full
	                        5000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 100Mb/s
	Duplex: Full
	Auto-negotiation: on
	Port: MII
	PHYAD: 8
	Transceiver: external
	Link detected: yes

Its because kernel sees your link partner only capable of 100M, this shouldn't really have anything to do with it.

No, something is wrong.
Connecting the same cable to another port:

[ 1245.432344] nss-dp 3a001400.dp3 lan3: PHY Link up speed: 1000

Yes, something is wrong, but I dont see how enabling C45 reads and writes causes it.
You can try dropping this "fix", and then just manually setting MMD 4 register 0xc441 to 0x8 to enable USXGMII MAC autoneg and then see if kernel sees 1G capability on the link partner

Without "fix" I have the same result:

root@OpenWrt:/# mdio 9* mmd 8:4 0xC441
0x0000
root@OpenWrt:/# mdio 9* mmd 8:4 0xC441 8
root@OpenWrt:/# mdio 9* mmd 8:4 0xC441
0x0008
[  603.112186] nss-dp 3a007000.dp6-syn wan: PHY Link up speed: 100

Maybe the changes mentioned by @rmandrad are needed: Adding OpenWrt support for QNAP QHora-301W - #749 by rmandrad ?

You are using the kernel or u-boot to load the FW?

I load FW using u-boot. There is a problem with reset gpio when loading FW from the kernel.

And it worked completely fine with kernel 6.1?

Yes: OpenWrt support for Linksys MX8500 - #43 by lytr

I tried using the latest sources: https://git.codelinaro.org/clo/qsdk/oss/lklm/qca-ssdk/-/commit/6c08d8a5c406c3fc5ec15d27ec11de725d7749ef
But there is no change. The link speed is still incorrect.

Its not an SSDK issue, AQR is reporting those itself via standard registers

Are there any changes in the latest aquantia driver sources that should be backported?

Most stuff has been backported, driver itself pretty much only loads the FW and populates info for the kernel, there isn't much if any configuration of the PHY in it, that is usually done by the PHY FW

Aquantia patches from Linksys GPL sources:

I did not notice any automatic restarts after setting the loading order of ath11k modules:

90-ath11k-ahb
91-ath11k-pci
[    8.643107] procd: - early -
[    8.643182] procd: - watchdog -
[    9.175954] procd: - watchdog -
[    9.176191] procd: - ubus -
[    9.229411] procd: - init -
Please press Enter to activate this console.
[    9.359700] kmodloader: loading kernel modules from /etc/modules.d/*
[    9.429528] hid: raw HID events driver (C) Jiri Kosina
[    9.430141] Loading modules backported from Linux version v6.6.15-0-g51f354b815c4
[    9.433667] Backport generated by backports.git 193becf2
[    9.463979] ath11k c000000.wifi: ipq8074 hw2.0
[    9.464012] ath11k c000000.wifi: FW memory mode: 0
[    9.484329] NET: Registered PF_QIPCRTR protocol family
[    9.485081] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[    9.488425] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[    9.561855] urngd: v1.0.2 started.
[    9.839537] remoteproc remoteproc0: remote processor cd00000.q6v5_wcss is now up
[    9.844291] ath11k_pci 0000:01:00.0: BAR 0: assigned [mem 0x20400000-0x205fffff 64bit]
[    9.846059] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[    9.854223] ath11k_pci 0000:01:00.0: MSI vectors: 16
[    9.859907] ath11k_pci 0000:01:00.0: qcn9074 hw1.0
[    9.865104] ath11k_pci 0000:01:00.0: FW memory mode: 2
[   10.026709] mhi mhi0: Requested to power ON
[   10.026749] mhi mhi0: Power on setup success
[   10.131701] mhi mhi0: Wait for device to enter SBL or Mission mode
[   10.186943] Bluetooth: Core ver 2.22
[   10.187060] NET: Registered PF_BLUETOOTH protocol family
[   10.189593] Bluetooth: HCI device and connection manager initialized
[   10.194920] Bluetooth: HCI socket layer initialized
[   10.201227] Bluetooth: L2CAP socket layer initialized
[   10.205842] Bluetooth: SCO socket layer initialized
[   10.212095] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.215721] Bluetooth: BNEP filters: protocol multicast
[   10.221282] Bluetooth: BNEP socket layer initialized
[   10.229302] usbcore: registered new interface driver btusb
[   10.232128] Bluetooth: HCI UART driver ver 2.3
[   10.236726] Bluetooth: HCI UART protocol H4 registered
[   10.241153] Bluetooth: HCI UART protocol BCSP registered
[   10.247087] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   10.251770] Bluetooth: HIDP socket layer initialized
[   10.264617] Bluetooth: RFCOMM TTY layer initialized
[   10.264651] Bluetooth: RFCOMM socket layer initialized
[   10.268309] Bluetooth: RFCOMM ver 1.11
[   10.284138] ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[   10.284179] ath11k_pci 0000:01:00.0: fw_version 0x290607b9 fw_build_timestamp 2023-10-12 01:21 fw_build_id 
[   10.299362] PPP generic driver version 2.4.2
[   10.302214] NET: Registered PF_PPPOX protocol family
[   10.305981] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[   10.312749] kmodloader: done loading kernel modules from /etc/modules.d/*
[   10.316938] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[   10.323783] ath11k c000000.wifi: fw_version 0x290604a5 fw_build_timestamp 2023-10-12 02:06 fw_build_id WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1
[   10.763605] ath11k c000000.wifi: htt event 48 not handled

Before the change, it looked like this:

[    8.523278] procd: - early -
[    8.523352] procd: - watchdog -
[    9.056327] procd: - watchdog -
[    9.056564] procd: - ubus -
[    9.209229] procd: - init -
Please press Enter to activate this console.
[    9.330525] kmodloader: loading kernel modules from /etc/modules.d/*
[    9.398119] hid: raw HID events driver (C) Jiri Kosina
[    9.404691] Bluetooth: Core ver 2.22
[    9.404805] NET: Registered PF_BLUETOOTH protocol family
[    9.407340] Bluetooth: HCI device and connection manager initialized
[    9.412657] Bluetooth: HCI socket layer initialized
[    9.418972] Bluetooth: L2CAP socket layer initialized
[    9.423584] Bluetooth: SCO socket layer initialized
[    9.429557] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    9.433478] Bluetooth: BNEP filters: protocol multicast
[    9.439029] Bluetooth: BNEP socket layer initialized
[    9.446978] usbcore: registered new interface driver btusb
[    9.449558] Loading modules backported from Linux version v6.6.15-0-g51f354b815c4
[    9.454490] Backport generated by backports.git 193becf2
[    9.462681] Bluetooth: HCI UART driver ver 2.3
[    9.467407] Bluetooth: HCI UART protocol H4 registered
[    9.471660] Bluetooth: HCI UART protocol BCSP registered
[    9.477474] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    9.482273] Bluetooth: HIDP socket layer initialized
[    9.490285] urngd: v1.0.2 started.
[    9.496842] NET: Registered PF_QIPCRTR protocol family
[    9.498715] Bluetooth: RFCOMM TTY layer initialized
[    9.501447] Bluetooth: RFCOMM socket layer initialized
[    9.506309] Bluetooth: RFCOMM ver 1.11
[    9.542267] PPP generic driver version 2.4.2
[    9.542931] NET: Registered PF_PPPOX protocol family
[    9.553767] ath11k c000000.wifi: ipq8074 hw2.0
[    9.553799] ath11k c000000.wifi: FW memory mode: 0
[    9.557320] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[    9.561938] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[    9.913548] remoteproc remoteproc0: remote processor cd00000.q6v5_wcss is now up
[    9.916264] ath11k_pci 0000:01:00.0: BAR 0: assigned [mem 0x20400000-0x205fffff 64bit]
[    9.920088] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[    9.928254] ath11k_pci 0000:01:00.0: MSI vectors: 16
[    9.933923] ath11k_pci 0000:01:00.0: qcn9074 hw1.0
[    9.939108] ath11k_pci 0000:01:00.0: FW memory mode: 2
[ 5844.178791] pcieport 0000:00:00.0: AER: Multiple Corrected error message received from 0000:00:00.0

Maybe loading ath11k modules after bluetooth modules is a problem?

Stupid thing, I forgot to add the patch for AQR114C to the directory with patches for kernel 6.6 :slight_smile:

1 Like

Now I'm trying to understand how gpio44 is set high.

From GPL sources:

@@ -180,11 +184,13 @@
 			drive-strength = <8>;
 			bias-pull-up;
 		};
+#if 0		//WNC[Kenny], fix eth0 issue.	
 		mux_2 {
 			pins = "gpio44";
 			function = "gpio";
 			bias-pull-up;
 		};
+#endif		
 	};
 
 	uart_pins: uart_pins {   
 	};
 
-	mdio@90000 {
+	mdio: mdio@90000 { /*wnc_jackson*/
 		pinctrl-0 = <&mdio_pins>;
 		pinctrl-names = "default";
-		phy-reset-gpio = <&tlmm 37 0>;
-		compatible = "qcom,ipq40xx-mdio", "qcom,qca-mdio";
+		phy-reset-gpio = <&tlmm 37 0 &tlmm 44 1>;
+		/*wnc_jackson*/
+		/*compatible = "qcom,ipq40xx-mdio", "qcom,qca-mdio"; */
 		phy0: ethernet-phy@0 {
 			reg = <0>;
 		};

Full dts patch: https://gist.github.com/testuser7/2a948efd815d4fbb43eaf4007839c4d3

Usually its simply set as the reset GPIO, but the issue is that you cannot construct a compatible with C45 PHY ID like you can for C22 PHY-s so it never gets invoked.

phy-reset-gpio is a QCA custom hack they added to the MDIO driver that allows fetching an array of GPIO-s

So reset for AQR phy for other devices under OpenWrt don't really work?

Yes, in case where its not described as the MDIO bus reset.

Its one of the things that need to be sorted out as we will see more and more C45 only devices