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 <[email protected]> >> --- >> 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 <[email protected]> >> +S: Maintained >> +F: arch/arm/dts/rk3576-nanopi-r76s* >> +F: configs/nanopi-r76s-rk3576_defconfig >> + >> OMNI3576-RK3576 >> M: Jonas Karlman <[email protected]> >> 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
