Search the Community
Showing results for tags 'nanopi-m5'.
Found 2 results
-
Hi, I would like to report an issue I encountered while testing the new NanoPi M5 UFS boot support in Armbian 26.5.1. Board: NanoPi M5 Boot media for installation: SD card Target storage: onboard UFS BOOT switch after installation: UFS/SD Tested images: * `Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img.xz` * `Armbian_26.5.1_Nanopi-m5_trixie_current_6.18.33_minimal.img.xz` My current NVMe setup uses a custom layout: * `ext4` `/boot` * `btrfs` `/` I had to use this layout because, in my previous NVMe tests, installing the system directly to NVMe with btrfs using `armbian-install` did not boot when `/boot` was also located on btrfs. With a separate ext4 `/boot` partition and a btrfs root filesystem, the NVMe setup works correctly. When testing the new UFS installation path, I noticed that the UFS option in `armbian-install` seems to only install the whole system to `/dev/sda1` on the UFS General LUN. Unlike the NVMe installation path, I could not find a way to select an existing target partition or use a manually prepared partition layout. I tried the following UFS layout manually: * `/dev/sda1` as `ext4` for `/boot` * `/dev/sda2` as `btrfs` for `/` However, after splitting the UFS General LUN this way, the system did not boot at all. I also tested the default UFS installation path without manually changing the partition layout. I booted from SD card, ran `armbian-install`, selected the UFS install option, and selected btrfs as the filesystem. With both tested images listed above, the installation process completed, but after removing the SD card and booting from UFS with the BOOT switch set to UFS/SD, the system did not boot. So the behavior I observed is: * UFS installation creates and uses only `/dev/sda1` as the system partition. * UFS installation with btrfs selected completes, but the installed system does not boot afterward. * A manual layout with separate `ext4 /boot` and `btrfs /` on UFS also does not boot. * The UFS install path does not seem to provide the same manual partition selection behavior as the NVMe install path. My questions are: 1. Is btrfs on UFS expected to be bootable at this stage? 2. Or should ext4 currently be considered the only supported/recommended filesystem for UFS boot on NanoPi M5? -
**Board:** NanoPi M5 (RK3576) **Kernel:** 6.18.33-current-rockchip64 (#1 SMP PREEMPT Sat May 23 11:07:21 UTC 2026) **Armbian build:** v26.8.0-trunk.53 ## Problem Gigabit RX is completely non-functional on `end0` (GMAC0, `ethernet@2a220000`). The interface comes up at 1000Mb/s, TX works, but no packets are ever received. DHCP never gets an OFFER, `ethtool -S end0` shows RX counters stuck at zero. Forcing 100Mb/s via `ethtool -s end0 speed 100 duplex full autoneg off` works around the issue — RX starts working immediately. ## Root cause The DTB sets `phy-mode = "rgmii-id"` together with `rx_delay = <0x3f>`. The RTL8211F PHY in `-id` mode already applies its own internal RX delay, and the driver applies an additional hardware delay on top of it. The double delay breaks gigabit RX entirely. ``` # /boot/dtb/rockchip/rk3576-nanopi-m5.dtb — broken phy-mode = "rgmii-id"; tx_delay = <0x21>; rx_delay = <0x3f>; # <-- causes double RX delay ``` ## Fix Change `phy-mode` to `rgmii-rxid` (PHY applies RX delay internally) and remove `rx_delay`. This applies to both GMAC0 (`ethernet@2a220000`) and GMAC1 (`ethernet@2a230000`). ``` # Fixed phy-mode = "rgmii-rxid"; tx_delay = <0x21>; # rx_delay removed ``` After applying this fix gigabit works correctly at 1000Mb/s with full RX functionality. ## Workaround ```bash ethtool -s end0 speed 100 duplex full autoneg off ``` Or patch the DTB manually: ```bash dtc -I dtb -O dts -o /tmp/nanopi.dts /boot/dtb/rockchip/rk3576-nanopi-m5.dtb sed -i 's/phy-mode = "rgmii-id"/phy-mode = "rgmii-rxid"/g' /tmp/nanopi.dts sed -i '/rx_delay/d' /tmp/nanopi.dts dtc -I dts -O dtb -o /boot/dtb/rockchip/rk3576-nanopi-m5.dtb /tmp/nanopi.dts reboot ```