Hi Dennis,
On 10/2/26 5:13 AM, Dennis Gilmore wrote:
The Xunlong Orange Pi 5 Pro is a single-board computer based on the
Rockchip RK3588S SoC. The board provides many interfaces, including
two HDMI output ports, a PCIe-attached Motorcomm YT6801 2.5GbE port,
an M.2 M-Key slot, one USB 3.0 and four USB 2.0 ports.
Features tested on an Orange Pi 5 Pro 16GB:
- SD-card boot
- eMMC boot
- PCIe/NVMe
The devicetree is taken from Linux v7.3 via the preceding dts/upstream
picks.
The upstream devicetree muxes the PERST# pin of pcie2x1l1 and
pcie2x1l2 to the controller's dedicated function while also using it
as reset-gpios. Linux switches the pin to GPIO when it is requested,
U-Boot does not, and probing pcie2x1l2 then hangs. Override the
pinctrl in the -u-boot.dtsi to use GPIO function for the reset pins,
like rk3568-rock-3a-u-boot.dtsi does, until the Linux devicetree is
fixed.
Please add the link to the patch on the kernel mailing list so it's
easier to follow its status.
https://lore.kernel.org/linux-rockchip/[email protected]/
Signed-off-by: Dennis Gilmore <[email protected]>
---
.../dts/rk3588s-orangepi-5-pro-u-boot.dtsi | 25 ++++++
board/rockchip/evb_rk3588/MAINTAINERS | 6 ++
configs/orangepi-5-pro-rk3588s_defconfig | 82 +++++++++++++++++++
doc/board/rockchip/rockchip.rst | 1 +
4 files changed, 114 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-orangepi-5-pro-u-boot.dtsi
create mode 100644 configs/orangepi-5-pro-rk3588s_defconfig
diff --git a/arch/arm/dts/rk3588s-orangepi-5-pro-u-boot.dtsi
b/arch/arm/dts/rk3588s-orangepi-5-pro-u-boot.dtsi
new file mode 100644
index 00000000000..142db4a0fcf
--- /dev/null
+++ b/arch/arm/dts/rk3588s-orangepi-5-pro-u-boot.dtsi
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
+
+&pcie2x1l1 {
+ pinctrl-0 = <&pcie2x1l1_reset_h>, <&pcie30x1m1_1_clkreqn>,
+ <&pcie30x1m1_1_waken>;
+};
+
+&pcie2x1l2 {
+ pinctrl-0 = <&pcie2x1l2_reset_h>, <&pcie20x1m0_clkreqn>,
+ <&pcie20x1m0_waken>;
+};
+
+&pinctrl {
+ pcie {
+ pcie2x1l1_reset_h: pcie2x1l1-reset-h {
+ rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pcie2x1l2_reset_h: pcie2x1l2-reset-h {
+ rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
diff --git a/board/rockchip/evb_rk3588/MAINTAINERS
b/board/rockchip/evb_rk3588/MAINTAINERS
index b64dd4947ee..0cc32a6e28e 100644
--- a/board/rockchip/evb_rk3588/MAINTAINERS
+++ b/board/rockchip/evb_rk3588/MAINTAINERS
@@ -35,6 +35,12 @@ S: Maintained
F: configs/orangepi-5-rk3588s_defconfig
F: arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
+ORANGEPI-5-PRO-RK3588S
+M: Dennis Gilmore <[email protected]>
+S: Maintained
+F: configs/orangepi-5-pro-rk3588s_defconfig
+F: arch/arm/dts/rk3588s-orangepi-5-pro-u-boot.dtsi
+
Please order alphabetically with the other entries in this file.
ORANGEPI-5-MAX-RK3588
M: Ilya Katsnelson <[email protected]>
S: Maintained
diff --git a/configs/orangepi-5-pro-rk3588s_defconfig
b/configs/orangepi-5-pro-rk3588s_defconfig
new file mode 100644
index 00000000000..f4c6eecf2d5
--- /dev/null
+++ b/configs/orangepi-5-pro-rk3588s_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=24000000
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3588s-orangepi-5-pro"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_SPL_SERIAL=y
+CONFIG_TARGET_EVB_RK3588=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_DEBUG_UART_BASE=0xFEB50000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_EFI_SECURE_BOOT=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="pci enum; usb start; nvme scan;"
I know Jonas has been pretty vocal against having PREBOOT set by default
as it drastically increases the boot time in all scenarios. We don't
have many Rockchip boards that set this variable, do you really need it?
Shouldn't bootflow set this up properly when attempting to use
PCI/USB/NVMe storage to locate files?
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588s-orangepi-5-pro.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x40000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_ATF=y
+CONFIG_CMD_NVEDIT_EFI=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
assigned-clock-rates assigned-clock-parents"
Do we really need to remove the clock-names from the SPL DTB?
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MISC=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_NVME_PCI=y
+CONFIG_PCIE_DW_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONFIG_PHY_ROCKCHIP_USBDP=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_SPL_RAM=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SPI=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_GENERIC=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
I don't think we have VOP2 support in U-Boot yet, so how did you test
video support?
+CONFIG_ERRNO_STR=y
There are PWM leds on the board, would enabling CONFIG_LED_PWM,
CONFIG_CMD_LED and CONFIG_PWM_ROCKCHIP help you control them maybe?
There's an RTL8111HS, I'm assuming we don't have a driver for this in
U-Boot? Have you tried CONFIG_RTL8169 maybe?
Looks ok to me otherwise!
Cheers,
Quentin
