Werner

No. You can build Armbian on any Linux machine if Docker is available. Check my workaround above. It just pulls the package from a random mirror (dotsrc in this case) and installs it via dpkg. Might be interesting to know which are necessary so they might get moved into standard firmware package to make this work oob.

Well rpi is partially proprietary and especially the boot process is handled completely different that other boards. However I found a workaround. No clue it if works, I don't have this board and probably never get one unless its a gift lol Main() { apt-get update apt-get -y install wget cd /root wget http://mirrors.dotsrc.org/armbian-apt/pool/main/a/armbian-firmware-full/armbian-firmware-full_24.11.2_all__1-SA8dbb-SM633e-B6c7f-R448a.deb dpkg -i *.deb } # Main Main "$@"

Confirmed. Well that's odd. Maybe bad luck to both of us having a bad mirror when attempting? Anyway have you checked if the armbian-firmware-full packages actually contains the necessary blobs you are looking for? Check github.com/armbian/firmware

Just checked and it seems like their Release file on the repo is still marked with ovm6 while the package you get when installing is omv7. Tried to build an image with omv pre-installed, but throw a bunch of errors, so no idea if it works. https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Rockpro64_bookworm_current_6.12.9-omv.img.xz If not grab a standard rockpro image ( https://dl.armbian.com/rockpro64/Bookworm_current_minimal ) and proceed according omv docs: https://docs.openmediavault.org/en/stable/installation/on_debian.html Keep in mind that omv heavily messes with the system, so if anything breaks after installation (like network access or even boot) we cannot help. This is userspace.

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.

Ah you have set SHARE_LOG to yes which is good in general but in this particular case isn't You can either - set this to no so you will be provided with the curl command or - additionally set PASTE_URL="https://paste.armbian.de/log"

Feel free to build an image with edge branch which is 6.13-rc...5..ish? I don't remember. Anyway this should give you a good idea about what to expect when it becomes stable after rc7.

Hi At the end of the build process you will provided with a curl command to send logs to https://paste.armbian.com/logs simply copy&paste this command to get the URL you are looking for Tip: If upload fails try replacing paste.armbian.com/logs with paste.armbian.de/logs or paste.armbian.eu/logs

never heard of that one before. image name and source? Edit: Found. You are not using Armbian but a fork. We cannot support 3rd party images. Ask at the place where you got the image from for help.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

There isn't much to it. tl;dr: clone the repo using git and execute ./compile.sh. Rest is interactive. https://docs.armbian.com/Developer-Guide_Build-Preparation/ Yes it is possible to include omv6(!) while building the image but there is actually not much to it doing by hand. This is basically how an Armbian omv-preinstalled image is made: https://github.com/armbian/os/blob/3c2bf37c3544f2d16ac12e1c407e6976367ec4d0/userpatches/extensions/omv.sh#L15-L35 tl;dr: grab omv key, install omv key, apt update, apt install openmediavault You can do that manually after first boot.

Build your image with code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ENABLE_EXTENSIONS=mesa-vpu. This will address necessary packages for acceleration, depending on which kernel you choose. For desktop usage I recommend going for vendor branch (kernel 6.1.y to say) as mainline is still under heavy development.

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

We provide just a very small selection of images for each hw and even that eats a lot into our resources. See https://docs.armbian.com/User-Guide_FAQ/#why-is-there-no-image-for-board-with-bookwormjammynobletrixie-and-minimalclignomekdexfce-with-vendorlegacycurrentedge-kernel However the build framework makes it very easy to combine whatever you want together. Just like the image I provided you https://docs.armbian.com/Developer-Guide_Build-Preparation/

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.