[PATCH 2/2] board: rockchip: Add FriendlyElec NanoPi R76S

Tue Mar 10 00:49:08 CET 2026

Hi Quentin,

On 1/14/2026 5:52 PM, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 1/8/26 3:35 PM, Jonas Karlman wrote:
>> The NanoPi R76S (as "R76S") is an open-sourced mini IoT gateway
>> device with two 2.5G, designed and developed by FriendlyElec.
>>
>> Features tested on a NanoPi R76S 2411:
>> - SD-card boot
>> - eMMC boot
>> - LEDs and button
>> - PCIe/Ethernet
>> - USB host
>>
>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
>> ---
>>   arch/arm/dts/rk3576-nanopi-r76s-u-boot.dtsi |  3 ++
>>   arch/arm/mach-rockchip/rk3576/MAINTAINERS   |  6 +++
>>   configs/nanopi-r76s-rk3576_defconfig        | 60 +++++++++++++++++++++
>>   doc/board/rockchip/rockchip.rst             |  1 +
>>   4 files changed, 70 insertions(+)
>>   create mode 100644 arch/arm/dts/rk3576-nanopi-r76s-u-boot.dtsi
>>   create mode 100644 configs/nanopi-r76s-rk3576_defconfig
>>
>> diff --git a/arch/arm/dts/rk3576-nanopi-r76s-u-boot.dtsi b/arch/arm/dts/rk3576-nanopi-r76s-u-boot.dtsi
>> new file mode 100644
>> index 000000000000..632fabb6af56
>> --- /dev/null
>> +++ b/arch/arm/dts/rk3576-nanopi-r76s-u-boot.dtsi
>> @@ -0,0 +1,3 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +
>> +#include "rk3576-u-boot.dtsi"
> 
> I don't think that should be necessary?

You are correct, I have removed this file in v2.

> U-Boot should fallback to rj3576-u-boot.dtsi if there's no 
> rk3576-nanopi-r76s-u-boot.dtsi, because SYS_SOC is rk3576 in 
> arch/arm/mach-rockchip/rk3576/Kconfig and the wildcard list in 
> u_boot_dtsi_options in scripts/Makefile.lib.
> 
> More comments below but they are definitely not blocker for merging this.
> 
>> diff --git a/arch/arm/mach-rockchip/rk3576/MAINTAINERS b/arch/arm/mach-rockchip/rk3576/MAINTAINERS
>> index 393edd3984ce..79cf9e97f70b 100644
>> --- a/arch/arm/mach-rockchip/rk3576/MAINTAINERS
>> +++ b/arch/arm/mach-rockchip/rk3576/MAINTAINERS
>> @@ -10,6 +10,12 @@ S:	Maintained
>>   F:	arch/arm/dts/rk3576-nanopi-m5*
>>   F:	configs/nanopi-m5-rk3576_defconfig
>>   
>> +NANOPI-R76S-RK3576
>> +M:	Jonas Karlman <jonas at kwiboo.se>
>> +S:	Maintained
>> +F:	arch/arm/dts/rk3576-nanopi-r76s*
>> +F:	configs/nanopi-r76s-rk3576_defconfig
>> +
>>   OMNI3576-RK3576
>>   M:	Jonas Karlman <jonas at kwiboo.se>
>>   S:	Maintained
>> diff --git a/configs/nanopi-r76s-rk3576_defconfig b/configs/nanopi-r76s-rk3576_defconfig
>> new file mode 100644
>> index 000000000000..af149dc4ba56
>> --- /dev/null
>> +++ b/configs/nanopi-r76s-rk3576_defconfig
>> @@ -0,0 +1,60 @@
>> +CONFIG_ARM=y
>> +CONFIG_SKIP_LOWLEVEL_INIT=y
>> +CONFIG_SYS_HAS_NONCACHED_MEMORY=y
>> +CONFIG_COUNTER_FREQUENCY=24000000
>> +CONFIG_ARCH_ROCKCHIP=y
>> +CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3576-nanopi-r76s"
>> +CONFIG_ROCKCHIP_RK3576=y
>> +CONFIG_SYS_LOAD_ADDR=0x40c00800
> 
> Should we think about adding a default value for various Rockchip SoCs 
> in root Kconfig for SYS_LOAD_ADDR?

Possible, I do not even know if this is a fully safe default for
SYS_LOAD_ADDR or what will really use this addr, but it matches what is
used by many other Rockchip boards.

