The NanoPi R28S is a dual gigabit Ethernet router board based on the
Rockchip RK3528 SoC:
https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R28S
It is closely related to the already supported NanoPi Zero2, sharing
most of its power tree and peripheral routing. Patch 2 therefore moves
the common parts into rk3528-nanopi.dtsi, and patch 3 adds the board on
top of it. The split leaves the NanoPi Zero2 dtb unchanged; I verified
this by decompiling the dtb before and after the split and comparing
them with the phandle numbering normalised.
The devicetree was derived from the vendor tree:
https://github.com/friendlyarm/kernel-rockchip/commit/ee640c5344b13a0a317436e2357df01af8268ce7
but with many changes to make it suitable for mainline.
Tested on a metal-case unit without the optional onboard eMMC: boots
from microSD, both Ethernet ports link up at 1000 Mbps, the HYM8563 RTC
registers, and all three LEDs are functional. The USB Type-C connector
registers as a DWC3 UDC in peripheral mode; gadget enumeration against
a USB host was not completed, because that connector is also the 5V
input and a PC port cannot power the board.
Two things I did not do, because my hardware cannot verify them:
- The AICSemi AIC8800D80 WiFi chip on sdio0 has no upstream driver, so
only the SDIO controller is described.
- The eMMC is described as HS200 rather than the vendor's HS400 with
enhanced strobe, since the board at hand has an unpopulated eMMC
footprint and the faster modes could not be verified.
---
Changes in v2:
- Split the parts shared with the NanoPi Zero2 into a new
rk3528-nanopi.dtsi (new patch 2). The NanoPi Zero2 dtb is unchanged.
- Name the pinctrl labels after the nets in the schematic: usr_btn,
led1, led2, led_sys, pwr_wf and pcie_eth_perstb.
- Rename the button node to button-user and its label to "USER".
- Link to v1: https://patch.msgid.link/20260905-r28s-upstream-v1-0-f68d5389269a@proton.me
---
安容 (3):
dt-bindings: arm: rockchip: Add FriendlyElec NanoPi R28S
arm64: dts: rockchip: Split out the common NanoPi RK3528 parts
arm64: dts: rockchip: Add devicetree for the FriendlyElec NanoPi R28S
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../arm64/boot/dts/rockchip/rk3528-nanopi-r28s.dts | 142 +++++++++++
.../boot/dts/rockchip/rk3528-nanopi-zero2.dts | 271 +-------------------
arch/arm64/boot/dts/rockchip/rk3528-nanopi.dtsi | 279 +++++++++++++++++++++
5 files changed, 428 insertions(+), 270 deletions(-)
---
base-commit: 32e0f64640d558a0f5410ac5cdd8ebf371c5e6a6
change-id: 20260905-r28s-upstream-e212e27d6165
Best regards,
--
安容 [off-list ref]
From: 安容 <redacted>
The FriendlyElec NanoPi Zero2 and the NanoPi R28S share their power
tree, storage, RGMII Ethernet, RTC and debug console. Move those parts
into rk3528-nanopi.dtsi so the NanoPi R28S can reuse them, and leave
only the board specific nodes in the NanoPi Zero2 devicetree.
Suggested-by: Chukun Pan <redacted>
Signed-off-by: 安容 <redacted>
---
.../boot/dts/rockchip/rk3528-nanopi-zero2.dts | 271 +-------------------
arch/arm64/boot/dts/rockchip/rk3528-nanopi.dtsi | 279 +++++++++++++++++++++
2 files changed, 280 insertions(+), 270 deletions(-)
From: 安容 <redacted>
The NanoPi R28S is a dual gigabit Ethernet router board based on the
Rockchip RK3528 SoC, designed and developed by FriendlyElec. It shares
most of its design with the NanoPi Zero2, so it builds on the common
rk3528-nanopi.dtsi.
Specification:
- Rockchip RK3528
- 1GB RAM
- eMMC socket (optional)
- MicroSD slot
- 1x 1000Base-T (GMAC1, Realtek RTL8211F)
- 1x 1000Base-T (PCIe, Realtek RTL8111H)
- AICSemi AIC8800D80 SDIO WiFi
- 3x LEDs (SYS, LAN, WAN)
- 1x USB 2.0 Type-C, peripheral only, shared with the 5V power input
- User and MaskROM buttons
- Haoyu HYM8563 RTC
- 1x USB Type-C debug UART (onboard WCH CH340E)
Assisted-by: LLM
Signed-off-by: 安容 <redacted>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../arm64/boot/dts/rockchip/rk3528-nanopi-r28s.dts | 142 +++++++++++++++++++++
2 files changed, 143 insertions(+)
@@ -0,0 +1,142 @@+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)+/*+*Copyright(c)2022RockchipElectronicsCo.,Ltd.+*Copyright(c)2026FriendlyElecComputerTech.Co.,Ltd.+*Copyright(c)2026安容<HystericalDragons@proton.me>+*/++/dts-v1/;++#include<dt-bindings/leds/common.h>+#include"rk3528-nanopi.dtsi"++/{+model="FriendlyElec NanoPi R28S";+compatible="friendlyarm,nanopi-r28s","rockchip,rk3528";++aliases{+mmc2=&sdio0;+};++gpio-keys{+compatible="gpio-keys";+pinctrl-names="default";+pinctrl-0=<&usr_btn>;++button-user{+debounce-interval=<50>;+gpios=<&gpio4RK_PB2GPIO_ACTIVE_LOW>;+label="USER";+linux,code=<KEY_RESTART>;+wakeup-source;+};+};++leds{+compatible="gpio-leds";+pinctrl-names="default";+pinctrl-0=<&led1>,<&led2>,<&led_sys>;++led-lan{+color=<LED_COLOR_ID_GREEN>;+default-state="off";+function=LED_FUNCTION_LAN;+gpios=<&gpio4RK_PB3GPIO_ACTIVE_HIGH>;+linux,default-trigger="netdev";+};++led-sys{+color=<LED_COLOR_ID_RED>;+default-state="on";+function=LED_FUNCTION_HEARTBEAT;+gpios=<&gpio4RK_PB0GPIO_ACTIVE_HIGH>;+linux,default-trigger="heartbeat";+};++led-wan{+color=<LED_COLOR_ID_GREEN>;+default-state="off";+function=LED_FUNCTION_WAN;+gpios=<&gpio4RK_PB1GPIO_ACTIVE_HIGH>;+linux,default-trigger="netdev";+};+};++sdio_pwrseq:sdio-pwrseq{+compatible="mmc-pwrseq-simple";+pinctrl-names="default";+pinctrl-0=<&pwr_wf>;+post-power-on-delay-ms=<100>;+reset-gpios=<&gpio1RK_PC2GPIO_ACTIVE_LOW>;+};+};++&combphy{+status="okay";+};++&pcie{+pinctrl-names="default";+pinctrl-0=<&pcie_eth_perstb>;+reset-gpios=<&gpio4RK_PC0GPIO_ACTIVE_HIGH>;+vpcie3v3-supply=<&vcc_3v3>;+status="okay";+};++&pinctrl{+gpio-keys{+usr_btn:usr-btn{+rockchip,pins=<4RK_PB2RK_FUNC_GPIO&pcfg_pull_up>;+};+};++leds{+led1:led1{+rockchip,pins=<4RK_PB1RK_FUNC_GPIO&pcfg_pull_none>;+};++led2:led2{+rockchip,pins=<4RK_PB3RK_FUNC_GPIO&pcfg_pull_none>;+};++led_sys:led-sys{+rockchip,pins=<4RK_PB0RK_FUNC_GPIO&pcfg_pull_none>;+};+};++pcie{+pcie_eth_perstb:pcie-eth-perstb{+rockchip,pins=<4RK_PC0RK_FUNC_GPIO&pcfg_pull_none>;+};+};++wifi{+pwr_wf:pwr-wf{+rockchip,pins=<1RK_PC2RK_FUNC_GPIO&pcfg_pull_none>;+};+};+};++&sdio0{+bus-width=<4>;+cap-sd-highspeed;+cap-sdio-irq;+keep-power-in-suspend;+mmc-pwrseq=<&sdio_pwrseq>;+non-removable;+sd-uhs-sdr104;+vqmmc-supply=<&vcc_1v8>;+status="okay";+};++&uart2{+pinctrl-names="default";+pinctrl-0=<&uart2m1_xfer>,<&uart2m1_ctsn>,<&uart2m1_rtsn>;+uart-has-rtscts;+status="okay";+};++&usb_host0_xhci{+/* Type-C port, shared with the 5V power input */+dr_mode="peripheral";+};
From: Diederik de Haas <hidden> Date: 2026-09-09 10:53:31
On Mon Sep 7, 2026 at 4:13 PM CEST, 安容 via B4 Relay wrote:
quoted hunk
From: 安容 <redacted>
The NanoPi R28S is a dual gigabit Ethernet router board based on the
Rockchip RK3528 SoC, designed and developed by FriendlyElec. It shares
most of its design with the NanoPi Zero2, so it builds on the common
rk3528-nanopi.dtsi.
Specification:
- Rockchip RK3528
- 1GB RAM
- eMMC socket (optional)
- MicroSD slot
- 1x 1000Base-T (GMAC1, Realtek RTL8211F)
- 1x 1000Base-T (PCIe, Realtek RTL8111H)
- AICSemi AIC8800D80 SDIO WiFi
- 3x LEDs (SYS, LAN, WAN)
- 1x USB 2.0 Type-C, peripheral only, shared with the 5V power input
- User and MaskROM buttons
- Haoyu HYM8563 RTC
- 1x USB Type-C debug UART (onboard WCH CH340E)
Assisted-by: LLM
Signed-off-by: 安容 <redacted>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../arm64/boot/dts/rockchip/rk3528-nanopi-r28s.dts | 142 +++++++++++++++++++++
2 files changed, 143 insertions(+)
If you run
``scripts/dtc/dt-check-style --mode=strict arch/arm64/boot/dts/rockchip/rk3528-nanopi-r28s.dts``
it will find a few (IMO) false-positives, but the property order of
pinctrl-0/pinctrl-names is valid and a blank line preceeding ``status`` too.
Cheers,
Diederik
@@ -0,0 +1,142 @@+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)+/*+*Copyright(c)2022RockchipElectronicsCo.,Ltd.+*Copyright(c)2026FriendlyElecComputerTech.Co.,Ltd.+*Copyright(c)2026安容<HystericalDragons@proton.me>+*/++/dts-v1/;++#include<dt-bindings/leds/common.h>+#include"rk3528-nanopi.dtsi"++/{+model="FriendlyElec NanoPi R28S";+compatible="friendlyarm,nanopi-r28s","rockchip,rk3528";++aliases{+mmc2=&sdio0;+};++gpio-keys{+compatible="gpio-keys";+pinctrl-names="default";+pinctrl-0=<&usr_btn>;++button-user{+debounce-interval=<50>;+gpios=<&gpio4RK_PB2GPIO_ACTIVE_LOW>;+label="USER";+linux,code=<KEY_RESTART>;+wakeup-source;+};+};++leds{+compatible="gpio-leds";+pinctrl-names="default";+pinctrl-0=<&led1>,<&led2>,<&led_sys>;++led-lan{+color=<LED_COLOR_ID_GREEN>;+default-state="off";+function=LED_FUNCTION_LAN;+gpios=<&gpio4RK_PB3GPIO_ACTIVE_HIGH>;+linux,default-trigger="netdev";+};++led-sys{+color=<LED_COLOR_ID_RED>;+default-state="on";+function=LED_FUNCTION_HEARTBEAT;+gpios=<&gpio4RK_PB0GPIO_ACTIVE_HIGH>;+linux,default-trigger="heartbeat";+};++led-wan{+color=<LED_COLOR_ID_GREEN>;+default-state="off";+function=LED_FUNCTION_WAN;+gpios=<&gpio4RK_PB1GPIO_ACTIVE_HIGH>;+linux,default-trigger="netdev";+};+};++sdio_pwrseq:sdio-pwrseq{+compatible="mmc-pwrseq-simple";+pinctrl-names="default";+pinctrl-0=<&pwr_wf>;+post-power-on-delay-ms=<100>;+reset-gpios=<&gpio1RK_PC2GPIO_ACTIVE_LOW>;+};+};++&combphy{+status="okay";+};++&pcie{+pinctrl-names="default";+pinctrl-0=<&pcie_eth_perstb>;+reset-gpios=<&gpio4RK_PC0GPIO_ACTIVE_HIGH>;+vpcie3v3-supply=<&vcc_3v3>;+status="okay";+};++&pinctrl{+gpio-keys{+usr_btn:usr-btn{+rockchip,pins=<4RK_PB2RK_FUNC_GPIO&pcfg_pull_up>;+};+};++leds{+led1:led1{+rockchip,pins=<4RK_PB1RK_FUNC_GPIO&pcfg_pull_none>;+};++led2:led2{+rockchip,pins=<4RK_PB3RK_FUNC_GPIO&pcfg_pull_none>;+};++led_sys:led-sys{+rockchip,pins=<4RK_PB0RK_FUNC_GPIO&pcfg_pull_none>;+};+};++pcie{+pcie_eth_perstb:pcie-eth-perstb{+rockchip,pins=<4RK_PC0RK_FUNC_GPIO&pcfg_pull_none>;+};+};++wifi{+pwr_wf:pwr-wf{+rockchip,pins=<1RK_PC2RK_FUNC_GPIO&pcfg_pull_none>;+};+};+};++&sdio0{+bus-width=<4>;+cap-sd-highspeed;+cap-sdio-irq;+keep-power-in-suspend;+mmc-pwrseq=<&sdio_pwrseq>;+non-removable;+sd-uhs-sdr104;+vqmmc-supply=<&vcc_1v8>;+status="okay";+};++&uart2{+pinctrl-names="default";+pinctrl-0=<&uart2m1_xfer>,<&uart2m1_ctsn>,<&uart2m1_rtsn>;+uart-has-rtscts;+status="okay";+};++&usb_host0_xhci{+/* Type-C port, shared with the 5V power input */+dr_mode="peripheral";+};
This is carried over unchanged from the NanoPi Zero2, so not something
this patch introduces, but it is worth fixing while the node is being
moved, because as written the port depends on the bootloader.
of_mdio_bus_register() reads the PHY ID with get_phy_device() before
phy_device_register() fetches the PHY node's reset-gpios, so a PHY that
the bootloader left in reset is simply not found:
mdio_bus stmmac-0: MDIO device at address 1 is missing.
I hit exactly that on a NanoPi R28S booted with mainline U-Boot
(generic-rk3528), which does not touch that pin - the RGMII port never
came up. Describing the reset on the MAC instead makes stmmac install it
as mii_bus->reset, which runs before the bus is scanned:
&gmac1 {
snps,reset-active-low;
snps,reset-delays-us = <0 20000 100000>;
snps,reset-gpio = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
};
with &gmac1_rstn_l moved to the MAC's pinctrl-0 and the three reset
properties dropped from the PHY node. Then the port comes up whatever
the bootloader did, on both boards. Armbian carries the same change for
the NanoPi Zero2, for the same reason.
I had an R28S series of my own out before I saw yours; I am dropping it.
Happy to test this one on the hardware and send a Tested-by.
Andrey
On Wed, Sep 09, 2026 at 04:47:16PM +0300, Andrey Korshunov wrote:
of_mdio_bus_register() reads the PHY ID with get_phy_device() before
phy_device_register() fetches the PHY node's reset-gpios, so a PHY that
the bootloader left in reset is simply not found:
mdio_bus stmmac-0: MDIO device at address 1 is missing.
Thanks, the diagnosis is right and I have reproduced the ordering in
the code: `__of_mdiobus_register()` registers the bus before it walks the
children. And for a PHY node with only the generic c22 compatible,
`fwnode_mdiobus_register_phy()` reads the PHY ID via `get_phy_device()`
before `phy_device_register()` gets as far as requesting reset-gpios.
Describing the reset on the MAC instead makes stmmac install it
as mii_bus->reset, which runs before the bus is scanned:
&gmac1 {
snps,reset-active-low;
snps,reset-delays-us = <0 20000 100000>;
snps,reset-gpio = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
};
But I would rather not use those: snps,reset-gpio, snps,reset-active-low
and snps,reset-delays-us are all deprecated in snps,dwmac.yaml,
so a new DTS using them is unlikely to get through netdev.
The MDIO bus level reset in mdio.yaml solves the same ordering problem
without using deprecated property. `__mdiobus_register()` asserts and
releases it before any device on the bus is registered, so it also
covers the DT described case where the bus is not scanned at all:
&mdio1 {
reset-delay-us = <20000>;
reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
reset-post-delay-us = <100000>;
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0x1>;
};
};
with gmac1_rstn_l moved to the MAC's pinctrl-0, since the MDIO bus has
no device of its own for pinctrl to bind to. There is only one PHY on
mdio1, so a bus wide reset is equivalent to the per-PHY one.
v3 carries this as patch 1, against the NanoPi Zero2 and ahead of the
move, so it can be backported:
<https://lore.kernel.org/r/20260909-r28s-upstream-v3-0-ee3e1a34a353@proton.me>
A `Tested-by` on that form would be very welcome, since it is not the
variant you tested.
I had an R28S series of my own out before I saw yours; I am dropping it.
Sorry about the duplicated effort.
Thanks,
Rong An.