Likely a kernel issue at a guess. I went back to an old build using bookworm but with 5.x and had similar issues although I could boot with USB devices plugged in and then detected, I got many USB bus reset errors and the device was unusable. Is the correct route here to file a bug?

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: Werner <werner@armbian.com> Date: Thu, 9 Jan 2025 05:55:04 +0100 Subject: Patching kernel rockchip64 files 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: Werner <werner@armbian.com> --- 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 + 4 files changed, 10 insertions(+), 1 deletion(-) 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 ad868e8d195d..fae699054c51 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -601,10 +601,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.

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

In the meantime, the difference between the two initramfs images lsinitramfs revealed is conf/conf.d/zz-resume-auto. This is generated by mkinitramfs in case there is a RESUME variable set, which is expected to be a path or UUID to a swap partition, for suspend-to-disk functionality. Searching for it in DuckDuckGo gives kernel panic reports as 3 of 5 first results, though mostly due to a syntax error in this script, which I would expect to be fixed, or non-existing swap partition UUID. On the host (outside the initramfs), there is no other initramfs-tools config than the default, which does not define RESUME, and there is (has never been) a swap partition in our or Armbian images, but at best a swap file on the root filesystem. So I wonder why this script is generated. Since I could not find any reason in initramfs or kernel maintainer/postinst scripts or configs, I guess the kernel itself somehow must ask/trigger initramfs-tools to generate it. It however can not contain anything correct, but either nothing or false content, as there is no swap partition. Sadly the user who helped investigating initially set up the system freshly now, hence cannot further help, checking the content of this script and whether it can be prevented via RESUME=none in initramfs-tools config. I can further investigate myself from January 17th on. However, while this script, and the kernel panic in search results seem very suspicious, it might be the wrong track. But so far it is the only trace I was able to find 😉.

Hello Developers, I ran into some issues installing the latest release on an Orange Pi 5 Plus. The images I downloaded are as follows: Armbian_24.11.2_Orangepi5-plus_noble_current_6.12.0_kde-neon-kisak_desktop.img.xz Armbian_24.11.2_Orangepi5-plus_noble_vendor_6.1.75_gnome-kisak_desktop.img.xz The KDE version will install and boot from the 256GB emmc drive, however it only works if there is a 4K HDMI monitor attached to HDMI1, I was not able to get it to display on a 1920x1200 HDMI monitor nor a USB connected or HDMI connected portable display (2560x1440). The Gnome version will boot with any of those 4 types of displays (4K HDMI, 1920x1200 HDMI and USB C or USB C to HDMI portable display) so in the end I would most likely install the GNOME version and then add KDE or Enlightenment packages to it since I don't like GNOME at all (20 yrs Debian/XFCE4 user). There is one issue I have with the GNOME version: It does not detect the emmc drive and only the SD card and the 500 GB NVME drives are showing up in gparted and fdisk. I am looking forward to using Armbian on an Orange Pi 5 Plus as my daily desktop and I hope this can be easily resolved. I am open to using either version as long as I can use a portable USB C or HDMI display with less than 4K resolution. thanks -ali