1791

I've compiled a build of this for my xr500 from Ansuel's repo, and it is working for me.

I merged this commit, which adds XR500 support. I used the dts files directly from that commit and added the nss modifications back to qcom-ipq8065-nighthawk.dtsi, which is shared between the r7800 and xr500.

Here is the commit on top of Ansuel's repo:

https://github.com/JordanP-Dev/openwrt/commit/228cfa7f1bafc2e09a71d1f14b01da63d131ca14

1 Like
1792

Please do try to help getting the xr500 supported in OpenWrt master first, doing that would help you and others to get (and keep!) this device supported long term. NSS support is then just an optimization, perhaps the icing on the cake (if you need throughput above ~500 MBit/s), but you're in a much better position if you have basic device support merged.

1 Like
1793

Just as a info... qca8k (dsa driver) + the nss gmac driver doesn't work... (driver doesn't register)

1794

That’s odd. The DSA driver, AFAIK, doesn’t handle GMAC PHY. The NSS GMAC driver did not load at all? What’s the default upstream GMAC driver? Does that work?

1795

Looks like a problem with the mdio interface adding some debug info

[    8.595122] (unnamed net_device) (uninitialized): mdio bus '37000000.mdio-mii' OK.
[    8.602204] libphy: PHY 37000000.mdio-mii:00 not found
[    8.609805] ipq8064-mdio 37000000.mdio (unnamed net_device) (uninitialized): PHY 37000000.mdio-mii:00 attach FAIL
[    8.614922] nss-gmac: probe of 37400000.ethernet failed with error -5

with the sysfs is present 37000000.mdio-mii:10

Also why our mdio address are switched?
In stock openwrt we have that gmac1 has mdio4 and gmac2 has mdio0...
In the qsdk configuration gmac1 --> mdio0 gmac2 --> mdio4

A wrong configuration on openwrt from ages?

(using the virtual mdio-gpio driver is the same, in sys i have the :10)

1796

I think it really depends on the board and how it’s wired, not just SoC.

From QSDK, my R7800 matches the ap148 config. The ap160 differs, and it has 3 GMACs wired up, so the MDIOs config are different for it.

1797

Hi @quarky,

what is the default behavior of nss, does it offload all or some traffic and how do i confirm the offload?
highly appreciate any clue on this.

Thanks and Regards,
Shyam

1798

If you have set up the necessary NSS firmware and drivers correctly, all wired traffic will be accelerated. I.e. if you test with utility like iperf3, all LAN-WAN traffic will show near zero router CPU usage.

Unfortunately we still haven’t yet figure out how to properly accelerate WiFi traffic.

1 Like
1799

Can't really find why qca8k doesn't work with the nss gmac driver... Looks like the driver doesn't init at all... thinking of porting the offload special function to the upstream gmac driver o.o

Just as a info I found something very interesting and surprising by qcom... The nss gmac driver doesn't actually enables the offload... the driver itself have the generic function to load the data_plane but the code only contains the slowpath functions...

It's the nss-drv that tells the gmac driver to load and use the nss offload functions...

I really think they use the same approach for everything else... (wifi offload for new target...)
Well let's have some fun with trying to add data_plane support to the upstream driver ahahah

3 Likes
1800

The NSS GMAC driver should load if the GMAC DTS (and probably the MDIO) nodes are defined with all the required properties. Are you using the same DTS definitions like the swconfig driver or are you using a new DTS from upstream?

1801

I'm using the dsa definition... but I notice that dsa doesn't work if the gmac driver is not compiled built-in

The definition is this... (with the same configuration, but using the swconfig definition all works)

&mdio0 {
	status = "okay";

	pinctrl-0 = <&mdio0_pins>;
	pinctrl-names = "default";

	switch@10 {
		compatible = "qca,qca8337";
		#address-cells = <1>;
		#size-cells = <0>;
		reg = <0x10>;

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				label = "cpu";
				ethernet = <&gmac1>;
				phy-mode = "rgmii-id";

				fixed-link {
					speed = <1000>;
					full-duplex;
				};
			};

			port@1 {
				reg = <1>;
				label = "lan1";
			};

			port@2 {
				reg = <2>;
				label = "lan2";
			};

			port@3 {
				reg = <3>;
				label = "lan3";
			};

			port@4 {
				reg = <4>;
				label = "lan4";
			};

			port@5 {
				reg = <5>;
				label = "wan";
			};

			/*
			port@6 {
					reg = <0>;
					label = "cpu";
					ethernet = <&gmac2>;
					phy-mode = "rgmii";

					fixed-link {
							speed = <1000>;
							full-duplex;
							pause;
							asym-pause;
					};
			};
			*/
		};
	};
};
1802