> 
>> +CONFIG_DEBUG_UART_BASE=0x2AD40000
>> +CONFIG_DEBUG_UART_CLOCK=24000000
> 
> Same here. I'm assuming there's a reference design most people are 
> basing their HW on, so having a default DEBUG_UART_BASE common for the 
> SoC makes sense (and we could even then have a comment specifying which 
> UART controller that is). As for the clock speed, I'm wondering if we 
> ever had something different than that. And also wondering if it's 
> related (should be in sync?) with &uart0/clock-frequency?

Agree, there are some defaults that we could and probably should set on
SoC level. And yes, there are multiple possible duplicated 24 MHz ref
clocks in use for UART, e.g.: DEBUG_UART_CLOCK, &uart0/clock-frequency
and CFG_SYS_NS16550_CLK. To my knowledge all Rockchip SoCs use a 24 MHz
ref clock.

> 
>> +CONFIG_PCI=y
>> +CONFIG_DEBUG_UART=y
>> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3576-nanopi-r76s.dtb"
>> +# CONFIG_DISPLAY_CPUINFO is not set
> 
> Why not :)?

It requires asm/arch-rockchip/cru.h to have a soc specific #ifdef to
make it work to print out and set a reset reason. Something I rather see
being reworked to use sysresed uclass or similar than enable for "new"
SoCs.

> 
>> +CONFIG_SPL_MAX_SIZE=0x40000
>> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
>> +CONFIG_CMD_MEMINFO=y
>> +CONFIG_CMD_MEMINFO_MAP=y
>> +CONFIG_CMD_ADC=y
>> +CONFIG_CMD_GPIO=y
>> +CONFIG_CMD_GPT=y
>> +CONFIG_CMD_I2C=y
>> +CONFIG_CMD_MISC=y
>> +CONFIG_CMD_MMC=y
>> +CONFIG_CMD_PCI=y
>> +CONFIG_CMD_USB=y
>> +# CONFIG_CMD_SETEXPR is not set
>> +CONFIG_CMD_RNG=y
>> +CONFIG_CMD_REGULATOR=y
>> +# CONFIG_SPL_DOS_PARTITION is not set
>> +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
>> +CONFIG_BUTTON=y
>> +CONFIG_BUTTON_GPIO=y
>> +CONFIG_ROCKCHIP_GPIO=y
>> +CONFIG_SYS_I2C_ROCKCHIP=y
>> +CONFIG_LED=y
>> +CONFIG_LED_GPIO=y
>> +CONFIG_SUPPORT_EMMC_RPMB=y
>> +CONFIG_MMC_DW=y
>> +CONFIG_MMC_DW_ROCKCHIP=y
>> +CONFIG_MMC_SDHCI=y
>> +CONFIG_MMC_SDHCI_SDMA=y
>> +CONFIG_MMC_SDHCI_ROCKCHIP=y
>> +CONFIG_RTL8169=y
>> +CONFIG_PCIE_DW_ROCKCHIP=y
>> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>> +CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
>> +CONFIG_PHY_ROCKCHIP_USBDP=y
>> +CONFIG_DM_PMIC=y
>> +CONFIG_PMIC_RK8XX=y
>> +CONFIG_REGULATOR_RK8XX=y
>> +CONFIG_BAUDRATE=1500000
>> +CONFIG_DEBUG_UART_SHIFT=2
>> +CONFIG_SYS_NS16550_MEM32=y
> 
> The two above also are always the same on Rockchip no?

Yes, to my knowledge most reg access on RK is 32-bit based and should
use readl/writel instead of readb/writeb.

> 
> By default, the expected baudrate is probably 1500000 on Rockchip, 
> wondering if we shouldn't make that the default either?

Agree, there are only a few SoCs/boards that 

> 
>> +CONFIG_SYSRESET_PSCI=y
>> +CONFIG_USB=y
>> +CONFIG_USB_XHCI_HCD=y
>> +CONFIG_USB_DWC3=y
>> +CONFIG_USB_DWC3_GENERIC=y
>> +CONFIG_ERRNO_STR=y
> 
> I'm wondering whether we should think about setting WERROR on by default 
> for new boards? What do you think?

Sounds like a good idea but no other board in-tree seem to enable it.
My local build script always injected -Werror using CFLAGS, but maybe
better to enable CONFIG_WERROR.

Regards,
Jonas

> 
> Cheers,
> Quentin