Werner

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? 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

Would you mind sharing logs as described below? Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Try this one which has updated rockchip sdk kernel and check if nvme is visible: https://github.com/armbian/os/releases/download/25.2.0-trunk.299/Armbian_25.2.0-trunk.299_Orangepi5_trixie_vendor_6.1.84_minimal.img.xz

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

Expected since this image uses mainline 6.12.y kernel which has basic hdmi support at most. 6.13 will bring a few more features but there is still lots of things WIP. This image uses Rockchip SDK kernel which is almost feature-complete. You can use the build framework to create a clean KDE Plasma or Neon featuring image. Hm. The sdk kernel has been bumped in version shortly after the November release. Please try this image I made for testing if that detects the eMMC correctly: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5-plus_noble_vendor_6.1.84_kde-neon-kisak_desktop.img.xz

Indeed that .1 overvoltage can already make a difference. Check my ramble here about (over)voltage and SBCs

Hi, best way to follow mainline development is both the Collabora sheet here https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md and the Linux/U-Boot ARM patchwork: https://patchwork.kernel.org/project/linux-arm-kernel/list/ https://patchwork.ozlabs.org/project/uboot/list/ Though none of this exists for 6.1.y or older 5.10.y since these kernels are from Rockchip SDK (and these are not even public but leaked by people who have access) and nobody knows (at least I don't ) what or if they are working on at the moment. Closest in following this development is check the commit log here https://github.com/armbian/linux-rockchip or its forks. Maybe somebody works on something: https://github.com/armbian/linux-rockchip/network

Yes, probably. Basic kernel support should be there in both vendor and (I guess) with 6.14 mainline dtb being pushed. So it narrows down to wifi drivers and some tweaks and maybe dts issues. Feel free to dive into.

This is an unsupported (community/staging/whatever you wanna call it) board and those do not get stable build. Become a maintainer and change it

As mentioned it was just a guess. Maybe something else is missing. Flaw in dts maybe? Dunno. Anyone who has some spare time might dive into and check. Armbian core team probably won't anytime soon, simply due to lack of human resources We highly appreciate contributions from our community.

My guess is that they backported patches which were merged into 6.13 and still in the pipeline. It is still on decision if we want to go through the pain backporting HDMI stuff to 6.12 LTS (our current) or simply drop everything related to that and tell users to follow edge (or stick with vendor which works very well) which will be 6.13, 6.14 and so on until a new LTS kernel is released. For server applications stability is more critical and HDMI is not needed there in most cases.

Yes you missed it https://github.com/armbian/community/releases/tag/25.2.0-trunk.266

Yes, apologies. I forgot that KERNEL_CONFIGURE is also deprecated. Anyway there is a nice write-up on how to deal with this the modern way: https://zuckerbude.org/armbian-using-kernel-config/

Fact is the Opi5, just like many other SBCs actually prefer being fed with slight over-voltage to compensate for losses across wiring and connectors. This is why, for example, the official PSU from RaspberryPi is labeled with 5.1 volts output and the official PSU from Orangepi, even though labaled as 5V actually outputs around 5.2 volts. The reason is that with such low voltages losses as mentioned across wiring and connectors become significant and the voltage will drop even further on load spikes. A while ago I did some measurements on my opi5 so I could experience and see the voltage drops by myself. For that I measured both output voltage at the PSU, which was 5.2 volts, and at on of the USB-A ports of the OPi5 which were at around 5.1 volts while the board being idle. 0.1 volts loss across wires, connectors and the PCB just for being powered on and doing nothing. Putting a heavy load on the board and the voltage dropped to something between 4.8 and 4.9 volts across everything except PSU which kept its voltage constant. At least my meter could not detect a drop higher than 10mV. Now thing about having a bad/crappy PSU. It is VERY likely that the voltage also breaks down directly at the source which adds up across the already mentioned losses. And boom, your board throws all kinds of issues which are hard to explain. Just because of undervoltage.

Is /boot/boot.env present?

Easiest is probably to copy the whole /boot directory. Make sure to adjust the UUID in armbianEnv.txt to match the target sdcard. Otherwise boot will probably stuck in initramfs. Use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } blkid to get the value.

mainline support is still under heavy development. Don't expect that 6.13 will magically make everything work properly. In fact for now the best - close to feature-complete - experience on this soc, rockchip sdk based kernel (6.1.y vendor to say) is the way to go until mainline is more matured. It took years for RK3399 to mature decently. The same is expected for RK3588 and its derivates. The only advantage there is this time, is the fact that collabora invests in its support and provides the development results for free as open source.

Have you tried with the image I linked above? This is based around updated rockchip sdk kernel.

Use vendor kernel based images, 6.1.y to say. I assume you tried mainline. Mainline images are known having incomplete hdmi support. This will be better once kernel 6.13 images are available. For even better experience check for images with mesa-vpu extension or build such by by yourself. Try these just for fun if you want: should include everything. https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5-plus_noble_vendor_6.1.84_kde-neon-kisak_desktop.img.xz https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5_noble_vendor_6.1.84_kde-neon-kisak_desktop.img.xz

Easiest is probably to build a custom set of packages including headers. With the build framework this is quite simple. Clone repo https://github.com/armbian/build/ code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=odroidn2 BRANCH=current KERNEL_CONFIGURE=no kernel Copy the debs from output/debs folder to the board and install them via code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg -i

Change everything to known-good - sdcard - PSU - cables (!) - Armbian image If the behavior does not change the board is probably broken.

double-check which board you actually have so matching packages can be built. deprecated Never heard of that branch before. Try ./compile.sh BOARD=orangepizero3 KERNEL_CONFIGURE=yes kernel Adjust kernel config as needed. Check with Google or similar for necessary options to use KVM. Then check output/debs folder.

Have you read https://docs.armbian.com/User-Guide_Recovery/#replacing-boot ? There is also procedure how to extract the contents of .debs to the sdcard without chroot.

Hi, I don't there is a mechanism yet to just build this package. Because you are using an x86 machine and then the build framework uses cross compiling to create armhf/arm64 binaries.

There is an armbian-firmware package. I suggest to push your adjustments there: https://github.com/armbian/firmware/