The GMAC drive probe will return -EIO (-5) under the following:

	prop = of_get_property(np, "mdiobus", NULL);
	if (!prop) {
		netdev_dbg(netdev, "cannot get 'mdiobus' property\n");
		ret = -EIO;
		goto mdiobus_init_fail;
	}

	mdio_node = of_find_node_by_phandle(be32_to_cpup(prop));
	if (!mdio_node) {
		netdev_dbg(netdev, "cannot find mdio node by phandle\n");
		ret = -EIO;
		goto mdiobus_init_fail;
	}

	mdio_plat = of_find_device_by_node(mdio_node);
	if (!mdio_plat) {
		netdev_dbg(netdev, "cannot find platform device from mdio node\n");
		of_node_put(mdio_node);
		ret = -EIO;
		goto mdiobus_init_fail;
	}

	gmacdev->miibus = dev_get_drvdata(&mdio_plat->dev);
	if (!gmacdev->miibus) {
		netdev_dbg(netdev, "cannot get mii bus reference from device data\n");
		of_node_put(mdio_node);
		ret = -EIO;
		goto mdiobus_init_fail;
	}

Most likely due to missing properties in DTS.

1803

The mdio registers correctly...

The error is triggered by

		SET_NETDEV_DEV(netdev, gmacdev->miibus->parent);

		/*
		 * Issue a phy_attach for the interface connected to a switch
		 */
#if (LINUX_VERSION_CODE <= KERNEL_VERSION(3, 8, 0))
		gmacdev->phydev = phy_attach(netdev,
						(const char *)phy_id, 0, phyif);
#else
		gmacdev->phydev = phy_attach(netdev,
						(const char *)phy_id, phyif);
#endif
		if (IS_ERR(gmacdev->phydev)) {
			netdev_dbg(netdev, "PHY %s attach FAIL\n", phy_id);
			ret = -EIO;
			goto nss_gmac_phy_attach_fail;
		}
1804

OK, then it looks like the DSA driver is also handling GMAC PHY layer as well. I thot DSA is a direct replacement for swconfig and it still requires the stmmac GMAC driver. For upstream, the stmmac driver is no longer required? NSS GMAC replaces the stmmac driver.

1805

mhh nope dsa still needs gmac for the dsa to work... (tested now and no init by dsa)

Wonder if the problem is that gmac is compiled as a module and is not built in...

I notice that dsa doesn't work if it's compiled as module and loaded after so i wonder if this is the problem?

Anyway the problem is that for some reason the nss gmac driver can't find the phy interface

1806

@quarky any hint on how to build the gmac driver directly in the kernel and not as a module?

Some more info... making the upstream gmac driver as a module doesn't cause any problem with the dsa... as soon as the gmac driver is loaded the dsa is probed and runs...

1 Like
1807

Well funny... when removing code actually fix things... It's from yesterday that i notice that phy_attach was used only on one broadcom driver and the upstream stmmac driver didn't use it at all...

Remove the phy_attach logic and bam... dsa works like magic o.O
Or could be related by wrong netdev register dev? will test...

@quarky while investigating some ath10k proprietary stuff I found something very interesting...

ansuel@Ansuel-XPS:~[redacted 1?!?!?]$ grep -rnw . -e qca-nss-drv
./Makefile:109: QCA_NSS_INCLUDE=$(STAGING_DIR)/usr/include/qca-nss-drv \
./os/linux/src/osif_nss_wifiol_li_vdev_if.c:66: * This file is responsible for interacting with qca-nss-drv's
./os/linux/src/osif_nss_wifiol_be_vdev_if.c:56: * This file is responsible for interacting with qca-nss-drv's
./os/linux/src/osif_nss_wifiol_vdev_if.c:68: * This file is responsible for interacting with qca-nss-drv's
4 Likes
1808

Where did you get those sources?

1809

The naming scheme looks strange but it could really be how they now implement wifi offload
From the codeaurora repo i think they just never pushed/removed any code about the wifi offload
The qca-wifi repo stop after QSDK 6 and the tree is empty

2 Likes
1810

I've been using this method ever since to test all of these builds. I have it connected to a raspberry pi setup as an AP. Nice to be able to test without needing the router to be "up", and if it fails to boot, it just reboots into the working 4.4 LEDE build :slight_smile:

Would you by any chance know how to flash the "factory.img" version from the console? I see the steps listed on the wiki but there's more commands listed and mentions doing an erase with specific NAND addresses. I know I can do the reset method and push from my server, rather just do it over the console.