Orange pi 5 allow only 4 VLANs on Ethernet port

[Regela]

System Information: https://paste.armbian.com/mozehisomu

 

When i am trying to setup many vlan interfacces i have whis dmesg message:

 

rk_gmac-dwmac fe1c0000.ethernet eth0: MAC_VLAN_Tag_Filter full (size: 4)

 

interface info:

 

ethtool -i eth0
driver: st_gmac
version: Jan_2016
firmware-version: 
expansion-rom-version: 
bus-info: 
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

 

I need about 20-30 vlan interfaces

 

[dpsweigart]

I don’t suppose you ever found a workaround for this? Do we know if this is a driver or hardware issue?

[stihlee_dan]

I ran into the same issue. Trying to get PiMox setup on some OrangePi's and found that the OrangePi 5 only supports 4 vlans.

I believe I got a workaround working however. Executing CLI commands (haven't had time to test with /etc/network/interfaces or netplan) for 5 bridges (plus br0). My thought
process was to build separate vlans on the bridge and not vlan interfaces off of eth0. I'm sure this can be improved upon.

#Build bridges
ip link add name br0 address aa:ab:c0:26:f7:f0 up type bridge vlan_filtering 0 vlan_default_pvid 0
ip link add name br1 address aa:ab:c0:26:f7:01 up type bridge vlan_filtering 0 vlan_default_pvid 0
ip link add name br2 address aa:ab:c0:26:f7:02 up type bridge vlan_filtering 0 vlan_default_pvid 0
ip link add name br3 address aa:ab:c0:26:f7:03 up type bridge vlan_filtering 0 vlan_default_pvid 0
ip link add name br4 address aa:ab:c0:26:f7:04 up type bridge vlan_filtering 0 vlan_default_pvid 0
ip link add name br5 address aa:ab:c0:26:f7:05 up type bridge vlan_filtering 0 vlan_default_pvid 0

#Set uplink for br0
ip link set dev eth0 up master br0

# Add vlan to bridges
bridge vlan add vid 2-250 dev br0 self
bridge vlan add vid 1 dev br1 self
bridge vlan add vid 2 dev br2 self
bridge vlan add vid 3 dev br3 self
bridge vlan add vid 4 dev br4 self
bridge vlan add vid 5 dev br5 self

# Create sub-interfaces for each vlan and assign IP for bridges.
ip link add link br0 name br0.1 up type vlan id 1
ip addr add 192.168.101.2/24 dev br1

ip link add link br0 name br0.2 up type vlan id 2
ip addr add 192.168.102.2/24 dev br2

ip link add link br0 name br0.3 up type vlan id 3
ip addr add 192.168.103.2/24 dev br3

ip link add link br0 name br0.4 up type vlan id 4
ip addr add 192.168.104.2/24 dev br4

ip link add link br0 name br0.5 up type vlan id 5
ip addr ad 192.168.105.2/24 dev br5

# Set uplinks for bridges
ip link set dev br0.1 up master br1
ip link set dev br0.2 up master br2
ip link set dev br0.3 up master br3
ip link set dev br0.4 up master br4
ip link set dev br0.5 up master br5

[DeVILRuNNeR]

Did anybody figure this problem out?

I just also figured out this is still a problem on this onboard gmac ethernet adapter.

 

Apparently this is a driver problem and was resolved in immortalwrt or openwrt.

https://github.com/immortalwrt/immortalwrt/commit/07e476cac84e52d2f3d7d8afa9cbae57d9a97ffd

 

How would one go about fixing this for armbian?

 

[Werner]

I'd try to apply the patch manually with the kernel-patch command. I tried that with rockchip64-current which is 6.12.y atm

 

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: John Doe <john.doe@somewhere.on.planet>
Date: Thu, 9 Jan 2025 19:00:32 +0000
Subject: Patching kernel rockchip64 files
 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
 drivers/net/ethernet/realtek/r8169_main.c
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c include/linux/stmmac.h

Signed-off-by: John Doe <john.doe@somewhere.on.planet>
---
 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts   | 1 +
 drivers/net/ethernet/realtek/r8169_main.c             | 5 +++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c     | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +++
 include/linux/stmmac.h                                | 1 +
 5 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
index b39a3fc976b5..3461dbe3a78b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
@@ -178,10 +178,11 @@ &gmac1 {
 	pinctrl-0 = <&gmac1_miim
 		     &gmac1_tx_bus2
 		     &gmac1_rx_bus2
 		     &gmac1_rgmii_clk
 		     &gmac1_rgmii_bus>;
+	snps,no-vlhash;
 	pinctrl-names = "default";
 	tx_delay = <0x42>;
 	status = "okay";
 };
 
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 5ed2818bac25..5c5d45cb6087 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -19,10 +19,11 @@
 #include <linux/phy.h>
 #include <linux/if_vlan.h>
 #include <linux/in.h>
 #include <linux/io.h>
 #include <linux/ip.h>
+#include <linux/of.h>
 #include <linux/tcp.h>
 #include <linux/interrupt.h>
 #include <linux/dma-mapping.h>
 #include <linux/pm_runtime.h>
 #include <linux/bitfield.h>
@@ -5375,17 +5376,21 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
 	struct rtl8169_private *tp;
 	int jumbo_max, region, rc;
 	enum mac_version chipset;
 	struct net_device *dev;
+	const char *devname = of_get_property(pdev->dev.of_node, "label", NULL);
 	u32 txconfig;
 	u16 xid;
 
 	dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
 	if (!dev)
 		return -ENOMEM;
 
+	if (devname)
+		strscpy(dev->name, devname, IFNAMSIZ);
+
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	dev->netdev_ops = &rtl_netdev_ops;
 	tp = netdev_priv(dev);
 	tp->dev = dev;
 	tp->pci_dev = pdev;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d65ab43fa5d6..21cb04ced88e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7648,11 +7648,11 @@ int stmmac_dvr_probe(struct device *device,
 	ndev->features |= NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_STAG_RX;
 	if (priv->plat->has_gmac4) {
 		ndev->hw_features |= NETIF_F_HW_VLAN_CTAG_RX;
 		priv->hw->hw_vlan_en = true;
 	}
-	if (priv->dma_cap.vlhash) {
+	if (priv->plat->vlhash_en && priv->dma_cap.vlhash) {
 		ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
 		ndev->features |= NETIF_F_HW_VLAN_STAG_FILTER;
 	}
 	if (priv->dma_cap.vlins) {
 		ndev->features |= NETIF_F_HW_VLAN_CTAG_TX;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index aaf008bdbbcd..cccc48956024 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -587,10 +587,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
 		plat->force_sf_dma_mode = 0;
 		dev_warn(&pdev->dev,
 			 "force_sf_dma_mode is ignored if force_thresh_dma_mode is set.\n");
 	}
 
+	/* To disable VLAN tag filter */
+	plat->vlhash_en = !of_property_read_bool(np, "snps,no-vlhash");
+
 	of_property_read_u32(np, "snps,ps-speed", &plat->mac_port_sel_speed);
 
 	plat->axi = stmmac_axi_setup(pdev);
 
 	rc = stmmac_mtl_setup(pdev, plat);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index d79ff252cfdc..9b8b5b27851b 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -260,10 +260,11 @@ struct plat_stmmacenet_data {
 	struct stmmac_axi *axi;
 	int has_gmac4;
 	int rss_en;
 	int mac_port_sel_speed;
 	int has_xgmac;
+	bool vlhash_en;
 	u8 vlan_fail_q;
 	unsigned int eee_usecs_rate;
 	struct pci_dev *pdev;
 	int int_snapshot_num;
 	int msi_mac_vec;
-- 
Created with Armbian build tools https://github.com/armbian/build

 

This is missing the additional line in the dts which I added manually. No idea if it is correctly applied, builds or works.

If it does dts change must be added and patch rewritten to match initial author.

 

Edit: Building works

Edit2: Fix patch to include dts patch

[DeVILRuNNeR]

That is amazing !

Are you able to have more then 4 VLANs on this interface?

 

Perhaps a stupid question but how can I apply this potential fix to my GMAC driver?

 

On a side note: I am running a NanoPI R6C that only has 2 interfaces; yet it's showing 3 interfaces available to me 🤐

 

 

[Werner]

1 hour ago, DeVILRuNNeR said:

NanoPI R6C that only has 2 interfaces; yet it's showing 3 interfaces available t

This sounds like you use the dtb for the R6S model which has 3 interfaces. Can you double-check which dtb is used when booting?

 

1 hour ago, DeVILRuNNeR said:

Are you able to have more then 4 VLANs on this interface?

I have no idea about VLANs and how to use this stuff. I'm not a networking guy. I was just curios if I can apply the changes from openwrt to our mainline linux tree and if it compiles. Testing is up to others

 

[DeVILRuNNeR]

More then willing to test on my NanoPi but not sure how I would need to compile 🙄

[Werner]

I recreated the patch to include dts patch for the r6c.

 

You can test this image which should include it: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Nanopi-r6c_bookworm_current_6.12.9_minimal.img.xz

[eselarm]

22 hours ago, Werner said:

You can test this image which should include it: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Nanopi-r6c_bookworm_current_6.12.9_minimal.img.xz

I have copied the kernel+DTB and regenerated initrd and uInitrd on my Armbian NanoPi-R6C rootfs, set those as boot instead of 6.12.6-current-rockchip-rk3588
Reboot works, but still the limit of 4. And also no network connection as I use bridges and also wan (GMAC 1G) itself counts as VLAN 0

But if I do nmcli con down <a currently unused test VLAN>, there is room for VLAN 0 (done all via serial console), then base LAN connection is there.

 

I have lan1 (realtek 2.5G) unused, workaround would be to use that for the single RJ45 cable connected to the NanoPi-R6C, but plan was/is to use that for other point-to-point link.

So I think I will need a closer look and see what could be wrong.

 

[DeVILRuNNeR]

I was running the UEFI generic build with the 6.12 kernel and dtbs applied through the grub loader.

 

I didn't feel like going through all these hoops anymore and went back to the friendlyelec builds that work fine.

No vlan or driver issues there. Not what i really wanted but this is just to much weird issues.

 

Note: tried installing or running their kernel.deb that i have but refused to install. It complained about some board or machine info (in /proc) not being there. This dtb, DTS, dtbo thing is really sh*t and a shame on arm platforms compared to amd64.

Edited Friday at 10:01 PM by DeVILRuNNeR

[Werner]

9 hours ago, DeVILRuNNeR said:

This dtb, DTS, dtbo thing is really sh*t and a shame on arm platforms compared to amd64.

If you want an arm64 board that behaves like and x86 this is possible, but you have to spend a lot of money. You get is what you pay for.

[Igor]

10 hours ago, DeVILRuNNeR said:

is really sh*t and a shame on arm platforms compared to amd64.

 

tl;dr; Custom hardware world is fundamentally different then standard desktop amd64 PC. HW designers stream toward uniqueness in order to stand out from another one, which cause after market software support, where vendor in question is not involved at all, nightmare.

 

You will always be happy with a new toy they produced "and works fine" and unhappy with the only existing community aftermarket software support, which is abused by HW dealers and their customers.

 

10 hours ago, DeVILRuNNeR said:

friendlyelec builds that work fine.

Demo software support is designed to give a feeling that what you purchased works well - and they focus into their special hw functions only with some old kernel. And this will only work if you don't change much. You want more recent Linux? Sure. But costs of that are insane ... and you (all customers / community together) are not willing to cover not even a percentage of that. But still you want & expect

 

 

insane expensive firmware operations every day  

[DeVILRuNNeR]

Thanks for your feedback all.

 

To look on the positives: I have learned allot from these endeavours. My overall key take away is that off the shelf software support or available images is key with this kind of hardware. 

Any 'hacking' or custom builds is going to cost way more then the hardware itself and as this example proved might not even work at all.

 

Hope these gmac driver issues get sorted for the Future but for now I am going to run thé vendor images.

Edited Sunday at 08:58 AM by DeVILRuNNeR

[eselarm]

Small update: As expected, 4+  VLANs work when lan1 is used on my NanoPi-R6C (and with 6.12.6 I had running/installed 3 weeks ago). I basically can work with the limitation on the wan port as for normal planned use-case, I do not need more than 3 VLANs, but any test/trial/experiment is impossible then (I have 9 or more VLANs around in my managed switches).

 

I copied the NM config files to my Rock3A, there is is no problem (but other U-Boot, kernel 6.12.6-edge-rockchip64, Noble instead of Bookworm). I do not understand various details of the patch, for example why is something in the realtek driver needed and not just the STM based MAC driver. I need better understanding first, otherwise I think this is above my skills. It might also be that the Gbit port silicon in the RK3568 is newer than the one in RK3588(S).

[Werner]

Hm even though that's probably an edge case it would be nice to know if the workaround of openwrt actually works and why for Armbian it does not....