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

[Quentin Schulz <quentin.schulz@cherry.de>]

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@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?

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@kwiboo.se>
> +S:	Maintained
> +F:	arch/arm/dts/rk3576-nanopi-r76s*
> +F:	configs/nanopi-r76s-rk3576_defconfig
> +
>   OMNI3576-RK3576
>   M:	Jonas Karlman <jonas@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?

> +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?

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

Why not :)?

> +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?

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

> +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?

Cheers,
Quentin