Hi Fabio,

On 7/22/26 3:36 AM, Fabio Estevam via U-Boot wrote:
From: Fabio Estevam <[email protected]>

The ROC-RK3399-PC has an MP8859 regulator on I2C7 at address 0x66,
while the ROC-RK3399-PC-PLUS does not. Probe for the regulator in SPL

The ROC-RK3399-PC-Pro also doesn't have one, so we'll need to figure out a way to differentiate them too (the day someone upstreams support for it :), we don't need to think about it today fortunately).

and use the result to select the matching devicetree from the U-Boot
FIT. Fall back to the original board if the I2C bus cannot be probed.

Build both devicetrees from the existing roc-pc-rk3399_defconfig and
enable the XMC SPI NOR driver used by the Plus variant. Set fdtfile
from the selected U-Boot devicetree so the matching Linux devicetree
is used as well.

Signed-off-by: Fabio Estevam <[email protected]>
---
Changes since v1:
- Added run-time board time detection.

  arch/arm/dts/rk3399-roc-pc-plus-u-boot.dtsi |  3 ++
  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi      |  8 +++++
  board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 37 +++++++++++++++++++++
  configs/roc-pc-rk3399_defconfig             |  3 ++
  doc/board/rockchip/rockchip.rst             |  2 +-
  5 files changed, 52 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/rk3399-roc-pc-plus-u-boot.dtsi

diff --git a/arch/arm/dts/rk3399-roc-pc-plus-u-boot.dtsi 
b/arch/arm/dts/rk3399-roc-pc-plus-u-boot.dtsi
new file mode 100644
index 000000000000..c80529a62b97
--- /dev/null
+++ b/arch/arm/dts/rk3399-roc-pc-plus-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3399-roc-pc-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi 
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index a85e9549c83e..e7e4a2c89072 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -12,6 +12,14 @@
        };
  };
+&i2c7 {
+       bootph-pre-ram;
+};
+
+&i2c7_xfer {
+       bootph-pre-ram;
+};
+
  &gpio4 {
        bootph-pre-ram;
  };
diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index 6937a27176f9..60a3ba43cdbd 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -5,14 +5,24 @@
#include <dm.h>
  #include <env.h>
+#include <fdtdec.h>
+#include <i2c.h>
+#include <image.h>
  #include <log.h>
  #include <spl_gpio.h>
+#include <asm/global_data.h>
  #include <asm/io.h>
#include <asm/arch-rockchip/cru.h>
  #include <asm/arch-rockchip/gpio.h>
  #include <asm/arch-rockchip/grf_rk3399.h>
+#define ROC_PC_MP8859_BUS "i2c@ff160000"
+#define ROC_PC_MP8859_ADDR     0x66
+#define ROC_PC_PLUS_FDTFILE    "rockchip/rk3399-roc-pc-plus.dtb"
+
+DECLARE_GLOBAL_DATA_PTR;
+
  #ifdef CONFIG_XPL_BUILD
#define PMUGRF_BASE 0xff320000
@@ -54,4 +64,31 @@ void led_setup(void)
        spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
  }
+static bool is_roc_pc_plus(void)
+{
+       struct udevice *bus, *dev;
+
+       if (uclass_get_device_by_name(UCLASS_I2C, ROC_PC_MP8859_BUS, &bus))
+               return false;
+
+       return dm_i2c_probe(bus, ROC_PC_MP8859_ADDR, 0, &dev);
+}
+
+int board_fit_config_name_match(const char *name)
+{
+       if (is_roc_pc_plus())
+               return strcmp(name, ROC_PC_PLUS_FDTFILE);
+
+       return strcmp(name, CONFIG_DEFAULT_FDT_FILE);
+}
+
  #endif
+
+int rk_board_late_init(void)
+{
+       if (!fdt_node_check_compatible(gd->fdt_blob, 0,
+                                      "firefly,roc-rk3399-pc-plus"))
+               env_set("fdtfile", ROC_PC_PLUS_FDTFILE);

include/configs/rk3399_common.h sets fdtfile to CONFIG_DEFAULT_FDT_FILE (which is rockchip/rk3399-roc-pc.dtb for configs/roc-pc-rk3399_defconfig) by default so *not* setting it for the roc-rk3399-pc case means it'll use the default. We just hope someone doesn't save the environment on e.g. an SD card when having booted from a ROC-RK3399-PC-Plus and then insert it in a ROC-RK3399-PC... so maybe really set fdtfile for the roc-rk3399-pc case. What do you think?

Looks good to me otherwise, thanks!
Quentin

Reply via email to