[PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR

[PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR

[Quentin Schulz]

This adds all the necessary bits for adding support for Theobroma's new
SBC.

JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
is targeting Autonomous Mobile Robots (AMR).

It features:
 * LPDDR4X (up to 16GB)
 * 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
 * PCIe 3.0 4-lane on M.2 M-key connector
 * PCIe 2.1 1-lane on M.2 E-key
 * USB 2.0 on M.2 E-key
 * 2x USB3 OTG type-c ports with DP Alt-Mode
 * USB2 host port
 * HDMI output
 * 2x camera connectors, each exposing:
   * 2-lane MIPI-CSI
   * 1v2, 1v8, 2v8 power rails
   * I2C bus
   * GPIOs
 * PPS input
 * CAN
 * RS485 UART
 * FAN connector
 * SD card slot
 * eMMC (up to 256GB)
 * RTC backup battery
 * Companion microcontroller
   * ISL1208 RTC emulation
   * AMC6821 PWM emulation
 * On/off buzzer control
 * Secure Element
 * 80-pin Mezzanine connector for daughterboards:
   * GPIOs
   * 1Gbps Ethernet
   * PCIe 2.1 1-lane
   * 2x 2-lane MIPI-CSI
   * ADC channel
   * I2C bus
   * PWM
   * UART
   * SPI
   * SDIO
   * CAN
   * I2S
   * 1v8, 3v3, 5v0, dc-in (12-24V) power rails

While at it, do some code cleanup and factoring out for Rockchip SoCs.

This also fixes issues with the SDMMC controller on all RK3588 boards
being muxed into JTAG automatically and breaking SD card support.

This also binds the MMC controllers from RK3588 in U-Boot proper before
relocation so that it's available for env_init(), be there any need for
it (there's for Theobroma's RK3588 based products), and match all
(except the RK356x family) Rockchip SoCs behavior.

Special attention should be brought to the rockchip_early_misc_init_r
migration for Pinephone Pro and Pinebook Pro since they now also call
rockchip_setup_macaddr() which they didn't until now.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
Heiko Stuebner (2):
      rockchip: rk3588: use mainline pmu-grf compatible
      rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1

Quentin Schulz (16):
      rockchip: avoid out-of-bounds when computing cpuid
      rockchip: add weak function symbol called at the beginning of misc_init_r
      rockchip: google: gru: migrate to rockchip_early_misc_init_r
      rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
      rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r
      rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
      rockchip: theobroma-systems: puma: migrate to rockchip_early_misc_init_r
      rockchip: theobroma-systems: ringneck: migrate to rockchip_early_misc_init_r
      rockchip: merge misc.c into board.c
      rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol
      rockchip: rk3588: fix non-working SD controller if booting from other media
      rockchip: rk3588: add constants for some register address spaces
      rockchip: migrate hardware.h inclusion into appropriate files
      rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h
      rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
      board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC

 arch/arm/dts/rk3588-jaguar-u-boot.dtsi             |  32 +
 arch/arm/dts/rk3588-jaguar.dts                     | 803 +++++++++++++++++++++
 arch/arm/dts/rk3588s-u-boot.dtsi                   |  40 +-
 arch/arm/dts/rk3588s.dtsi                          | 152 ++++
 arch/arm/include/asm/arch-rockchip/cru_rk3588.h    |   2 +
 arch/arm/include/asm/arch-rockchip/grf_rk3588.h    |  24 +
 arch/arm/include/asm/arch-rockchip/hardware.h      |   2 +
 arch/arm/include/asm/arch-rockchip/ioc_rk3588.h    |   6 +
 arch/arm/include/asm/arch-rockchip/misc.h          |  14 -
 arch/arm/mach-rockchip/Makefile                    |   1 -
 arch/arm/mach-rockchip/board.c                     | 139 +++-
 arch/arm/mach-rockchip/cpu-info.c                  |   1 -
 arch/arm/mach-rockchip/misc.c                      | 135 ----
 arch/arm/mach-rockchip/px30/px30.c                 |   1 -
 arch/arm/mach-rockchip/rk3036/rk3036.c             |   1 -
 arch/arm/mach-rockchip/rk3036/sdram_rk3036.c       |   1 -
 arch/arm/mach-rockchip/rk3066/rk3066.c             |   2 +-
 arch/arm/mach-rockchip/rk3188/rk3188.c             |   1 -
 arch/arm/mach-rockchip/rk322x/rk322x.c             |   1 -
 arch/arm/mach-rockchip/rk3288/rk3288.c             |   1 -
 arch/arm/mach-rockchip/rk3308/rk3308.c             |   1 -
 arch/arm/mach-rockchip/rk3328/rk3328.c             |   1 -
 arch/arm/mach-rockchip/rk3368/rk3368.c             |   1 -
 arch/arm/mach-rockchip/rk3399/rk3399.c             |   1 -
 arch/arm/mach-rockchip/rk3568/rk3568.c             |   1 -
 arch/arm/mach-rockchip/rk3588/Kconfig              |  28 +
 arch/arm/mach-rockchip/rk3588/rk3588.c             |  12 +-
 arch/arm/mach-rockchip/rk3588/syscon_rk3588.c      |   2 +-
 arch/arm/mach-rockchip/rv1126/rv1126.c             |   1 -
 board/elgin/elgin_rv1108/elgin_rv1108.c            |   1 -
 board/firefly/firefly-rk3308/roc_cc_rk3308.c       |   1 -
 board/google/gru/gru.c                             |  21 +-
 .../pinebook-pro-rk3399/pinebook-pro-rk3399.c      |  19 +-
 .../pinephone-pro-rk3399/pinephone-pro-rk3399.c    |  18 +-
 board/pine64/rockpro64_rk3399/rockpro64-rk3399.c   |  21 +-
 board/rockchip/evb_rv1108/evb_rv1108.c             |   1 -
 board/theobroma-systems/jaguar_rk3588/Kconfig      |  16 +
 board/theobroma-systems/jaguar_rk3588/MAINTAINERS  |  12 +
 board/theobroma-systems/jaguar_rk3588/Makefile     |  10 +
 board/theobroma-systems/jaguar_rk3588/README       | 118 +++
 .../jaguar_rk3588/jaguar_rk3588.c                  |  52 ++
 board/theobroma-systems/puma_rk3399/puma-rk3399.c  |  21 +-
 .../ringneck_px30/ringneck-px30.c                  |  20 +-
 board/vamrs/rock960_rk3399/rock960-rk3399.c        |   1 -
 configs/jaguar-rk3588_defconfig                    | 115 +++
 drivers/clk/rockchip/clk_pll.c                     |   1 -
 drivers/clk/rockchip/clk_px30.c                    |   1 -
 drivers/clk/rockchip/clk_rk3036.c                  |   1 -
 drivers/clk/rockchip/clk_rk3066.c                  |   1 -
 drivers/clk/rockchip/clk_rk3128.c                  |   1 -
 drivers/clk/rockchip/clk_rk3188.c                  |   1 -
 drivers/clk/rockchip/clk_rk322x.c                  |   1 -
 drivers/clk/rockchip/clk_rk3288.c                  |   1 -
 drivers/clk/rockchip/clk_rk3308.c                  |   1 -
 drivers/clk/rockchip/clk_rk3328.c                  |   1 -
 drivers/clk/rockchip/clk_rk3368.c                  |   1 -
 drivers/clk/rockchip/clk_rk3399.c                  |   1 -
 drivers/clk/rockchip/clk_rk3568.c                  |   1 -
 drivers/clk/rockchip/clk_rk3588.c                  |   1 -
 drivers/clk/rockchip/clk_rv1108.c                  |   1 -
 drivers/clk/rockchip/clk_rv1126.c                  |   1 -
 drivers/gpio/rk_gpio.c                             |   1 -
 drivers/net/gmac_rockchip.c                        |   1 -
 drivers/ram/rockchip/dmc-rk3368.c                  |   2 +-
 drivers/ram/rockchip/sdram_px30.c                  |   1 -
 drivers/ram/rockchip/sdram_rk3066.c                |   1 -
 drivers/ram/rockchip/sdram_rk3188.c                |   2 +-
 drivers/ram/rockchip/sdram_rk322x.c                |   1 -
 drivers/ram/rockchip/sdram_rk3288.c                |   2 +-
 drivers/ram/rockchip/sdram_rk3399.c                |   1 -
 drivers/ram/rockchip/sdram_rv1126.c                |   1 -
 drivers/rng/rockchip_rng.c                         |   1 -
 drivers/sysreset/sysreset_rockchip.c               |   1 -
 drivers/video/rockchip/dw_mipi_dsi_rockchip.c      |   1 -
 drivers/video/rockchip/rk3288_hdmi.c               |   1 -
 drivers/video/rockchip/rk3288_mipi.c               |   1 -
 drivers/video/rockchip/rk3288_vop.c                |   1 -
 drivers/video/rockchip/rk3399_hdmi.c               |   1 -
 drivers/video/rockchip/rk3399_mipi.c               |   1 -
 drivers/video/rockchip/rk3399_vop.c                |   1 -
 drivers/video/rockchip/rk_edp.c                    |   1 -
 drivers/video/rockchip/rk_hdmi.c                   |   1 -
 drivers/video/rockchip/rk_lvds.c                   |   1 -
 include/configs/jaguar_rk3588.h                    |  15 +
 include/configs/rk3036_common.h                    |   1 -
 include/configs/rk3066_common.h                    |   1 -
 include/configs/rk3188_common.h                    |   1 -
 include/configs/rk322x_common.h                    |   1 -
 include/configs/rk3288_common.h                    |   1 -
 include/configs/rk3368_common.h                    |   1 -
 include/configs/rv1108_common.h                    |   1 -
 91 files changed, 1553 insertions(+), 364 deletions(-)
---
base-commit: 15e7927b5a2d33666af19879577bf0c30ab088fe
change-id: 20240123-jaguar-efd00e57f56c

Best regards,
-- 
Quentin Schulz <quentin.schulz@theobroma-systems.com>

[PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible

[Quentin Schulz]

From: Heiko Stuebner <heiko.stuebner@cherry.de>

The compatible for the pmugrf in the mainline kernel is dfferent from the
one currently used in u-boot. Adapt the -u-boot.dtsi and syscon driver
to use the correct compatible.

Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rk3588s-u-boot.dtsi              | 2 +-
 arch/arm/mach-rockchip/rk3588/syscon_rk3588.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index c0fd16c4022..9a5ffec926e 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -66,7 +66,7 @@
 
 	pmu1_grf: syscon@fd58a000 {
 		bootph-all;
-		compatible = "rockchip,rk3588-pmu1-grf", "syscon";
+		compatible = "rockchip,rk3588-pmugrf", "syscon";
 		reg = <0x0 0xfd58a000 0x0 0x2000>;
 	};
 
diff --git a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
index e8772d3a382..7b2cf37d9da 100644
--- a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
@@ -10,7 +10,7 @@
 
 static const struct udevice_id rk3588_syscon_ids[] = {
 	{ .compatible = "rockchip,rk3588-sys-grf", .data = ROCKCHIP_SYSCON_GRF },
-	{ .compatible = "rockchip,rk3588-pmu1-grf", .data = ROCKCHIP_SYSCON_PMUGRF },
+	{ .compatible = "rockchip,rk3588-pmugrf",  .data = ROCKCHIP_SYSCON_PMUGRF },
 	{ .compatible = "rockchip,rk3588-vop-grf", .data = ROCKCHIP_SYSCON_VOP_GRF },
 	{ .compatible = "rockchip,rk3588-vo-grf",  .data = ROCKCHIP_SYSCON_VO_GRF },
 	{ .compatible = "rockchip,pcie30-phy-grf", .data = ROCKCHIP_SYSCON_PCIE30_PHY_GRF },

-- 
2.43.0

Re: [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>
> The compatible for the pmugrf in the mainline kernel is dfferent from the
> one currently used in u-boot. Adapt the -u-boot.dtsi and syscon driver
> to use the correct compatible.
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/dts/rk3588s-u-boot.dtsi              | 2 +-
>   arch/arm/mach-rockchip/rk3588/syscon_rk3588.c | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
> index c0fd16c4022..9a5ffec926e 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -66,7 +66,7 @@
>   
>   	pmu1_grf: syscon@fd58a000 {
>   		bootph-all;
> -		compatible = "rockchip,rk3588-pmu1-grf", "syscon";
> +		compatible = "rockchip,rk3588-pmugrf", "syscon";
>   		reg = <0x0 0xfd58a000 0x0 0x2000>;
>   	};
>   
> diff --git a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> index e8772d3a382..7b2cf37d9da 100644
> --- a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> +++ b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> @@ -10,7 +10,7 @@
>   
>   static const struct udevice_id rk3588_syscon_ids[] = {
>   	{ .compatible = "rockchip,rk3588-sys-grf", .data = ROCKCHIP_SYSCON_GRF },
> -	{ .compatible = "rockchip,rk3588-pmu1-grf", .data = ROCKCHIP_SYSCON_PMUGRF },
> +	{ .compatible = "rockchip,rk3588-pmugrf",  .data = ROCKCHIP_SYSCON_PMUGRF },
>   	{ .compatible = "rockchip,rk3588-vop-grf", .data = ROCKCHIP_SYSCON_VOP_GRF },
>   	{ .compatible = "rockchip,rk3588-vo-grf",  .data = ROCKCHIP_SYSCON_VO_GRF },
>   	{ .compatible = "rockchip,pcie30-phy-grf", .data = ROCKCHIP_SYSCON_PCIE30_PHY_GRF },
>

Re: [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible

[Weizhao Ouyang]

On Tue, Jan 23, 2024 at 10:50 PM Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>
> The compatible for the pmugrf in the mainline kernel is dfferent from the
> one currently used in u-boot. Adapt the -u-boot.dtsi and syscon driver
> to use the correct compatible.

Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>

BR,
Weizhao

>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>  arch/arm/dts/rk3588s-u-boot.dtsi              | 2 +-
>  arch/arm/mach-rockchip/rk3588/syscon_rk3588.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
> index c0fd16c4022..9a5ffec926e 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -66,7 +66,7 @@
>
>         pmu1_grf: syscon@fd58a000 {
>                 bootph-all;
> -               compatible = "rockchip,rk3588-pmu1-grf", "syscon";
> +               compatible = "rockchip,rk3588-pmugrf", "syscon";
>                 reg = <0x0 0xfd58a000 0x0 0x2000>;
>         };
>
> diff --git a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> index e8772d3a382..7b2cf37d9da 100644
> --- a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> +++ b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> @@ -10,7 +10,7 @@
>
>  static const struct udevice_id rk3588_syscon_ids[] = {
>         { .compatible = "rockchip,rk3588-sys-grf", .data = ROCKCHIP_SYSCON_GRF },
> -       { .compatible = "rockchip,rk3588-pmu1-grf", .data = ROCKCHIP_SYSCON_PMUGRF },
> +       { .compatible = "rockchip,rk3588-pmugrf",  .data = ROCKCHIP_SYSCON_PMUGRF },
>         { .compatible = "rockchip,rk3588-vop-grf", .data = ROCKCHIP_SYSCON_VOP_GRF },
>         { .compatible = "rockchip,rk3588-vo-grf",  .data = ROCKCHIP_SYSCON_VO_GRF },
>         { .compatible = "rockchip,pcie30-phy-grf", .data = ROCKCHIP_SYSCON_PCIE30_PHY_GRF },
>
> --
> 2.43.0
>

[PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1

[Quentin Schulz]

From: Heiko Stuebner <heiko.stuebner@cherry.de>

This brings the real host2_xhci node as well as the pmu1grf node and
spi0 to spi4 aliases from the next-20240110 Linux kernel. So also
adapt/remove the nodes and aliases in rk3588s-u-boot.dtsi

Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
[sync with v6.8-rc1]
[remove spi0 to spi4 aliases from rk3588s-u-boot.dtsi]
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rk3588s-u-boot.dtsi |  36 ++--------
 arch/arm/dts/rk3588s.dtsi        | 152 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 156 insertions(+), 32 deletions(-)

diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index 9a5ffec926e..960ac4abda3 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -7,11 +7,6 @@
 
 / {
 	aliases {
-		spi0 = &spi0;
-		spi1 = &spi1;
-		spi2 = &spi2;
-		spi3 = &spi3;
-		spi4 = &spi4;
 		spi5 = &sfc;
 	};
 
@@ -43,33 +38,6 @@
 		status = "disabled";
 	};
 
-	usb_host2_xhci: usb@fcd00000 {
-		compatible = "rockchip,rk3588-dwc3", "rockchip,rk3568-dwc3", "snps,dwc3";
-		reg = <0x0 0xfcd00000 0x0 0x400000>;
-		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH 0>;
-		clocks = <&cru REF_CLK_USB3OTG2>, <&cru SUSPEND_CLK_USB3OTG2>,
-			 <&cru ACLK_USB3OTG2>, <&cru CLK_UTMI_OTG2>,
-			 <&cru CLK_PIPEPHY2_PIPE_U3_G>;
-		clock-names = "ref_clk", "suspend_clk", "bus_clk", "utmi", "pipe";
-		dr_mode = "host";
-		phys = <&combphy2_psu PHY_TYPE_USB3>;
-		phy-names = "usb3-phy";
-		phy_type = "utmi_wide";
-		resets = <&cru SRST_A_USB3OTG2>;
-		snps,dis_enblslpm_quirk;
-		snps,dis-u2-freeclk-exists-quirk;
-		snps,dis-del-phy-power-chg-quirk;
-		snps,dis-tx-ipgap-linecheck-quirk;
-		snps,dis_rxdet_inp3_quirk;
-		status = "disabled";
-	};
-
-	pmu1_grf: syscon@fd58a000 {
-		bootph-all;
-		compatible = "rockchip,rk3588-pmugrf", "syscon";
-		reg = <0x0 0xfd58a000 0x0 0x2000>;
-	};
-
 	usbdpphy0_grf: syscon@fd5c8000 {
 		compatible = "rockchip,rk3588-usbdpphy-grf", "syscon";
 		reg = <0x0 0xfd5c8000 0x0 0x4000>;
@@ -201,6 +169,10 @@
 	status = "okay";
 };
 
+&pmu1grf {
+	bootph-all;
+};
+
 &sys_grf {
 	bootph-pre-ram;
 	status = "okay";
diff --git a/arch/arm/dts/rk3588s.dtsi b/arch/arm/dts/rk3588s.dtsi
index 61a9a11c3bb..36b1b7acfe6 100644
--- a/arch/arm/dts/rk3588s.dtsi
+++ b/arch/arm/dts/rk3588s.dtsi
@@ -18,6 +18,38 @@
 	#address-cells = <2>;
 	#size-cells = <2>;
 
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+		i2c7 = &i2c7;
+		i2c8 = &i2c8;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		spi2 = &spi2;
+		spi3 = &spi3;
+		spi4 = &spi4;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -362,6 +394,11 @@
 		#clock-cells = <0>;
 	};
 
+	display_subsystem: display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
@@ -443,11 +480,47 @@
 		status = "disabled";
 	};
 
+	usb_host2_xhci: usb@fcd00000 {
+		compatible = "rockchip,rk3588-dwc3", "snps,dwc3";
+		reg = <0x0 0xfcd00000 0x0 0x400000>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru REF_CLK_USB3OTG2>, <&cru SUSPEND_CLK_USB3OTG2>,
+			 <&cru ACLK_USB3OTG2>, <&cru CLK_UTMI_OTG2>,
+			 <&cru CLK_PIPEPHY2_PIPE_U3_G>;
+		clock-names = "ref_clk", "suspend_clk", "bus_clk", "utmi", "pipe";
+		dr_mode = "host";
+		phys = <&combphy2_psu PHY_TYPE_USB3>;
+		phy-names = "usb3-phy";
+		phy_type = "utmi_wide";
+		resets = <&cru SRST_A_USB3OTG2>;
+		snps,dis_enblslpm_quirk;
+		snps,dis-u2-freeclk-exists-quirk;
+		snps,dis-del-phy-power-chg-quirk;
+		snps,dis-tx-ipgap-linecheck-quirk;
+		snps,dis_rxdet_inp3_quirk;
+		status = "disabled";
+	};
+
+	pmu1grf: syscon@fd58a000 {
+		compatible = "rockchip,rk3588-pmugrf", "syscon", "simple-mfd";
+		reg = <0x0 0xfd58a000 0x0 0x10000>;
+	};
+
 	sys_grf: syscon@fd58c000 {
 		compatible = "rockchip,rk3588-sys-grf", "syscon";
 		reg = <0x0 0xfd58c000 0x0 0x1000>;
 	};
 
+	vop_grf: syscon@fd5a4000 {
+		compatible = "rockchip,rk3588-vop-grf", "syscon";
+		reg = <0x0 0xfd5a4000 0x0 0x2000>;
+	};
+
+	vo1_grf: syscon@fd5a8000 {
+		compatible = "rockchip,rk3588-vo-grf", "syscon";
+		reg = <0x0 0xfd5a8000 0x0 0x100>;
+	};
+
 	php_grf: syscon@fd5b0000 {
 		compatible = "rockchip,rk3588-php-grf", "syscon";
 		reg = <0x0 0xfd5b0000 0x0 0x1000>;
@@ -567,6 +640,74 @@
 		status = "disabled";
 	};
 
+	vop: vop@fdd90000 {
+		compatible = "rockchip,rk3588-vop";
+		reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
+		reg-names = "vop", "gamma-lut";
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru ACLK_VOP>,
+			 <&cru HCLK_VOP>,
+			 <&cru DCLK_VOP0>,
+			 <&cru DCLK_VOP1>,
+			 <&cru DCLK_VOP2>,
+			 <&cru DCLK_VOP3>,
+			 <&cru PCLK_VOP_ROOT>;
+		clock-names = "aclk",
+			      "hclk",
+			      "dclk_vp0",
+			      "dclk_vp1",
+			      "dclk_vp2",
+			      "dclk_vp3",
+			      "pclk_vop";
+		iommus = <&vop_mmu>;
+		power-domains = <&power RK3588_PD_VOP>;
+		rockchip,grf = <&sys_grf>;
+		rockchip,vop-grf = <&vop_grf>;
+		rockchip,vo1-grf = <&vo1_grf>;
+		rockchip,pmu = <&pmu>;
+		status = "disabled";
+
+		vop_out: ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			vp0: port@0 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0>;
+			};
+
+			vp1: port@1 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <1>;
+			};
+
+			vp2: port@2 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <2>;
+			};
+
+			vp3: port@3 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <3>;
+			};
+		};
+	};
+
+	vop_mmu: iommu@fdd97e00 {
+		compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+		reg = <0x0 0xfdd97e00 0x0 0x100>, <0x0 0xfdd97f00 0x0 0x100>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>;
+		clock-names = "aclk", "iface";
+		#iommu-cells = <0>;
+		power-domains = <&power RK3588_PD_VOP>;
+		status = "disabled";
+	};
+
 	uart0: serial@fd890000 {
 		compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
 		reg = <0x0 0xfd890000 0x0 0x100>;
@@ -890,6 +1031,7 @@
 				reg = <RK3588_PD_USB>;
 				clocks = <&cru PCLK_PHP_ROOT>,
 					 <&cru ACLK_USB_ROOT>,
+					 <&cru ACLK_USB>,
 					 <&cru HCLK_USB_ROOT>,
 					 <&cru HCLK_HOST0>,
 					 <&cru HCLK_HOST_ARB0>,
@@ -1329,6 +1471,16 @@
 		};
 	};
 
+	dfi: dfi@fe060000 {
+		reg = <0x00 0xfe060000 0x00 0x10000>;
+		compatible = "rockchip,rk3588-dfi";
+		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>;
+		rockchip,pmu = <&pmu1grf>;
+	};
+
 	gmac1: ethernet@fe1c0000 {
 		compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";
 		reg = <0x0 0xfe1c0000 0x0 0x10000>;

-- 
2.43.0

Re: [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>
> This brings the real host2_xhci node as well as the pmu1grf node and
> spi0 to spi4 aliases from the next-20240110 Linux kernel. So also
> adapt/remove the nodes and aliases in rk3588s-u-boot.dtsi
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> [sync with v6.8-rc1]
> [remove spi0 to spi4 aliases from rk3588s-u-boot.dtsi]
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/dts/rk3588s-u-boot.dtsi |  36 ++--------
>   arch/arm/dts/rk3588s.dtsi        | 152 +++++++++++++++++++++++++++++++++++++++
>   2 files changed, 156 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
> index 9a5ffec926e..960ac4abda3 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -7,11 +7,6 @@
>   
>   / {
>   	aliases {
> -		spi0 = &spi0;
> -		spi1 = &spi1;
> -		spi2 = &spi2;
> -		spi3 = &spi3;
> -		spi4 = &spi4;
>   		spi5 = &sfc;
>   	};
>   
> @@ -43,33 +38,6 @@
>   		status = "disabled";
>   	};
>   
> -	usb_host2_xhci: usb@fcd00000 {
> -		compatible = "rockchip,rk3588-dwc3", "rockchip,rk3568-dwc3", "snps,dwc3";
> -		reg = <0x0 0xfcd00000 0x0 0x400000>;
> -		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH 0>;
> -		clocks = <&cru REF_CLK_USB3OTG2>, <&cru SUSPEND_CLK_USB3OTG2>,
> -			 <&cru ACLK_USB3OTG2>, <&cru CLK_UTMI_OTG2>,
> -			 <&cru CLK_PIPEPHY2_PIPE_U3_G>;
> -		clock-names = "ref_clk", "suspend_clk", "bus_clk", "utmi", "pipe";
> -		dr_mode = "host";
> -		phys = <&combphy2_psu PHY_TYPE_USB3>;
> -		phy-names = "usb3-phy";
> -		phy_type = "utmi_wide";
> -		resets = <&cru SRST_A_USB3OTG2>;
> -		snps,dis_enblslpm_quirk;
> -		snps,dis-u2-freeclk-exists-quirk;
> -		snps,dis-del-phy-power-chg-quirk;
> -		snps,dis-tx-ipgap-linecheck-quirk;
> -		snps,dis_rxdet_inp3_quirk;
> -		status = "disabled";
> -	};
> -
> -	pmu1_grf: syscon@fd58a000 {
> -		bootph-all;
> -		compatible = "rockchip,rk3588-pmugrf", "syscon";
> -		reg = <0x0 0xfd58a000 0x0 0x2000>;
> -	};
> -
>   	usbdpphy0_grf: syscon@fd5c8000 {
>   		compatible = "rockchip,rk3588-usbdpphy-grf", "syscon";
>   		reg = <0x0 0xfd5c8000 0x0 0x4000>;
> @@ -201,6 +169,10 @@
>   	status = "okay";
>   };
>   
> +&pmu1grf {
> +	bootph-all;
> +};
> +
>   &sys_grf {
>   	bootph-pre-ram;
>   	status = "okay";
> diff --git a/arch/arm/dts/rk3588s.dtsi b/arch/arm/dts/rk3588s.dtsi
> index 61a9a11c3bb..36b1b7acfe6 100644
> --- a/arch/arm/dts/rk3588s.dtsi
> +++ b/arch/arm/dts/rk3588s.dtsi
> @@ -18,6 +18,38 @@
>   	#address-cells = <2>;
>   	#size-cells = <2>;
>   
> +	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c3 = &i2c3;
> +		i2c4 = &i2c4;
> +		i2c5 = &i2c5;
> +		i2c6 = &i2c6;
> +		i2c7 = &i2c7;
> +		i2c8 = &i2c8;
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +		serial5 = &uart5;
> +		serial6 = &uart6;
> +		serial7 = &uart7;
> +		serial8 = &uart8;
> +		serial9 = &uart9;
> +		spi0 = &spi0;
> +		spi1 = &spi1;
> +		spi2 = &spi2;
> +		spi3 = &spi3;
> +		spi4 = &spi4;
> +	};
> +
>   	cpus {
>   		#address-cells = <1>;
>   		#size-cells = <0>;
> @@ -362,6 +394,11 @@
>   		#clock-cells = <0>;
>   	};
>   
> +	display_subsystem: display-subsystem {
> +		compatible = "rockchip,display-subsystem";
> +		ports = <&vop_out>;
> +	};
> +
>   	timer {
>   		compatible = "arm,armv8-timer";
>   		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
> @@ -443,11 +480,47 @@
>   		status = "disabled";
>   	};
>   
> +	usb_host2_xhci: usb@fcd00000 {
> +		compatible = "rockchip,rk3588-dwc3", "snps,dwc3";
> +		reg = <0x0 0xfcd00000 0x0 0x400000>;
> +		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru REF_CLK_USB3OTG2>, <&cru SUSPEND_CLK_USB3OTG2>,
> +			 <&cru ACLK_USB3OTG2>, <&cru CLK_UTMI_OTG2>,
> +			 <&cru CLK_PIPEPHY2_PIPE_U3_G>;
> +		clock-names = "ref_clk", "suspend_clk", "bus_clk", "utmi", "pipe";
> +		dr_mode = "host";
> +		phys = <&combphy2_psu PHY_TYPE_USB3>;
> +		phy-names = "usb3-phy";
> +		phy_type = "utmi_wide";
> +		resets = <&cru SRST_A_USB3OTG2>;
> +		snps,dis_enblslpm_quirk;
> +		snps,dis-u2-freeclk-exists-quirk;
> +		snps,dis-del-phy-power-chg-quirk;
> +		snps,dis-tx-ipgap-linecheck-quirk;
> +		snps,dis_rxdet_inp3_quirk;
> +		status = "disabled";
> +	};
> +
> +	pmu1grf: syscon@fd58a000 {
> +		compatible = "rockchip,rk3588-pmugrf", "syscon", "simple-mfd";
> +		reg = <0x0 0xfd58a000 0x0 0x10000>;
> +	};
> +
>   	sys_grf: syscon@fd58c000 {
>   		compatible = "rockchip,rk3588-sys-grf", "syscon";
>   		reg = <0x0 0xfd58c000 0x0 0x1000>;
>   	};
>   
> +	vop_grf: syscon@fd5a4000 {
> +		compatible = "rockchip,rk3588-vop-grf", "syscon";
> +		reg = <0x0 0xfd5a4000 0x0 0x2000>;
> +	};
> +
> +	vo1_grf: syscon@fd5a8000 {
> +		compatible = "rockchip,rk3588-vo-grf", "syscon";
> +		reg = <0x0 0xfd5a8000 0x0 0x100>;
> +	};
> +
>   	php_grf: syscon@fd5b0000 {
>   		compatible = "rockchip,rk3588-php-grf", "syscon";
>   		reg = <0x0 0xfd5b0000 0x0 0x1000>;
> @@ -567,6 +640,74 @@
>   		status = "disabled";
>   	};
>   
> +	vop: vop@fdd90000 {
> +		compatible = "rockchip,rk3588-vop";
> +		reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
> +		reg-names = "vop", "gamma-lut";
> +		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru ACLK_VOP>,
> +			 <&cru HCLK_VOP>,
> +			 <&cru DCLK_VOP0>,
> +			 <&cru DCLK_VOP1>,
> +			 <&cru DCLK_VOP2>,
> +			 <&cru DCLK_VOP3>,
> +			 <&cru PCLK_VOP_ROOT>;
> +		clock-names = "aclk",
> +			      "hclk",
> +			      "dclk_vp0",
> +			      "dclk_vp1",
> +			      "dclk_vp2",
> +			      "dclk_vp3",
> +			      "pclk_vop";
> +		iommus = <&vop_mmu>;
> +		power-domains = <&power RK3588_PD_VOP>;
> +		rockchip,grf = <&sys_grf>;
> +		rockchip,vop-grf = <&vop_grf>;
> +		rockchip,vo1-grf = <&vo1_grf>;
> +		rockchip,pmu = <&pmu>;
> +		status = "disabled";
> +
> +		vop_out: ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			vp0: port@0 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <0>;
> +			};
> +
> +			vp1: port@1 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <1>;
> +			};
> +
> +			vp2: port@2 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <2>;
> +			};
> +
> +			vp3: port@3 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <3>;
> +			};
> +		};
> +	};
> +
> +	vop_mmu: iommu@fdd97e00 {
> +		compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> +		reg = <0x0 0xfdd97e00 0x0 0x100>, <0x0 0xfdd97f00 0x0 0x100>;
> +		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>;
> +		clock-names = "aclk", "iface";
> +		#iommu-cells = <0>;
> +		power-domains = <&power RK3588_PD_VOP>;
> +		status = "disabled";
> +	};
> +
>   	uart0: serial@fd890000 {
>   		compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
>   		reg = <0x0 0xfd890000 0x0 0x100>;
> @@ -890,6 +1031,7 @@
>   				reg = <RK3588_PD_USB>;
>   				clocks = <&cru PCLK_PHP_ROOT>,
>   					 <&cru ACLK_USB_ROOT>,
> +					 <&cru ACLK_USB>,
>   					 <&cru HCLK_USB_ROOT>,
>   					 <&cru HCLK_HOST0>,
>   					 <&cru HCLK_HOST_ARB0>,
> @@ -1329,6 +1471,16 @@
>   		};
>   	};
>   
> +	dfi: dfi@fe060000 {
> +		reg = <0x00 0xfe060000 0x00 0x10000>;
> +		compatible = "rockchip,rk3588-dfi";
> +		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>;
> +		rockchip,pmu = <&pmu1grf>;
> +	};
> +
>   	gmac1: ethernet@fe1c0000 {
>   		compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";
>   		reg = <0x0 0xfe1c0000 0x0 0x10000>;
>

[PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

The expected length of the cpuid, as passed with cpuid_length,
determines the size of cpuid_str string. Therefore, care should be taken
to make sure nothing is accessing data out-of-bounds.

Instead of using hardcoded values, derive them from cpuid_length.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/mach-rockchip/misc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index 7d03f0c2b67..15397cff009 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -102,7 +102,7 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
 	int i;
 
 	memset(cpuid_str, 0, sizeof(cpuid_str));
-	for (i = 0; i < 16; i++)
+	for (i = 0; i < cpuid_length; i++)
 		sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
 
 	debug("cpuid: %s\n", cpuid_str);
@@ -111,13 +111,13 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
 	 * Mix the cpuid bytes using the same rules as in
 	 *   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
 	 */
-	for (i = 0; i < 8; i++) {
+	for (i = 0; i < cpuid_length / 2; i++) {
 		low[i] = cpuid[1 + (i << 1)];
 		high[i] = cpuid[i << 1];
 	}
 
-	serialno = crc32_no_comp(0, low, 8);
-	serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
+	serialno = crc32_no_comp(0, low, cpuid_length / 2);
+	serialno |= (u64)crc32_no_comp(serialno, high, cpuid_length / 2) << 32;
 	snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
 
 	oldid = env_get("cpuid#");

-- 
2.43.0

Re: [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> The expected length of the cpuid, as passed with cpuid_length,
> determines the size of cpuid_str string. Therefore, care should be taken
> to make sure nothing is accessing data out-of-bounds.
>
> Instead of using hardcoded values, derive them from cpuid_length.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/mach-rockchip/misc.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
> index 7d03f0c2b67..15397cff009 100644
> --- a/arch/arm/mach-rockchip/misc.c
> +++ b/arch/arm/mach-rockchip/misc.c
> @@ -102,7 +102,7 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
>   	int i;
>   
>   	memset(cpuid_str, 0, sizeof(cpuid_str));
> -	for (i = 0; i < 16; i++)
> +	for (i = 0; i < cpuid_length; i++)
>   		sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
>   
>   	debug("cpuid: %s\n", cpuid_str);
> @@ -111,13 +111,13 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
>   	 * Mix the cpuid bytes using the same rules as in
>   	 *   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
>   	 */
> -	for (i = 0; i < 8; i++) {
> +	for (i = 0; i < cpuid_length / 2; i++) {
>   		low[i] = cpuid[1 + (i << 1)];
>   		high[i] = cpuid[i << 1];
>   	}
>   
> -	serialno = crc32_no_comp(0, low, 8);
> -	serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
> +	serialno = crc32_no_comp(0, low, cpuid_length / 2);
> +	serialno |= (u64)crc32_no_comp(serialno, high, cpuid_length / 2) << 32;
>   	snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
>   
>   	oldid = env_get("cpuid#");
>

[PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Most Rockchip boards who override misc_init_r do it only to call another
function and keep the rest unchanged. Therefore to allow for less
duplication, let's just add a weak function symbol that is called inside
misc_init_r.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/mach-rockchip/board.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 2620530e03f..d5cb59c10fa 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -297,6 +297,11 @@ int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
 #endif
 
 #ifdef CONFIG_MISC_INIT_R
+__weak int rockchip_early_misc_init_r(void)
+{
+	return 0;
+}
+
 __weak int misc_init_r(void)
 {
 	const u32 cpuid_offset = CFG_CPUID_OFFSET;
@@ -304,6 +309,10 @@ __weak int misc_init_r(void)
 	u8 cpuid[cpuid_length];
 	int ret;
 
+	ret = rockchip_early_misc_init_r();
+	if (ret)
+		return ret;
+
 	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
 	if (ret)
 		return ret;

-- 
2.43.0

Re: [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Most Rockchip boards who override misc_init_r do it only to call another
> function and keep the rest unchanged. Therefore to allow for less
> duplication, let's just add a weak function symbol that is called inside
> misc_init_r.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/mach-rockchip/board.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 2620530e03f..d5cb59c10fa 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -297,6 +297,11 @@ int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
>   #endif
>   
>   #ifdef CONFIG_MISC_INIT_R
> +__weak int rockchip_early_misc_init_r(void)
> +{
> +	return 0;
> +}
> +
>   __weak int misc_init_r(void)
>   {
>   	const u32 cpuid_offset = CFG_CPUID_OFFSET;
> @@ -304,6 +309,10 @@ __weak int misc_init_r(void)
>   	u8 cpuid[cpuid_length];
>   	int ret;
>   
> +	ret = rockchip_early_misc_init_r();
> +	if (ret)
> +		return ret;
> +
>   	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
>   	if (ret)
>   		return ret;
>

Re: [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r

[Dragan Simic]

Hello Quentin,

This patch looks good to me, avoiding unnecessary code duplication
is always welcome.  My "Reviewed-by" is included below.

However, I've got some more comments,  which I'll send separately
for the other patches in this series.


On 2024-01-23 15:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> Most Rockchip boards who override misc_init_r do it only to call 
> another
> function and keep the rest unchanged. Therefore to allow for less
> duplication, let's just add a weak function symbol that is called 
> inside
> misc_init_r.
> 
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Reviewed-by: Dragan Simic <dsimic@manjaro.org>

> ---
>  arch/arm/mach-rockchip/board.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/mach-rockchip/board.c 
> b/arch/arm/mach-rockchip/board.c
> index 2620530e03f..d5cb59c10fa 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -297,6 +297,11 @@ int fastboot_set_reboot_flag(enum
> fastboot_reboot_reason reason)
>  #endif
> 
>  #ifdef CONFIG_MISC_INIT_R
> +__weak int rockchip_early_misc_init_r(void)
> +{
> +	return 0;
> +}
> +
>  __weak int misc_init_r(void)
>  {
>  	const u32 cpuid_offset = CFG_CPUID_OFFSET;
> @@ -304,6 +309,10 @@ __weak int misc_init_r(void)
>  	u8 cpuid[cpuid_length];
>  	int ret;
> 
> +	ret = rockchip_early_misc_init_r();
> +	if (ret)
> +		return ret;
> +
>  	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
>  	if (ret)
>  		return ret;

[PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Only setup_iodomain() differs from the original misc_init_r from
Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
reimplementing the whole misc_init_r from Rockchip.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 board/google/gru/gru.c | 20 ++------------------
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
index fbcf845e87d..ecbf702b035 100644
--- a/board/google/gru/gru.c
+++ b/board/google/gru/gru.c
@@ -11,7 +11,6 @@
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/arch-rockchip/misc.h>
 
 #define GRF_IO_VSEL_BT656_SHIFT 0
 #define GRF_IO_VSEL_AUDIO_SHIFT 1
@@ -85,24 +84,9 @@ static void setup_iodomain(void)
 				      1 << PMUGRF_CON0_VOL_SHIFT));
 }
 
-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-	const u32 cpuid_offset = 0x7;
-	const u32 cpuid_length = 0x10;
-	u8 cpuid[cpuid_length];
-	int ret;
-
 	setup_iodomain();
 
-	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
-	if (ret)
-		return ret;
-
-	ret = rockchip_cpuid_set(cpuid, cpuid_length);
-	if (ret)
-		return ret;
-
-	ret = rockchip_setup_macaddr();
-
-	return ret;
+	return 0;
 }

-- 
2.43.0

Re: [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Only setup_iodomain() differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   board/google/gru/gru.c | 20 ++------------------
>   1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
> index fbcf845e87d..ecbf702b035 100644
> --- a/board/google/gru/gru.c
> +++ b/board/google/gru/gru.c
> @@ -11,7 +11,6 @@
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/arch-rockchip/misc.h>
>   
>   #define GRF_IO_VSEL_BT656_SHIFT 0
>   #define GRF_IO_VSEL_AUDIO_SHIFT 1
> @@ -85,24 +84,9 @@ static void setup_iodomain(void)
>   				      1 << PMUGRF_CON0_VOL_SHIFT));
>   }
>   
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>   {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
>   	setup_iodomain();
>   
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_setup_macaddr();
> -
> -	return ret;
> +	return 0;
>   }
>

[PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Compared to the original misc_init_r from Rockchip mach code,
setup_iodomain() is added and rockchip_setup_macaddr() is not called.

It is assumed adding rockchip_setup_macaddr() back is fine.
Let's use rockchip_early_misc_init_r instead of reimplementing the whole
misc_init_r from Rockchip (the side effect being that
rockchip_setup_macaddr() is back).

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
index 4ad780767ea..2408a367305 100644
--- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
+++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
@@ -11,7 +11,6 @@
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/arch-rockchip/misc.h>
 #include <linux/printk.h>
 #include <power/regulator.h>
 
@@ -54,23 +53,10 @@ static void setup_iodomain(void)
 	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
 }
 
-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-	const u32 cpuid_offset = 0x7;
-	const u32 cpuid_length = 0x10;
-	u8 cpuid[cpuid_length];
-	int ret;
-
 	setup_iodomain();
 
-	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
-	if (ret)
-		return ret;
-
-	ret = rockchip_cpuid_set(cpuid, cpuid_length);
-	if (ret)
-		return ret;
-
-	return ret;
+	return 0;
 }
 #endif

-- 
2.43.0

Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18 ++----------------
>   1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> index 4ad780767ea..2408a367305 100644
> --- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> +++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> @@ -11,7 +11,6 @@
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/arch-rockchip/misc.h>
>   #include <linux/printk.h>
>   #include <power/regulator.h>
>   
> @@ -54,23 +53,10 @@ static void setup_iodomain(void)
>   	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>   }
>   
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>   {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
>   	setup_iodomain();
>   
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> -
> -	return ret;
> +	return 0;
>   }
>   #endif
>

Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Kever and Quentin,

On 2024-02-01 03:48, Kever Yang wrote:
> On 2024/1/23 22:49, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>> 
>> Compared to the original misc_init_r from Rockchip mach code,
>> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>> 
>> It is assumed adding rockchip_setup_macaddr() back is fine.
>> Let's use rockchip_early_misc_init_r instead of reimplementing the 
>> whole
>> misc_init_r from Rockchip (the side effect being that
>> rockchip_setup_macaddr() is back).

We might actually introduce some issues with this change.  I'll get
back later with a more detailed explanation, together with a proposed
fix, after I check it all in detail.

This applies to some other patches in this series as well.

>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
> 
> Thanks,
> - Kever
>> ---
>>   board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18 
>> ++----------------
>>   1 file changed, 2 insertions(+), 16 deletions(-)
>> 
>> diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c 
>> b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
>> index 4ad780767ea..2408a367305 100644
>> --- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
>> +++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
>> @@ -11,7 +11,6 @@
>>   #include <asm/arch-rockchip/clock.h>
>>   #include <asm/arch-rockchip/grf_rk3399.h>
>>   #include <asm/arch-rockchip/hardware.h>
>> -#include <asm/arch-rockchip/misc.h>
>>   #include <linux/printk.h>
>>   #include <power/regulator.h>
>>   @@ -54,23 +53,10 @@ static void setup_iodomain(void)
>>   	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>   }
>>   -int misc_init_r(void)
>> +int rockchip_early_misc_init_r(void)
>>   {
>> -	const u32 cpuid_offset = 0x7;
>> -	const u32 cpuid_length = 0x10;
>> -	u8 cpuid[cpuid_length];
>> -	int ret;
>> -
>>   	setup_iodomain();
>>   -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, 
>> cpuid);
>> -	if (ret)
>> -		return ret;
>> -
>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>> -	if (ret)
>> -		return ret;
>> -
>> -	return ret;
>> +	return 0;
>>   }
>>   #endif
>> 

Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

Hi Dragan,

On 2/1/24 05:02, Dragan Simic wrote:
> [Some people who received this message don't often get email from 
> dsimic@manjaro.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello Kever and Quentin,
> 
> On 2024-02-01 03:48, Kever Yang wrote:
>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>
>>> Compared to the original misc_init_r from Rockchip mach code,
>>> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>>>
>>> It is assumed adding rockchip_setup_macaddr() back is fine.
>>> Let's use rockchip_early_misc_init_r instead of reimplementing the
>>> whole
>>> misc_init_r from Rockchip (the side effect being that
>>> rockchip_setup_macaddr() is back).
> 
> We might actually introduce some issues with this change.  I'll get
> back later with a more detailed explanation, together with a proposed
> fix, after I check it all in detail.
> 
> This applies to some other patches in this series as well.
> 

I assume this is specifically about the migration to 
rockchip_early_misc_init_r?

What's the issue? And for which devices?

I don't really need this patch, it's just to avoid code duplication in a 
later patch but I'd rather not have this block this patch series. We can 
always revisit this in a separate patch series which can take as long as 
we want.

Cheers,
Quentin

Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Quentin,

On 2024-02-01 18:46, Quentin Schulz wrote:
> On 2/1/24 05:02, Dragan Simic wrote:
>> On 2024-02-01 03:48, Kever Yang wrote:
>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>> 
>>>> Compared to the original misc_init_r from Rockchip mach code,
>>>> setup_iodomain() is added and rockchip_setup_macaddr() is not 
>>>> called.
>>>> 
>>>> It is assumed adding rockchip_setup_macaddr() back is fine.
>>>> Let's use rockchip_early_misc_init_r instead of reimplementing the
>>>> whole
>>>> misc_init_r from Rockchip (the side effect being that
>>>> rockchip_setup_macaddr() is back).
>> 
>> We might actually introduce some issues with this change.  I'll get
>> back later with a more detailed explanation, together with a proposed
>> fix, after I check it all in detail.
>> 
>> This applies to some other patches in this series as well.
>> 
> I assume this is specifically about the migration to 
> rockchip_early_misc_init_r?
> 
> What's the issue? And for which devices?
> 
> I don't really need this patch, it's just to avoid code duplication in
> a later patch but I'd rather not have this block this patch series. We
> can always revisit this in a separate patch series which can take as
> long as we want.

I should be able to provide all the details later today or tomorrow,
together with the proposed fix.  Perhaps such a timeline should be
acceptable, by not introducing some significant delays.

Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Quentin and Kever,

Please see my comments below.

On 2024-02-01 05:02, Dragan Simic wrote:
> On 2024-02-01 03:48, Kever Yang wrote:
>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>> 
>>> Compared to the original misc_init_r from Rockchip mach code,
>>> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>>> 
>>> It is assumed adding rockchip_setup_macaddr() back is fine.
>>> Let's use rockchip_early_misc_init_r instead of reimplementing the 
>>> whole
>>> misc_init_r from Rockchip (the side effect being that
>>> rockchip_setup_macaddr() is back).

The patch subject should include "pinebook-pro" instead of just
"pinebook".  Those are two quite different devices.

Please see my comments on your 08/18 patch in this series, for the
RockPro64, which also apply to the Pinebook Pro.

> We might actually introduce some issues with this change.  I'll get
> back later with a more detailed explanation, together with a proposed
> fix, after I check it all in detail.
> 
> This applies to some other patches in this series as well.
> 
>>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
>> 
>> Thanks,
>> - Kever
>>> ---
>>>   board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18 
>>> ++----------------
>>>   1 file changed, 2 insertions(+), 16 deletions(-)
>>> 
>>> diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c 
>>> b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
>>> index 4ad780767ea..2408a367305 100644
>>> --- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
>>> +++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
>>> @@ -11,7 +11,6 @@
>>>   #include <asm/arch-rockchip/clock.h>
>>>   #include <asm/arch-rockchip/grf_rk3399.h>
>>>   #include <asm/arch-rockchip/hardware.h>
>>> -#include <asm/arch-rockchip/misc.h>
>>>   #include <linux/printk.h>
>>>   #include <power/regulator.h>
>>>   @@ -54,23 +53,10 @@ static void setup_iodomain(void)
>>>   	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>>   }
>>>   -int misc_init_r(void)
>>> +int rockchip_early_misc_init_r(void)
>>>   {
>>> -	const u32 cpuid_offset = 0x7;
>>> -	const u32 cpuid_length = 0x10;
>>> -	u8 cpuid[cpuid_length];
>>> -	int ret;
>>> -
>>>   	setup_iodomain();
>>>   -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, 
>>> cpuid);
>>> -	if (ret)
>>> -		return ret;
>>> -
>>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>>> -	if (ret)
>>> -		return ret;
>>> -
>>> -	return ret;
>>> +	return 0;
>>>   }
>>>   #endif
>>> 

[PATCH 07/18] rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Compared to the original misc_init_r from Rockchip mach code,
setup_iodomain() is added and rockchip_setup_macaddr() is not called.

It is assumed adding rockchip_setup_macaddr() back is fine.
Let's use rockchip_early_misc_init_r instead of reimplementing the whole
misc_init_r from Rockchip (the side effect being that
rockchip_setup_macaddr() is back).

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 .../pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c  | 17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
index b6ccbb9c1c4..de75ee329d8 100644
--- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
+++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
@@ -12,7 +12,6 @@
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/arch-rockchip/misc.h>
 #include <power/regulator.h>
 
 #define GRF_IO_VSEL_BT565_GPIO2AB 1
@@ -56,23 +55,11 @@ static void setup_iodomain(void)
 	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
 }
 
-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-	const u32 cpuid_offset = 0x7;
-	const u32 cpuid_length = 0x10;
-	u8 cpuid[cpuid_length];
-	int ret;
-
 	setup_iodomain();
 
-	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
-	if (ret)
-		return ret;
-
-	ret = rockchip_cpuid_set(cpuid, cpuid_length);
-	if (ret)
-		return ret;
+	return 0;
 
-	return ret;
 }
 #endif

-- 
2.43.0

Re: [PATCH 07/18] rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   .../pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c  | 17 ++---------------
>   1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> index b6ccbb9c1c4..de75ee329d8 100644
> --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> @@ -12,7 +12,6 @@
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/arch-rockchip/misc.h>
>   #include <power/regulator.h>
>   
>   #define GRF_IO_VSEL_BT565_GPIO2AB 1
> @@ -56,23 +55,11 @@ static void setup_iodomain(void)
>   	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>   }
>   
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>   {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
>   	setup_iodomain();
>   
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> +	return 0;
>   
> -	return ret;
>   }
>   #endif
>

Re: [PATCH 07/18] rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Quentin,

Please see my comments below.

On 2024-01-23 15:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
> 
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the 
> whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).

The patch subject should include "pinephone-pro" instead of just
"pinephone".  Those are two quite different devices.

Please see my comments on your 08/18 patch in this series, for the
RockPro64, which also apply to the Pinephone Pro.

> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>  .../pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c  | 17 
> ++---------------
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> index b6ccbb9c1c4..de75ee329d8 100644
> --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> @@ -12,7 +12,6 @@
>  #include <asm/arch-rockchip/clock.h>
>  #include <asm/arch-rockchip/grf_rk3399.h>
>  #include <asm/arch-rockchip/hardware.h>
> -#include <asm/arch-rockchip/misc.h>
>  #include <power/regulator.h>
> 
>  #define GRF_IO_VSEL_BT565_GPIO2AB 1
> @@ -56,23 +55,11 @@ static void setup_iodomain(void)
>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>  }
> 
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>  {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
>  	setup_iodomain();
> 
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> +	return 0;
> 
> -	return ret;
>  }
>  #endif

[PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Only setup_iodomain() differs from the original misc_init_r from
Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
reimplementing the whole misc_init_r from Rockchip.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20 ++------------------
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
index d79084614f1..d0a694ead1d 100644
--- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
+++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
@@ -11,7 +11,6 @@
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/arch-rockchip/misc.h>
 
 #define GRF_IO_VSEL_BT565_SHIFT 0
 #define PMUGRF_CON0_VSEL_SHIFT 8
@@ -31,26 +30,11 @@ static void setup_iodomain(void)
 	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
 }
 
-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-	const u32 cpuid_offset = 0x7;
-	const u32 cpuid_length = 0x10;
-	u8 cpuid[cpuid_length];
-	int ret;
-
 	setup_iodomain();
 
-	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
-	if (ret)
-		return ret;
-
-	ret = rockchip_cpuid_set(cpuid, cpuid_length);
-	if (ret)
-		return ret;
-
-	ret = rockchip_setup_macaddr();
-
-	return ret;
+	return 0;
 }
 
 #endif

-- 
2.43.0

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Only setup_iodomain() differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20 ++------------------
>   1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> index d79084614f1..d0a694ead1d 100644
> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> @@ -11,7 +11,6 @@
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/arch-rockchip/misc.h>
>   
>   #define GRF_IO_VSEL_BT565_SHIFT 0
>   #define PMUGRF_CON0_VSEL_SHIFT 8
> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>   	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>   }
>   
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>   {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
>   	setup_iodomain();
>   
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_setup_macaddr();
> -
> -	return ret;
> +	return 0;
>   }
>   
>   #endif
>

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Quentin,

Please see my comments below.

On 2024-01-23 15:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> Only setup_iodomain() differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.

Your patches from this series are fine, but the trouble is that
we end up executing rockchip_setup_macaddr() for the devices
that don't use the RK3339's built-in Gigabit Ethernet interface,
which includes the Pinebook Pro and the Pinephone Pro.

We should add more ifdef guards to rockchip_setup_macaddr(),
to prevent the execution of its body for devices such as the
ones listed above, which eliminates the unneeded code from the
resulting U-Boot images, making them a bit smaller, and saves
some CPU cycles and a bit of time on boot.  It also prevents
the unneeded "ethaddr" and "eth1addr" variables from being
added to the environment.

The patch below should do the trick, which also performs a few
small code cleanups for additional file-level consistency:

diff --git a/arch/arm/mach-rockchip/misc.c 
b/arch/arm/mach-rockchip/misc.c
index 7d03f0c2b679..ed5bdab5a648 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -23,7 +23,8 @@

  int rockchip_setup_macaddr(void)
  {
-#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
+#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
+    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
  	int ret;
  	const char *cpuid = env_get("cpuid#");
  	u8 hash[SHA256_SUM_LEN];
@@ -64,15 +65,15 @@ int rockchip_cpuid_from_efuse(const u32 
cpuid_offset,
  			      const u32 cpuid_length,
  			      u8 *cpuid)
  {
-#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) || 
IS_ENABLED(CONFIG_ROCKCHIP_OTP)
+#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE) || 
CONFIG_IS_ENABLED(ROCKCHIP_OTP)
  	struct udevice *dev;
  	int ret;

  	/* retrieve the device */
-#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
+#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
  	ret = uclass_get_device_by_driver(UCLASS_MISC,
  					  DM_DRIVER_GET(rockchip_efuse), &dev);
-#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
+#elif CONFIG_IS_ENABLED(ROCKCHIP_OTP)
  	ret = uclass_get_device_by_driver(UCLASS_MISC,
  					  DM_DRIVER_GET(rockchip_otp), &dev);
  #endif

> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20 
> ++------------------
>  1 file changed, 2 insertions(+), 18 deletions(-)
> 
> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> index d79084614f1..d0a694ead1d 100644
> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> @@ -11,7 +11,6 @@
>  #include <asm/arch-rockchip/clock.h>
>  #include <asm/arch-rockchip/grf_rk3399.h>
>  #include <asm/arch-rockchip/hardware.h>
> -#include <asm/arch-rockchip/misc.h>
> 
>  #define GRF_IO_VSEL_BT565_SHIFT 0
>  #define PMUGRF_CON0_VSEL_SHIFT 8
> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>  }
> 
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>  {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
>  	setup_iodomain();
> 
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_setup_macaddr();
> -
> -	return ret;
> +	return 0;
>  }
> 
>  #endif

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Jonas Karlman]

Hi Dragan,

On 2024-02-03 14:19, Dragan Simic wrote:
> Hello Quentin,
> 
> Please see my comments below.
> 
> On 2024-01-23 15:49, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> Only setup_iodomain() differs from the original misc_init_r from
>> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
>> reimplementing the whole misc_init_r from Rockchip.
> 
> Your patches from this series are fine, but the trouble is that
> we end up executing rockchip_setup_macaddr() for the devices
> that don't use the RK3339's built-in Gigabit Ethernet interface,
> which includes the Pinebook Pro and the Pinephone Pro.

The rockchip_setup_macaddr() is not just for integrated ethernet
interface. The main purpose is to have a reliably mac address assigned
to any device assigned to the ethernet0/ethernet1 alias in the device
tree, see fdt_fixup_ethernet().

> 
> We should add more ifdef guards to rockchip_setup_macaddr(),
> to prevent the execution of its body for devices such as the
> ones listed above, which eliminates the unneeded code from the
> resulting U-Boot images, making them a bit smaller, and saves
> some CPU cycles and a bit of time on boot.  It also prevents
> the unneeded "ethaddr" and "eth1addr" variables from being
> added to the environment.

Adding the ethernet addresses only adds a few ms to boot, if you care
about boot speed, please look into if we can disable CONFIG_USE_PREBOOT
for these boards, running "usb start" as preboot adds several seconds to
the boot.

> 
> The patch below should do the trick, which also performs a few
> small code cleanups for additional file-level consistency:
> 
> diff --git a/arch/arm/mach-rockchip/misc.c 
> b/arch/arm/mach-rockchip/misc.c
> index 7d03f0c2b679..ed5bdab5a648 100644
> --- a/arch/arm/mach-rockchip/misc.c
> +++ b/arch/arm/mach-rockchip/misc.c
> @@ -23,7 +23,8 @@
> 
>   int rockchip_setup_macaddr(void)
>   {
> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)

This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot but
want a mac-address being set in DT fixup. And for newer RK35xx SoCs the
GMAC_ROCKCHIP driver is not used.

A new Kconfig option should be introduced if there is a need for some
boards to disable this.

>   	int ret;
>   	const char *cpuid = env_get("cpuid#");
>   	u8 hash[SHA256_SUM_LEN];
> @@ -64,15 +65,15 @@ int rockchip_cpuid_from_efuse(const u32 
> cpuid_offset,
>   			      const u32 cpuid_length,
>   			      u8 *cpuid)
>   {
> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) || 
> IS_ENABLED(CONFIG_ROCKCHIP_OTP)
> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE) || 

This changes behavior and is wrong. IS_ENABLED check for specific config
flag, CONFIG_IS_ENABLED would check for e.g. CONFIG_SPL_ROCKCHIP_EFUSE
or similar.

> CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>   	struct udevice *dev;
>   	int ret;
> 
>   	/* retrieve the device */
> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)

Same as above.

>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>   					  DM_DRIVER_GET(rockchip_efuse), &dev);
> -#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
> +#elif CONFIG_IS_ENABLED(ROCKCHIP_OTP)

Same as above.

Regards,
Jonas

>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>   					  DM_DRIVER_GET(rockchip_otp), &dev);
>   #endif
> 
>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>> ---
>>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20 
>> ++------------------
>>  1 file changed, 2 insertions(+), 18 deletions(-)
>>
>> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>> index d79084614f1..d0a694ead1d 100644
>> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>> @@ -11,7 +11,6 @@
>>  #include <asm/arch-rockchip/clock.h>
>>  #include <asm/arch-rockchip/grf_rk3399.h>
>>  #include <asm/arch-rockchip/hardware.h>
>> -#include <asm/arch-rockchip/misc.h>
>>
>>  #define GRF_IO_VSEL_BT565_SHIFT 0
>>  #define PMUGRF_CON0_VSEL_SHIFT 8
>> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>  }
>>
>> -int misc_init_r(void)
>> +int rockchip_early_misc_init_r(void)
>>  {
>> -	const u32 cpuid_offset = 0x7;
>> -	const u32 cpuid_length = 0x10;
>> -	u8 cpuid[cpuid_length];
>> -	int ret;
>> -
>>  	setup_iodomain();
>>
>> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
>> -	if (ret)
>> -		return ret;
>> -
>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>> -	if (ret)
>> -		return ret;
>> -
>> -	ret = rockchip_setup_macaddr();
>> -
>> -	return ret;
>> +	return 0;
>>  }
>>
>>  #endif

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Jonas,

On 2024-02-03 15:18, Jonas Karlman wrote:
> On 2024-02-03 14:19, Dragan Simic wrote:
>> Please see my comments below.
>> 
>> On 2024-01-23 15:49, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>> 
>>> Only setup_iodomain() differs from the original misc_init_r from
>>> Rockchip mach code, so let's use rockchip_early_misc_init_r instead 
>>> of
>>> reimplementing the whole misc_init_r from Rockchip.
>> 
>> Your patches from this series are fine, but the trouble is that
>> we end up executing rockchip_setup_macaddr() for the devices
>> that don't use the RK3339's built-in Gigabit Ethernet interface,
>> which includes the Pinebook Pro and the Pinephone Pro.
> 
> The rockchip_setup_macaddr() is not just for integrated ethernet
> interface. The main purpose is to have a reliably mac address assigned
> to any device assigned to the ethernet0/ethernet1 alias in the device
> tree, see fdt_fixup_ethernet().

Sure, I had already checked fdt_fixup_ethernet() before commenting.

As a note, there are no ethernetX aliases in the Pinebook Pro and
Pinephone Pro dts files, or at least there will be none eventually,
as the redundant aliases have already been removed in the Linux
kernel. [1]  No such aliases means that fdt_fixup_ethernet() should
end up doing nothing.

>> We should add more ifdef guards to rockchip_setup_macaddr(),
>> to prevent the execution of its body for devices such as the
>> ones listed above, which eliminates the unneeded code from the
>> resulting U-Boot images, making them a bit smaller, and saves
>> some CPU cycles and a bit of time on boot.  It also prevents
>> the unneeded "ethaddr" and "eth1addr" variables from being
>> added to the environment.
> 
> Adding the ethernet addresses only adds a few ms to boot, if you care
> about boot speed, please look into if we can disable CONFIG_USE_PREBOOT
> for these boards, running "usb start" as preboot adds several seconds 
> to
> the boot.

I see, but I personally don't care that much about how long the
U-Boot takes to execute;  a couple of seconds more don't bother me
much.  I care more about excluding the unneded code.

>> The patch below should do the trick, which also performs a few
>> small code cleanups for additional file-level consistency:
>> 
>> diff --git a/arch/arm/mach-rockchip/misc.c
>> b/arch/arm/mach-rockchip/misc.c
>> index 7d03f0c2b679..ed5bdab5a648 100644
>> --- a/arch/arm/mach-rockchip/misc.c
>> +++ b/arch/arm/mach-rockchip/misc.c
>> @@ -23,7 +23,8 @@
>> 
>>   int rockchip_setup_macaddr(void)
>>   {
>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
> 
> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot but
> want a mac-address being set in DT fixup. And for newer RK35xx SoCs the
> GMAC_ROCKCHIP driver is not used.

Thanks for pointing that out.  Not good.

> A new Kconfig option should be introduced if there is a need for some
> boards to disable this.

Is there any simpler way to achieve that?  If there isn't, perhaps
we could leave rockchip_setup_macaddr() generate the MAC address
and rely on fdt_fixup_ethernet() ending up doing nothing when no
ethernetX aliases exist.

>>   	int ret;
>>   	const char *cpuid = env_get("cpuid#");
>>   	u8 hash[SHA256_SUM_LEN];
>> @@ -64,15 +65,15 @@ int rockchip_cpuid_from_efuse(const u32
>> cpuid_offset,
>>   			      const u32 cpuid_length,
>>   			      u8 *cpuid)
>>   {
>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) ||
>> IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE) ||
> 
> This changes behavior and is wrong. IS_ENABLED check for specific 
> config
> flag, CONFIG_IS_ENABLED would check for e.g. CONFIG_SPL_ROCKCHIP_EFUSE
> or similar.

Sorry, my bad, somehow I managed to forget that.  Thanks for
pointing that out.

>> CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>>   	struct udevice *dev;
>>   	int ret;
>> 
>>   	/* retrieve the device */
>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
> 
> Same as above.
> 
>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>   					  DM_DRIVER_GET(rockchip_efuse), &dev);
>> -#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>> +#elif CONFIG_IS_ENABLED(ROCKCHIP_OTP)
> 
> Same as above.
> 
> Regards,
> Jonas
> 
>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>   					  DM_DRIVER_GET(rockchip_otp), &dev);
>>   #endif
>> 
>>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>> ---
>>>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20
>>> ++------------------
>>>  1 file changed, 2 insertions(+), 18 deletions(-)
>>> 
>>> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>> index d79084614f1..d0a694ead1d 100644
>>> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>> @@ -11,7 +11,6 @@
>>>  #include <asm/arch-rockchip/clock.h>
>>>  #include <asm/arch-rockchip/grf_rk3399.h>
>>>  #include <asm/arch-rockchip/hardware.h>
>>> -#include <asm/arch-rockchip/misc.h>
>>> 
>>>  #define GRF_IO_VSEL_BT565_SHIFT 0
>>>  #define PMUGRF_CON0_VSEL_SHIFT 8
>>> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>>>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>>  }
>>> 
>>> -int misc_init_r(void)
>>> +int rockchip_early_misc_init_r(void)
>>>  {
>>> -	const u32 cpuid_offset = 0x7;
>>> -	const u32 cpuid_length = 0x10;
>>> -	u8 cpuid[cpuid_length];
>>> -	int ret;
>>> -
>>>  	setup_iodomain();
>>> 
>>> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
>>> -	if (ret)
>>> -		return ret;
>>> -
>>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>>> -	if (ret)
>>> -		return ret;
>>> -
>>> -	ret = rockchip_setup_macaddr();
>>> -
>>> -	return ret;
>>> +	return 0;
>>>  }
>>> 
>>>  #endif

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d90cb1edcf7c1854e4cecb52871421f29d3d849

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Dragan Simic]

On 2024-02-03 16:18, Dragan Simic wrote:
> On 2024-02-03 15:18, Jonas Karlman wrote:
>> On 2024-02-03 14:19, Dragan Simic wrote:
>>> Please see my comments below.
>>> 
>>> On 2024-01-23 15:49, Quentin Schulz wrote:
>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>> 
>>>> Only setup_iodomain() differs from the original misc_init_r from
>>>> Rockchip mach code, so let's use rockchip_early_misc_init_r instead 
>>>> of
>>>> reimplementing the whole misc_init_r from Rockchip.
>>> 
>>> Your patches from this series are fine, but the trouble is that
>>> we end up executing rockchip_setup_macaddr() for the devices
>>> that don't use the RK3339's built-in Gigabit Ethernet interface,
>>> which includes the Pinebook Pro and the Pinephone Pro.
>> 
>> The rockchip_setup_macaddr() is not just for integrated ethernet
>> interface. The main purpose is to have a reliably mac address assigned
>> to any device assigned to the ethernet0/ethernet1 alias in the device
>> tree, see fdt_fixup_ethernet().
> 
> Sure, I had already checked fdt_fixup_ethernet() before commenting.
> 
> As a note, there are no ethernetX aliases in the Pinebook Pro and
> Pinephone Pro dts files, or at least there will be none eventually,
> as the redundant aliases have already been removed in the Linux
> kernel. [1]  No such aliases means that fdt_fixup_ethernet() should
> end up doing nothing.
> 
>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>> to prevent the execution of its body for devices such as the
>>> ones listed above, which eliminates the unneeded code from the
>>> resulting U-Boot images, making them a bit smaller, and saves
>>> some CPU cycles and a bit of time on boot.  It also prevents
>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>> added to the environment.
>> 
>> Adding the ethernet addresses only adds a few ms to boot, if you care
>> about boot speed, please look into if we can disable 
>> CONFIG_USE_PREBOOT
>> for these boards, running "usb start" as preboot adds several seconds 
>> to
>> the boot.
> 
> I see, but I personally don't care that much about how long the
> U-Boot takes to execute;  a couple of seconds more don't bother me
> much.  I care more about excluding the unneded code.
> 
>>> The patch below should do the trick, which also performs a few
>>> small code cleanups for additional file-level consistency:
>>> 
>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>> b/arch/arm/mach-rockchip/misc.c
>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>> --- a/arch/arm/mach-rockchip/misc.c
>>> +++ b/arch/arm/mach-rockchip/misc.c
>>> @@ -23,7 +23,8 @@
>>> 
>>>   int rockchip_setup_macaddr(void)
>>>   {
>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>> 
>> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot but
>> want a mac-address being set in DT fixup. And for newer RK35xx SoCs 
>> the
>> GMAC_ROCKCHIP driver is not used.
> 
> Thanks for pointing that out.  Not good.
> 
>> A new Kconfig option should be introduced if there is a need for some
>> boards to disable this.
> 
> Is there any simpler way to achieve that?  If there isn't, perhaps
> we could leave rockchip_setup_macaddr() generate the MAC address
> and rely on fdt_fixup_ethernet() ending up doing nothing when no
> ethernetX aliases exist.

After going through the source code once again, I think that adding
new configuration option would be warranted, because it would exclude
two sizable chunks of code from the resulting U-Boot images, and
because it would avoid polluting the environment with a couple of
unneeded variables.

I'll go ahead and implement this, and I hope that the patch will be
received well.

>>>   	int ret;
>>>   	const char *cpuid = env_get("cpuid#");
>>>   	u8 hash[SHA256_SUM_LEN];
>>> @@ -64,15 +65,15 @@ int rockchip_cpuid_from_efuse(const u32
>>> cpuid_offset,
>>>   			      const u32 cpuid_length,
>>>   			      u8 *cpuid)
>>>   {
>>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) ||
>>> IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE) ||
>> 
>> This changes behavior and is wrong. IS_ENABLED check for specific 
>> config
>> flag, CONFIG_IS_ENABLED would check for e.g. CONFIG_SPL_ROCKCHIP_EFUSE
>> or similar.
> 
> Sorry, my bad, somehow I managed to forget that.  Thanks for
> pointing that out.
> 
>>> CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>>>   	struct udevice *dev;
>>>   	int ret;
>>> 
>>>   	/* retrieve the device */
>>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
>>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
>> 
>> Same as above.
>> 
>>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>>   					  DM_DRIVER_GET(rockchip_efuse), &dev);
>>> -#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>>> +#elif CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>> 
>> Same as above.
>> 
>> Regards,
>> Jonas
>> 
>>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>>   					  DM_DRIVER_GET(rockchip_otp), &dev);
>>>   #endif
>>> 
>>>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>>>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>> ---
>>>>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20
>>>> ++------------------
>>>>  1 file changed, 2 insertions(+), 18 deletions(-)
>>>> 
>>>> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>> index d79084614f1..d0a694ead1d 100644
>>>> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>> @@ -11,7 +11,6 @@
>>>>  #include <asm/arch-rockchip/clock.h>
>>>>  #include <asm/arch-rockchip/grf_rk3399.h>
>>>>  #include <asm/arch-rockchip/hardware.h>
>>>> -#include <asm/arch-rockchip/misc.h>
>>>> 
>>>>  #define GRF_IO_VSEL_BT565_SHIFT 0
>>>>  #define PMUGRF_CON0_VSEL_SHIFT 8
>>>> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>>>>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>>>  }
>>>> 
>>>> -int misc_init_r(void)
>>>> +int rockchip_early_misc_init_r(void)
>>>>  {
>>>> -	const u32 cpuid_offset = 0x7;
>>>> -	const u32 cpuid_length = 0x10;
>>>> -	u8 cpuid[cpuid_length];
>>>> -	int ret;
>>>> -
>>>>  	setup_iodomain();
>>>> 
>>>> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, 
>>>> cpuid);
>>>> -	if (ret)
>>>> -		return ret;
>>>> -
>>>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>>>> -	if (ret)
>>>> -		return ret;
>>>> -
>>>> -	ret = rockchip_setup_macaddr();
>>>> -
>>>> -	return ret;
>>>> +	return 0;
>>>>  }
>>>> 
>>>>  #endif
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d90cb1edcf7c1854e4cecb52871421f29d3d849

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Jonas Karlman]

On 2024-02-04 05:21, Dragan Simic wrote:
> On 2024-02-03 16:18, Dragan Simic wrote:
>> On 2024-02-03 15:18, Jonas Karlman wrote:
>>> On 2024-02-03 14:19, Dragan Simic wrote:
>>>> Please see my comments below.
>>>>
>>>> On 2024-01-23 15:49, Quentin Schulz wrote:
>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>
>>>>> Only setup_iodomain() differs from the original misc_init_r from
>>>>> Rockchip mach code, so let's use rockchip_early_misc_init_r instead 
>>>>> of
>>>>> reimplementing the whole misc_init_r from Rockchip.
>>>>
>>>> Your patches from this series are fine, but the trouble is that
>>>> we end up executing rockchip_setup_macaddr() for the devices
>>>> that don't use the RK3339's built-in Gigabit Ethernet interface,
>>>> which includes the Pinebook Pro and the Pinephone Pro.
>>>
>>> The rockchip_setup_macaddr() is not just for integrated ethernet
>>> interface. The main purpose is to have a reliably mac address assigned
>>> to any device assigned to the ethernet0/ethernet1 alias in the device
>>> tree, see fdt_fixup_ethernet().
>>
>> Sure, I had already checked fdt_fixup_ethernet() before commenting.
>>
>> As a note, there are no ethernetX aliases in the Pinebook Pro and
>> Pinephone Pro dts files, or at least there will be none eventually,
>> as the redundant aliases have already been removed in the Linux
>> kernel. [1]  No such aliases means that fdt_fixup_ethernet() should
>> end up doing nothing.
>>
>>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>>> to prevent the execution of its body for devices such as the
>>>> ones listed above, which eliminates the unneeded code from the
>>>> resulting U-Boot images, making them a bit smaller, and saves
>>>> some CPU cycles and a bit of time on boot.  It also prevents
>>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>>> added to the environment.
>>>
>>> Adding the ethernet addresses only adds a few ms to boot, if you care
>>> about boot speed, please look into if we can disable 
>>> CONFIG_USE_PREBOOT
>>> for these boards, running "usb start" as preboot adds several seconds 
>>> to
>>> the boot.
>>
>> I see, but I personally don't care that much about how long the
>> U-Boot takes to execute;  a couple of seconds more don't bother me
>> much.  I care more about excluding the unneded code.
>>
>>>> The patch below should do the trick, which also performs a few
>>>> small code cleanups for additional file-level consistency:
>>>>
>>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>>> b/arch/arm/mach-rockchip/misc.c
>>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>>> --- a/arch/arm/mach-rockchip/misc.c
>>>> +++ b/arch/arm/mach-rockchip/misc.c
>>>> @@ -23,7 +23,8 @@
>>>>
>>>>   int rockchip_setup_macaddr(void)
>>>>   {
>>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>>>
>>> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot but
>>> want a mac-address being set in DT fixup. And for newer RK35xx SoCs 
>>> the
>>> GMAC_ROCKCHIP driver is not used.
>>
>> Thanks for pointing that out.  Not good.
>>
>>> A new Kconfig option should be introduced if there is a need for some
>>> boards to disable this.
>>
>> Is there any simpler way to achieve that?  If there isn't, perhaps
>> we could leave rockchip_setup_macaddr() generate the MAC address
>> and rely on fdt_fixup_ethernet() ending up doing nothing when no
>> ethernetX aliases exist.

As Chen-Yu Tsai pointed out in one of my prior patches [2]:

 The user might be loading a custom FDT for the kernel, or have DT
 overlays stacked on, either could have the "ethernet1" alias while
 the U-boot DT doesn't.

So the common rockchip_setup_macaddr() cannot rely on checking for
ethernetX alias, because the fixup may not run against the bundled DT.

[2] https://lore.kernel.org/u-boot/CAGb2v66hR5e3nBPZ0C3=h29fS4Um7whfBu7XTAi1sRbzXRAPxg@mail.gmail.com/

> 
> After going through the source code once again, I think that adding
> new configuration option would be warranted, because it would exclude
> two sizable chunks of code from the resulting U-Boot images, and
> because it would avoid polluting the environment with a couple of
> unneeded variables.

Yes a new Kconfig option would be preferred.

> 
> I'll go ahead and implement this, and I hope that the patch will be
> received well.

Great :-)

Regards,
Jonas

> 
>>>>   	int ret;
>>>>   	const char *cpuid = env_get("cpuid#");
>>>>   	u8 hash[SHA256_SUM_LEN];
>>>> @@ -64,15 +65,15 @@ int rockchip_cpuid_from_efuse(const u32
>>>> cpuid_offset,
>>>>   			      const u32 cpuid_length,
>>>>   			      u8 *cpuid)
>>>>   {
>>>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) ||
>>>> IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>>>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE) ||
>>>
>>> This changes behavior and is wrong. IS_ENABLED check for specific 
>>> config
>>> flag, CONFIG_IS_ENABLED would check for e.g. CONFIG_SPL_ROCKCHIP_EFUSE
>>> or similar.
>>
>> Sorry, my bad, somehow I managed to forget that.  Thanks for
>> pointing that out.
>>
>>>> CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>>>>   	struct udevice *dev;
>>>>   	int ret;
>>>>
>>>>   	/* retrieve the device */
>>>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
>>>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
>>>
>>> Same as above.
>>>
>>>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>>>   					  DM_DRIVER_GET(rockchip_efuse), &dev);
>>>> -#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>>>> +#elif CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>>>
>>> Same as above.
>>>
>>> Regards,
>>> Jonas
>>>
>>>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>>>   					  DM_DRIVER_GET(rockchip_otp), &dev);
>>>>   #endif
>>>>
>>>>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>> ---
>>>>>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20
>>>>> ++------------------
>>>>>  1 file changed, 2 insertions(+), 18 deletions(-)
>>>>>
>>>>> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>> index d79084614f1..d0a694ead1d 100644
>>>>> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>> @@ -11,7 +11,6 @@
>>>>>  #include <asm/arch-rockchip/clock.h>
>>>>>  #include <asm/arch-rockchip/grf_rk3399.h>
>>>>>  #include <asm/arch-rockchip/hardware.h>
>>>>> -#include <asm/arch-rockchip/misc.h>
>>>>>
>>>>>  #define GRF_IO_VSEL_BT565_SHIFT 0
>>>>>  #define PMUGRF_CON0_VSEL_SHIFT 8
>>>>> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>>>>>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>>>>  }
>>>>>
>>>>> -int misc_init_r(void)
>>>>> +int rockchip_early_misc_init_r(void)
>>>>>  {
>>>>> -	const u32 cpuid_offset = 0x7;
>>>>> -	const u32 cpuid_length = 0x10;
>>>>> -	u8 cpuid[cpuid_length];
>>>>> -	int ret;
>>>>> -
>>>>>  	setup_iodomain();
>>>>>
>>>>> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, 
>>>>> cpuid);
>>>>> -	if (ret)
>>>>> -		return ret;
>>>>> -
>>>>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>>>>> -	if (ret)
>>>>> -		return ret;
>>>>> -
>>>>> -	ret = rockchip_setup_macaddr();
>>>>> -
>>>>> -	return ret;
>>>>> +	return 0;
>>>>>  }
>>>>>
>>>>>  #endif
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d90cb1edcf7c1854e4cecb52871421f29d3d849

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Jonas,

On 2024-02-04 10:46, Jonas Karlman wrote:
> On 2024-02-04 05:21, Dragan Simic wrote:
>> On 2024-02-03 16:18, Dragan Simic wrote:
>>> On 2024-02-03 15:18, Jonas Karlman wrote:
>>>> On 2024-02-03 14:19, Dragan Simic wrote:
>>>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>>>> to prevent the execution of its body for devices such as the
>>>>> ones listed above, which eliminates the unneeded code from the
>>>>> resulting U-Boot images, making them a bit smaller, and saves
>>>>> some CPU cycles and a bit of time on boot.  It also prevents
>>>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>>>> added to the environment.
>>>> 
>>>> Adding the ethernet addresses only adds a few ms to boot, if you 
>>>> care
>>>> about boot speed, please look into if we can disable 
>>>> CONFIG_USE_PREBOOT
>>>> for these boards, running "usb start" as preboot adds several 
>>>> seconds
>>>> to the boot.
>>> 
>>> I see, but I personally don't care that much about how long the
>>> U-Boot takes to execute;  a couple of seconds more don't bother me
>>> much.  I care more about excluding the unneded code.
>>> 
>>>>> The patch below should do the trick, which also performs a few
>>>>> small code cleanups for additional file-level consistency:
>>>>> 
>>>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>>>> b/arch/arm/mach-rockchip/misc.c
>>>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>>>> --- a/arch/arm/mach-rockchip/misc.c
>>>>> +++ b/arch/arm/mach-rockchip/misc.c
>>>>> @@ -23,7 +23,8 @@
>>>>> 
>>>>>   int rockchip_setup_macaddr(void)
>>>>>   {
>>>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>>>> 
>>>> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot 
>>>> but
>>>> want a mac-address being set in DT fixup. And for newer RK35xx SoCs
>>>> the
>>>> GMAC_ROCKCHIP driver is not used.
>>> 
>>> Thanks for pointing that out.  Not good.
>>> 
>>>> A new Kconfig option should be introduced if there is a need for 
>>>> some
>>>> boards to disable this.
>>> 
>>> Is there any simpler way to achieve that?  If there isn't, perhaps
>>> we could leave rockchip_setup_macaddr() generate the MAC address
>>> and rely on fdt_fixup_ethernet() ending up doing nothing when no
>>> ethernetX aliases exist.
> 
> As Chen-Yu Tsai pointed out in one of my prior patches [2]:
> 
>  The user might be loading a custom FDT for the kernel, or have DT
>  overlays stacked on, either could have the "ethernet1" alias while
>  the U-boot DT doesn't.
> 
> So the common rockchip_setup_macaddr() cannot rely on checking for
> ethernetX alias, because the fixup may not run against the bundled DT.
> 
> [2] 
> https://lore.kernel.org/u-boot/CAGb2v66hR5e3nBPZ0C3=h29fS4Um7whfBu7XTAi1sRbzXRAPxg@mail.gmail.com/

I see, we unfortunately cannot know the final outcome in advance, to
be able to avoid polluting the environment by adding the "eth1addr"
variable if it actually isn't needed, for example.

Though, why can't the user supply an FDT that contains ethernetX
aliases 0 through 2, for example, in which case we wouldn't provide
a stable MAC address for ethernet2?  Am I missing something, i.e. is
there something preventing an ethernet2 alias from being present?

>> After going through the source code once again, I think that adding
>> new configuration option would be warranted, because it would exclude
>> two sizable chunks of code from the resulting U-Boot images, and
>> because it would avoid polluting the environment with a couple of
>> unneeded variables.
> 
> Yes a new Kconfig option would be preferred.
> 
>> I'll go ahead and implement this, and I hope that the patch will be
>> received well.
> 
> Great :-)

Thanks. :)  Got it implemented already and tested a bit.  I need to
write the patch and series summaries, and I'll send them over.

Regarding the above-described uncertainty about what ethernetX aliases
the final FDT containts, I'd say that ignoring the ethernetX aliases
completely for the Pinebook Pro and the Pinephone Pro is safe and valid,
because those are actual devices, instead of being development boards
for which the final hardware configuration is determined by the user.
I can hardly see anyone adding an Ethernet interface to them, except
by plugging in a USB Ethernet dongle.

I hope you agree.

>>>>>   	int ret;
>>>>>   	const char *cpuid = env_get("cpuid#");
>>>>>   	u8 hash[SHA256_SUM_LEN];
>>>>> @@ -64,15 +65,15 @@ int rockchip_cpuid_from_efuse(const u32
>>>>> cpuid_offset,
>>>>>   			      const u32 cpuid_length,
>>>>>   			      u8 *cpuid)
>>>>>   {
>>>>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) ||
>>>>> IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>>>>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE) ||
>>>> 
>>>> This changes behavior and is wrong. IS_ENABLED check for specific
>>>> config
>>>> flag, CONFIG_IS_ENABLED would check for e.g. 
>>>> CONFIG_SPL_ROCKCHIP_EFUSE
>>>> or similar.
>>> 
>>> Sorry, my bad, somehow I managed to forget that.  Thanks for
>>> pointing that out.
>>> 
>>>>> CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>>>>>   	struct udevice *dev;
>>>>>   	int ret;
>>>>> 
>>>>>   	/* retrieve the device */
>>>>> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
>>>>> +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
>>>> 
>>>> Same as above.
>>>> 
>>>>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>>>>   					  DM_DRIVER_GET(rockchip_efuse), &dev);
>>>>> -#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
>>>>> +#elif CONFIG_IS_ENABLED(ROCKCHIP_OTP)
>>>> 
>>>> Same as above.
>>>> 
>>>> Regards,
>>>> Jonas
>>>> 
>>>>>   	ret = uclass_get_device_by_driver(UCLASS_MISC,
>>>>>   					  DM_DRIVER_GET(rockchip_otp), &dev);
>>>>>   #endif
>>>>> 
>>>>>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>>>>>> Signed-off-by: Quentin Schulz 
>>>>>> <quentin.schulz@theobroma-systems.com>
>>>>>> ---
>>>>>>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20
>>>>>> ++------------------
>>>>>>  1 file changed, 2 insertions(+), 18 deletions(-)
>>>>>> 
>>>>>> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>>> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>>> index d79084614f1..d0a694ead1d 100644
>>>>>> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>>> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>>>>>> @@ -11,7 +11,6 @@
>>>>>>  #include <asm/arch-rockchip/clock.h>
>>>>>>  #include <asm/arch-rockchip/grf_rk3399.h>
>>>>>>  #include <asm/arch-rockchip/hardware.h>
>>>>>> -#include <asm/arch-rockchip/misc.h>
>>>>>> 
>>>>>>  #define GRF_IO_VSEL_BT565_SHIFT 0
>>>>>>  #define PMUGRF_CON0_VSEL_SHIFT 8
>>>>>> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
>>>>>>  	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>>>>>>  }
>>>>>> 
>>>>>> -int misc_init_r(void)
>>>>>> +int rockchip_early_misc_init_r(void)
>>>>>>  {
>>>>>> -	const u32 cpuid_offset = 0x7;
>>>>>> -	const u32 cpuid_length = 0x10;
>>>>>> -	u8 cpuid[cpuid_length];
>>>>>> -	int ret;
>>>>>> -
>>>>>>  	setup_iodomain();
>>>>>> 
>>>>>> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length,
>>>>>> cpuid);
>>>>>> -	if (ret)
>>>>>> -		return ret;
>>>>>> -
>>>>>> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
>>>>>> -	if (ret)
>>>>>> -		return ret;
>>>>>> -
>>>>>> -	ret = rockchip_setup_macaddr();
>>>>>> -
>>>>>> -	return ret;
>>>>>> +	return 0;
>>>>>>  }
>>>>>> 
>>>>>>  #endif
>>> 
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d90cb1edcf7c1854e4cecb52871421f29d3d849

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

Hi Dragan, Jonas,

On 2/4/24 11:39, Dragan Simic wrote:
> [Some people who received this message don't often get email from 
> dsimic@manjaro.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello Jonas,
> 
> On 2024-02-04 10:46, Jonas Karlman wrote:
>> On 2024-02-04 05:21, Dragan Simic wrote:
>>> On 2024-02-03 16:18, Dragan Simic wrote:
>>>> On 2024-02-03 15:18, Jonas Karlman wrote:
>>>>> On 2024-02-03 14:19, Dragan Simic wrote:
>>>>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>>>>> to prevent the execution of its body for devices such as the
>>>>>> ones listed above, which eliminates the unneeded code from the
>>>>>> resulting U-Boot images, making them a bit smaller, and saves
>>>>>> some CPU cycles and a bit of time on boot.  It also prevents
>>>>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>>>>> added to the environment.
>>>>>
>>>>> Adding the ethernet addresses only adds a few ms to boot, if you
>>>>> care
>>>>> about boot speed, please look into if we can disable
>>>>> CONFIG_USE_PREBOOT
>>>>> for these boards, running "usb start" as preboot adds several
>>>>> seconds
>>>>> to the boot.
>>>>
>>>> I see, but I personally don't care that much about how long the
>>>> U-Boot takes to execute;  a couple of seconds more don't bother me
>>>> much.  I care more about excluding the unneded code.
>>>>
>>>>>> The patch below should do the trick, which also performs a few
>>>>>> small code cleanups for additional file-level consistency:
>>>>>>
>>>>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>>>>> b/arch/arm/mach-rockchip/misc.c
>>>>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>>>>> --- a/arch/arm/mach-rockchip/misc.c
>>>>>> +++ b/arch/arm/mach-rockchip/misc.c
>>>>>> @@ -23,7 +23,8 @@
>>>>>>
>>>>>>   int rockchip_setup_macaddr(void)
>>>>>>   {
>>>>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>>>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>>>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>>>>>
>>>>> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot
>>>>> but
>>>>> want a mac-address being set in DT fixup. And for newer RK35xx SoCs
>>>>> the
>>>>> GMAC_ROCKCHIP driver is not used.
>>>>
>>>> Thanks for pointing that out.  Not good.
>>>>
>>>>> A new Kconfig option should be introduced if there is a need for
>>>>> some
>>>>> boards to disable this.
>>>>
>>>> Is there any simpler way to achieve that?  If there isn't, perhaps
>>>> we could leave rockchip_setup_macaddr() generate the MAC address
>>>> and rely on fdt_fixup_ethernet() ending up doing nothing when no
>>>> ethernetX aliases exist.
>>
>> As Chen-Yu Tsai pointed out in one of my prior patches [2]:
>>
>>  The user might be loading a custom FDT for the kernel, or have DT
>>  overlays stacked on, either could have the "ethernet1" alias while
>>  the U-boot DT doesn't.
>>
>> So the common rockchip_setup_macaddr() cannot rely on checking for
>> ethernetX alias, because the fixup may not run against the bundled DT.
>>
>> [2]
>> https://lore.kernel.org/u-boot/CAGb2v66hR5e3nBPZ0C3=h29fS4Um7whfBu7XTAi1sRbzXRAPxg@mail.gmail.com/
> 
> I see, we unfortunately cannot know the final outcome in advance, to
> be able to avoid polluting the environment by adding the "eth1addr"
> variable if it actually isn't needed, for example.
> 
> Though, why can't the user supply an FDT that contains ethernetX
> aliases 0 through 2, for example, in which case we wouldn't provide
> a stable MAC address for ethernet2?  Am I missing something, i.e. is
> there something preventing an ethernet2 alias from being present?
> 
>>> After going through the source code once again, I think that adding
>>> new configuration option would be warranted, because it would exclude
>>> two sizable chunks of code from the resulting U-Boot images, and
>>> because it would avoid polluting the environment with a couple of
>>> unneeded variables.
>>
>> Yes a new Kconfig option would be preferred.
>>
>>> I'll go ahead and implement this, and I hope that the patch will be
>>> received well.
>>
>> Great :-)
> 
> Thanks. :)  Got it implemented already and tested a bit.  I need to
> write the patch and series summaries, and I'll send them over.
> 
> Regarding the above-described uncertainty about what ethernetX aliases
> the final FDT containts, I'd say that ignoring the ethernetX aliases
> completely for the Pinebook Pro and the Pinephone Pro is safe and valid,
> because those are actual devices, instead of being development boards
> for which the final hardware configuration is determined by the user.
> I can hardly see anyone adding an Ethernet interface to them, except
> by plugging in a USB Ethernet dongle.
> 
> I hope you agree.
> 

What should be done with the patches for Pinephone/Pinebook Pro then? 
Since I was asked to wait on your answer/patches before respinning the 
patch series, I would like to know what to do with them :) Drop the 
patches for now or keep them as is?

Cheers,
Quentin

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Dragan Simic]

Hello Quentin,

On 2024-02-06 13:26, Quentin Schulz wrote:
> On 2/4/24 11:39, Dragan Simic wrote:
>> On 2024-02-04 10:46, Jonas Karlman wrote:
>>> On 2024-02-04 05:21, Dragan Simic wrote:
>>>> On 2024-02-03 16:18, Dragan Simic wrote:
>>>>> On 2024-02-03 15:18, Jonas Karlman wrote:
>>>>>> On 2024-02-03 14:19, Dragan Simic wrote:
>>>>>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>>>>>> to prevent the execution of its body for devices such as the
>>>>>>> ones listed above, which eliminates the unneeded code from the
>>>>>>> resulting U-Boot images, making them a bit smaller, and saves
>>>>>>> some CPU cycles and a bit of time on boot.  It also prevents
>>>>>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>>>>>> added to the environment.
>>>>>> 
>>>>>> Adding the ethernet addresses only adds a few ms to boot, if you
>>>>>> care
>>>>>> about boot speed, please look into if we can disable
>>>>>> CONFIG_USE_PREBOOT
>>>>>> for these boards, running "usb start" as preboot adds several
>>>>>> seconds
>>>>>> to the boot.
>>>>> 
>>>>> I see, but I personally don't care that much about how long the
>>>>> U-Boot takes to execute;  a couple of seconds more don't bother me
>>>>> much.  I care more about excluding the unneded code.
>>>>> 
>>>>>>> The patch below should do the trick, which also performs a few
>>>>>>> small code cleanups for additional file-level consistency:
>>>>>>> 
>>>>>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>>>>>> b/arch/arm/mach-rockchip/misc.c
>>>>>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>>>>>> --- a/arch/arm/mach-rockchip/misc.c
>>>>>>> +++ b/arch/arm/mach-rockchip/misc.c
>>>>>>> @@ -23,7 +23,8 @@
>>>>>>> 
>>>>>>>   int rockchip_setup_macaddr(void)
>>>>>>>   {
>>>>>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>>>>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>>>>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>>>>>> 
>>>>>> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot
>>>>>> but
>>>>>> want a mac-address being set in DT fixup. And for newer RK35xx 
>>>>>> SoCs
>>>>>> the
>>>>>> GMAC_ROCKCHIP driver is not used.
>>>>> 
>>>>> Thanks for pointing that out.  Not good.
>>>>> 
>>>>>> A new Kconfig option should be introduced if there is a need for
>>>>>> some
>>>>>> boards to disable this.
>>>>> 
>>>>> Is there any simpler way to achieve that?  If there isn't, perhaps
>>>>> we could leave rockchip_setup_macaddr() generate the MAC address
>>>>> and rely on fdt_fixup_ethernet() ending up doing nothing when no
>>>>> ethernetX aliases exist.
>>> 
>>> As Chen-Yu Tsai pointed out in one of my prior patches [2]:
>>> 
>>>  The user might be loading a custom FDT for the kernel, or have DT
>>>  overlays stacked on, either could have the "ethernet1" alias while
>>>  the U-boot DT doesn't.
>>> 
>>> So the common rockchip_setup_macaddr() cannot rely on checking for
>>> ethernetX alias, because the fixup may not run against the bundled 
>>> DT.
>>> 
>>> [2]
>>> https://lore.kernel.org/u-boot/CAGb2v66hR5e3nBPZ0C3=h29fS4Um7whfBu7XTAi1sRbzXRAPxg@mail.gmail.com/
>> 
>> I see, we unfortunately cannot know the final outcome in advance, to
>> be able to avoid polluting the environment by adding the "eth1addr"
>> variable if it actually isn't needed, for example.
>> 
>> Though, why can't the user supply an FDT that contains ethernetX
>> aliases 0 through 2, for example, in which case we wouldn't provide
>> a stable MAC address for ethernet2?  Am I missing something, i.e. is
>> there something preventing an ethernet2 alias from being present?
>> 
>>>> After going through the source code once again, I think that adding
>>>> new configuration option would be warranted, because it would 
>>>> exclude
>>>> two sizable chunks of code from the resulting U-Boot images, and
>>>> because it would avoid polluting the environment with a couple of
>>>> unneeded variables.
>>> 
>>> Yes a new Kconfig option would be preferred.
>>> 
>>>> I'll go ahead and implement this, and I hope that the patch will be
>>>> received well.
>>> 
>>> Great :-)
>> 
>> Thanks. :)  Got it implemented already and tested a bit.  I need to
>> write the patch and series summaries, and I'll send them over.
>> 
>> Regarding the above-described uncertainty about what ethernetX aliases
>> the final FDT containts, I'd say that ignoring the ethernetX aliases
>> completely for the Pinebook Pro and the Pinephone Pro is safe and 
>> valid,
>> because those are actual devices, instead of being development boards
>> for which the final hardware configuration is determined by the user.
>> I can hardly see anyone adding an Ethernet interface to them, except
>> by plugging in a USB Ethernet dongle.
>> 
>> I hope you agree.
> 
> What should be done with the patches for Pinephone/Pinebook Pro then?
> Since I was asked to wait on your answer/patches before respinning the
> patch series, I would like to know what to do with them :) Drop the
> patches for now or keep them as is?

Your patches are fine, just please update their subjects as I already
suggested.  The patches I'll send a bit later will resolve the issues
I raised previously for your patches, together with doing a bit more,
so there's no need to change your patches further.

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

Hi Dragan,

On 2/6/24 13:33, Dragan Simic wrote:
> [Some people who received this message don't often get email from 
> dsimic@manjaro.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello Quentin,
> 
> On 2024-02-06 13:26, Quentin Schulz wrote:
>> On 2/4/24 11:39, Dragan Simic wrote:
>>> On 2024-02-04 10:46, Jonas Karlman wrote:
>>>> On 2024-02-04 05:21, Dragan Simic wrote:
>>>>> On 2024-02-03 16:18, Dragan Simic wrote:
>>>>>> On 2024-02-03 15:18, Jonas Karlman wrote:
>>>>>>> On 2024-02-03 14:19, Dragan Simic wrote:
>>>>>>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>>>>>>> to prevent the execution of its body for devices such as the
>>>>>>>> ones listed above, which eliminates the unneeded code from the
>>>>>>>> resulting U-Boot images, making them a bit smaller, and saves
>>>>>>>> some CPU cycles and a bit of time on boot.  It also prevents
>>>>>>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>>>>>>> added to the environment.
>>>>>>>
>>>>>>> Adding the ethernet addresses only adds a few ms to boot, if you
>>>>>>> care
>>>>>>> about boot speed, please look into if we can disable
>>>>>>> CONFIG_USE_PREBOOT
>>>>>>> for these boards, running "usb start" as preboot adds several
>>>>>>> seconds
>>>>>>> to the boot.
>>>>>>
>>>>>> I see, but I personally don't care that much about how long the
>>>>>> U-Boot takes to execute;  a couple of seconds more don't bother me
>>>>>> much.  I care more about excluding the unneded code.
>>>>>>
>>>>>>>> The patch below should do the trick, which also performs a few
>>>>>>>> small code cleanups for additional file-level consistency:
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>>>>>>> b/arch/arm/mach-rockchip/misc.c
>>>>>>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>>>>>>> --- a/arch/arm/mach-rockchip/misc.c
>>>>>>>> +++ b/arch/arm/mach-rockchip/misc.c
>>>>>>>> @@ -23,7 +23,8 @@
>>>>>>>>
>>>>>>>>   int rockchip_setup_macaddr(void)
>>>>>>>>   {
>>>>>>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>>>>>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>>>>>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>>>>>>>
>>>>>>> This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot
>>>>>>> but
>>>>>>> want a mac-address being set in DT fixup. And for newer RK35xx
>>>>>>> SoCs
>>>>>>> the
>>>>>>> GMAC_ROCKCHIP driver is not used.
>>>>>>
>>>>>> Thanks for pointing that out.  Not good.
>>>>>>
>>>>>>> A new Kconfig option should be introduced if there is a need for
>>>>>>> some
>>>>>>> boards to disable this.
>>>>>>
>>>>>> Is there any simpler way to achieve that?  If there isn't, perhaps
>>>>>> we could leave rockchip_setup_macaddr() generate the MAC address
>>>>>> and rely on fdt_fixup_ethernet() ending up doing nothing when no
>>>>>> ethernetX aliases exist.
>>>>
>>>> As Chen-Yu Tsai pointed out in one of my prior patches [2]:
>>>>
>>>>  The user might be loading a custom FDT for the kernel, or have DT
>>>>  overlays stacked on, either could have the "ethernet1" alias while
>>>>  the U-boot DT doesn't.
>>>>
>>>> So the common rockchip_setup_macaddr() cannot rely on checking for
>>>> ethernetX alias, because the fixup may not run against the bundled
>>>> DT.
>>>>
>>>> [2]
>>>> https://lore.kernel.org/u-boot/CAGb2v66hR5e3nBPZ0C3=h29fS4Um7whfBu7XTAi1sRbzXRAPxg@mail.gmail.com/
>>>
>>> I see, we unfortunately cannot know the final outcome in advance, to
>>> be able to avoid polluting the environment by adding the "eth1addr"
>>> variable if it actually isn't needed, for example.
>>>
>>> Though, why can't the user supply an FDT that contains ethernetX
>>> aliases 0 through 2, for example, in which case we wouldn't provide
>>> a stable MAC address for ethernet2?  Am I missing something, i.e. is
>>> there something preventing an ethernet2 alias from being present?
>>>
>>>>> After going through the source code once again, I think that adding
>>>>> new configuration option would be warranted, because it would
>>>>> exclude
>>>>> two sizable chunks of code from the resulting U-Boot images, and
>>>>> because it would avoid polluting the environment with a couple of
>>>>> unneeded variables.
>>>>
>>>> Yes a new Kconfig option would be preferred.
>>>>
>>>>> I'll go ahead and implement this, and I hope that the patch will be
>>>>> received well.
>>>>
>>>> Great :-)
>>>
>>> Thanks. :)  Got it implemented already and tested a bit.  I need to
>>> write the patch and series summaries, and I'll send them over.
>>>
>>> Regarding the above-described uncertainty about what ethernetX aliases
>>> the final FDT containts, I'd say that ignoring the ethernetX aliases
>>> completely for the Pinebook Pro and the Pinephone Pro is safe and
>>> valid,
>>> because those are actual devices, instead of being development boards
>>> for which the final hardware configuration is determined by the user.
>>> I can hardly see anyone adding an Ethernet interface to them, except
>>> by plugging in a USB Ethernet dongle.
>>>
>>> I hope you agree.
>>
>> What should be done with the patches for Pinephone/Pinebook Pro then?
>> Since I was asked to wait on your answer/patches before respinning the
>> patch series, I would like to know what to do with them :) Drop the
>> patches for now or keep them as is?
> 
> Your patches are fine, just please update their subjects as I already
> suggested.  The patches I'll send a bit later will resolve the issues
> I raised previously for your patches, together with doing a bit more,
> so there's no need to change your patches further.

I would rather not break devices if I have a choice. Is merging those 
patches without yours going to break those devices?

Cheers,
Quentin

Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

[Dragan Simic]

On 2024-02-06 13:37, Quentin Schulz wrote:
> On 2/6/24 13:33, Dragan Simic wrote:
>> On 2024-02-06 13:26, Quentin Schulz wrote:
>>> On 2/4/24 11:39, Dragan Simic wrote:
>>>> On 2024-02-04 10:46, Jonas Karlman wrote:
>>>>> On 2024-02-04 05:21, Dragan Simic wrote:
>>>>>> On 2024-02-03 16:18, Dragan Simic wrote:
>>>>>>> On 2024-02-03 15:18, Jonas Karlman wrote:
>>>>>>>> On 2024-02-03 14:19, Dragan Simic wrote:
>>>>>>>>> We should add more ifdef guards to rockchip_setup_macaddr(),
>>>>>>>>> to prevent the execution of its body for devices such as the
>>>>>>>>> ones listed above, which eliminates the unneeded code from the
>>>>>>>>> resulting U-Boot images, making them a bit smaller, and saves
>>>>>>>>> some CPU cycles and a bit of time on boot.  It also prevents
>>>>>>>>> the unneeded "ethaddr" and "eth1addr" variables from being
>>>>>>>>> added to the environment.
>>>>>>>> 
>>>>>>>> Adding the ethernet addresses only adds a few ms to boot, if you
>>>>>>>> care
>>>>>>>> about boot speed, please look into if we can disable
>>>>>>>> CONFIG_USE_PREBOOT
>>>>>>>> for these boards, running "usb start" as preboot adds several
>>>>>>>> seconds
>>>>>>>> to the boot.
>>>>>>> 
>>>>>>> I see, but I personally don't care that much about how long the
>>>>>>> U-Boot takes to execute;  a couple of seconds more don't bother 
>>>>>>> me
>>>>>>> much.  I care more about excluding the unneded code.
>>>>>>> 
>>>>>>>>> The patch below should do the trick, which also performs a few
>>>>>>>>> small code cleanups for additional file-level consistency:
>>>>>>>>> 
>>>>>>>>> diff --git a/arch/arm/mach-rockchip/misc.c
>>>>>>>>> b/arch/arm/mach-rockchip/misc.c
>>>>>>>>> index 7d03f0c2b679..ed5bdab5a648 100644
>>>>>>>>> --- a/arch/arm/mach-rockchip/misc.c
>>>>>>>>> +++ b/arch/arm/mach-rockchip/misc.c
>>>>>>>>> @@ -23,7 +23,8 @@
>>>>>>>>> 
>>>>>>>>>   int rockchip_setup_macaddr(void)
>>>>>>>>>   {
>>>>>>>>> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
>>>>>>>>> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
>>>>>>>>> +    CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
>>>>>>>> 
>>>>>>>> This would exclude any board not enabling GMAC_ROCKCHIP in 
>>>>>>>> U-Boot
>>>>>>>> but
>>>>>>>> want a mac-address being set in DT fixup. And for newer RK35xx
>>>>>>>> SoCs
>>>>>>>> the
>>>>>>>> GMAC_ROCKCHIP driver is not used.
>>>>>>> 
>>>>>>> Thanks for pointing that out.  Not good.
>>>>>>> 
>>>>>>>> A new Kconfig option should be introduced if there is a need for
>>>>>>>> some
>>>>>>>> boards to disable this.
>>>>>>> 
>>>>>>> Is there any simpler way to achieve that?  If there isn't, 
>>>>>>> perhaps
>>>>>>> we could leave rockchip_setup_macaddr() generate the MAC address
>>>>>>> and rely on fdt_fixup_ethernet() ending up doing nothing when no
>>>>>>> ethernetX aliases exist.
>>>>> 
>>>>> As Chen-Yu Tsai pointed out in one of my prior patches [2]:
>>>>> 
>>>>>  The user might be loading a custom FDT for the kernel, or have DT
>>>>>  overlays stacked on, either could have the "ethernet1" alias while
>>>>>  the U-boot DT doesn't.
>>>>> 
>>>>> So the common rockchip_setup_macaddr() cannot rely on checking for
>>>>> ethernetX alias, because the fixup may not run against the bundled
>>>>> DT.
>>>>> 
>>>>> [2]
>>>>> https://lore.kernel.org/u-boot/CAGb2v66hR5e3nBPZ0C3=h29fS4Um7whfBu7XTAi1sRbzXRAPxg@mail.gmail.com/
>>>> 
>>>> I see, we unfortunately cannot know the final outcome in advance, to
>>>> be able to avoid polluting the environment by adding the "eth1addr"
>>>> variable if it actually isn't needed, for example.
>>>> 
>>>> Though, why can't the user supply an FDT that contains ethernetX
>>>> aliases 0 through 2, for example, in which case we wouldn't provide
>>>> a stable MAC address for ethernet2?  Am I missing something, i.e. is
>>>> there something preventing an ethernet2 alias from being present?
>>>> 
>>>>>> After going through the source code once again, I think that 
>>>>>> adding
>>>>>> new configuration option would be warranted, because it would
>>>>>> exclude
>>>>>> two sizable chunks of code from the resulting U-Boot images, and
>>>>>> because it would avoid polluting the environment with a couple of
>>>>>> unneeded variables.
>>>>> 
>>>>> Yes a new Kconfig option would be preferred.
>>>>> 
>>>>>> I'll go ahead and implement this, and I hope that the patch will 
>>>>>> be
>>>>>> received well.
>>>>> 
>>>>> Great :-)
>>>> 
>>>> Thanks. :)  Got it implemented already and tested a bit.  I need to
>>>> write the patch and series summaries, and I'll send them over.
>>>> 
>>>> Regarding the above-described uncertainty about what ethernetX 
>>>> aliases
>>>> the final FDT containts, I'd say that ignoring the ethernetX aliases
>>>> completely for the Pinebook Pro and the Pinephone Pro is safe and
>>>> valid,
>>>> because those are actual devices, instead of being development 
>>>> boards
>>>> for which the final hardware configuration is determined by the 
>>>> user.
>>>> I can hardly see anyone adding an Ethernet interface to them, except
>>>> by plugging in a USB Ethernet dongle.
>>>> 
>>>> I hope you agree.
>>> 
>>> What should be done with the patches for Pinephone/Pinebook Pro then?
>>> Since I was asked to wait on your answer/patches before respinning 
>>> the
>>> patch series, I would like to know what to do with them :) Drop the
>>> patches for now or keep them as is?
>> 
>> Your patches are fine, just please update their subjects as I already
>> suggested.  The patches I'll send a bit later will resolve the issues
>> I raised previously for your patches, together with doing a bit more,
>> so there's no need to change your patches further.
> 
> I would rather not break devices if I have a choice. Is merging those
> patches without yours going to break those devices?

Don't worry, I don't see how they could end up broken that way.  There
should only be some redundant code built into the resulting U-Boot 
images,
and some redundant variables added to the environment at runtime.

[PATCH 09/18] rockchip: theobroma-systems: puma: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Only setup_iodomain() and setup_boottargets differ from the original
misc_init_r from Rockchip mach code, so let's use
rockchip_early_misc_init_r instead of reimplementing the whole
misc_init_r from Rockchip.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index a82f97b2d54..98a818b135d 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -10,7 +10,6 @@
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
-#include <asm/arch-rockchip/misc.h>
 #include "../common/common.h"
 
 static void setup_iodomain(void)
@@ -27,25 +26,8 @@ static void setup_iodomain(void)
 	rk_setreg(&grf->io_vsel, 1 << GRF_IO_VSEL_GPIO4CD_SHIFT);
 }
 
-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-	const u32 cpuid_offset = 0x7;
-	const u32 cpuid_length = 0x10;
-	u8 cpuid[cpuid_length];
-	int ret;
-
-	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
-	if (ret)
-		return ret;
-
-	ret = rockchip_cpuid_set(cpuid, cpuid_length);
-	if (ret)
-		return ret;
-
-	ret = rockchip_setup_macaddr();
-	if (ret)
-		return ret;
-
 	setup_iodomain();
 	setup_boottargets();
 

-- 
2.43.0

Re: [PATCH 09/18] rockchip: theobroma-systems: puma: migrate to rockchip_early_misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Only setup_iodomain() and setup_boottargets differ from the original
> misc_init_r from Rockchip mach code, so let's use
> rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   board/theobroma-systems/puma_rk3399/puma-rk3399.c | 20 +-------------------
>   1 file changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index a82f97b2d54..98a818b135d 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -10,7 +10,6 @@
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
> -#include <asm/arch-rockchip/misc.h>
>   #include "../common/common.h"
>   
>   static void setup_iodomain(void)
> @@ -27,25 +26,8 @@ static void setup_iodomain(void)
>   	rk_setreg(&grf->io_vsel, 1 << GRF_IO_VSEL_GPIO4CD_SHIFT);
>   }
>   
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>   {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_setup_macaddr();
> -	if (ret)
> -		return ret;
> -
>   	setup_iodomain();
>   	setup_boottargets();
>   
>

[PATCH 10/18] rockchip: theobroma-systems: ringneck: migrate to rockchip_early_misc_init_r

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Only setup_boottargets differs from the original misc_init_r from
Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
reimplementing the whole misc_init_r from Rockchip.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 .../theobroma-systems/ringneck_px30/ringneck-px30.c  | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
index ff7e414303d..bfebfe5136d 100644
--- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c
+++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
@@ -4,29 +4,11 @@
  */
 
 #include <asm/gpio.h>
-#include <asm/arch-rockchip/misc.h>
 #include <linux/delay.h>
 #include "../common/common.h"
 
-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-	const u32 cpuid_offset = 0x7;
-	const u32 cpuid_length = 0x10;
-	u8 cpuid[cpuid_length];
-	int ret;
-
-	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
-	if (ret)
-		return ret;
-
-	ret = rockchip_cpuid_set(cpuid, cpuid_length);
-	if (ret)
-		return ret;
-
-	ret = rockchip_setup_macaddr();
-	if (ret)
-		return ret;
-
 	setup_boottargets();
 
 	return 0;

-- 
2.43.0

Re: [PATCH 10/18] rockchip: theobroma-systems: ringneck: migrate to rockchip_early_misc_init_r

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Only setup_boottargets differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   .../theobroma-systems/ringneck_px30/ringneck-px30.c  | 20 +-------------------
>   1 file changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
> index ff7e414303d..bfebfe5136d 100644
> --- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c
> +++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
> @@ -4,29 +4,11 @@
>    */
>   
>   #include <asm/gpio.h>
> -#include <asm/arch-rockchip/misc.h>
>   #include <linux/delay.h>
>   #include "../common/common.h"
>   
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>   {
> -	const u32 cpuid_offset = 0x7;
> -	const u32 cpuid_length = 0x10;
> -	u8 cpuid[cpuid_length];
> -	int ret;
> -
> -	ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -	if (ret)
> -		return ret;
> -
> -	ret = rockchip_setup_macaddr();
> -	if (ret)
> -		return ret;
> -
>   	setup_boottargets();
>   
>   	return 0;
>

[PATCH 11/18] rockchip: merge misc.c into board.c

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

The functions aren't used anywhere else than in board.c, therefore,
let's not expose them anymore at all.

This merges misc.c and board.c together and removes the functions from
the misc.h header file.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/include/asm/arch-rockchip/misc.h |   5 --
 arch/arm/mach-rockchip/Makefile           |   1 -
 arch/arm/mach-rockchip/board.c            | 125 +++++++++++++++++++++++++++
 arch/arm/mach-rockchip/misc.c             | 135 ------------------------------
 4 files changed, 125 insertions(+), 141 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/misc.h b/arch/arm/include/asm/arch-rockchip/misc.h
index 4155af8c3b0..ef37ff1661a 100644
--- a/arch/arm/include/asm/arch-rockchip/misc.h
+++ b/arch/arm/include/asm/arch-rockchip/misc.h
@@ -6,9 +6,4 @@
  *      Rohan Garg <rohan.garg@collabora.com>
  */
 
-int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
-			      const u32 cpuid_length,
-			      u8 *cpuid);
-int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length);
-int rockchip_setup_macaddr(void);
 void rockchip_capsule_update_board_setup(void);
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 1dc92066bbf..c07bdaee4c3 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -23,7 +23,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 # meaning "turn it off".
 obj-y += boot_mode.o
 obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
-obj-$(CONFIG_MISC_INIT_R) += misc.o
 endif
 
 ifeq ($(CONFIG_TPL_BUILD),)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index d5cb59c10fa..80b4514852f 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -1,20 +1,32 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * (C) Copyright 2019 Rockchip Electronics Co., Ltd.
+ *
+ * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
+ *      Rohan Garg <rohan.garg@collabora.com>
+ *
+ * Based on puma-rk3399.c:
+ *      (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  */
 #include <common.h>
 #include <clk.h>
 #include <cpu_func.h>
+#include <env.h>
 #include <dm.h>
 #include <efi_loader.h>
 #include <fastboot.h>
+#include <hash.h>
 #include <init.h>
 #include <log.h>
 #include <mmc.h>
+#include <dm/uclass-internal.h>
+#include <misc.h>
 #include <part.h>
 #include <ram.h>
 #include <syscon.h>
 #include <uuid.h>
+#include <u-boot/crc.h>
+#include <u-boot/sha256.h>
 #include <asm/cache.h>
 #include <asm/io.h>
 #include <asm/arch-rockchip/boot_mode.h>
@@ -297,6 +309,119 @@ int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
 #endif
 
 #ifdef CONFIG_MISC_INIT_R
+int rockchip_setup_macaddr(void)
+{
+#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
+	int ret;
+	const char *cpuid = env_get("cpuid#");
+	u8 hash[SHA256_SUM_LEN];
+	int size = sizeof(hash);
+	u8 mac_addr[6];
+
+	/* Only generate a MAC address, if none is set in the environment */
+	if (env_get("ethaddr"))
+		return 0;
+
+	if (!cpuid) {
+		debug("%s: could not retrieve 'cpuid#'\n", __func__);
+		return -1;
+	}
+
+	ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, &size);
+	if (ret) {
+		debug("%s: failed to calculate SHA256\n", __func__);
+		return -1;
+	}
+
+	/* Copy 6 bytes of the hash to base the MAC address on */
+	memcpy(mac_addr, hash, 6);
+
+	/* Make this a valid MAC address and set it */
+	mac_addr[0] &= 0xfe;  /* clear multicast bit */
+	mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
+	eth_env_set_enetaddr("ethaddr", mac_addr);
+
+	/* Make a valid MAC address for ethernet1 */
+	mac_addr[5] ^= 0x01;
+	eth_env_set_enetaddr("eth1addr", mac_addr);
+#endif
+	return 0;
+}
+
+int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
+			      const u32 cpuid_length,
+			      u8 *cpuid)
+{
+#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) || IS_ENABLED(CONFIG_ROCKCHIP_OTP)
+	struct udevice *dev;
+	int ret;
+
+	/* retrieve the device */
+#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
+	ret = uclass_get_device_by_driver(UCLASS_MISC,
+					  DM_DRIVER_GET(rockchip_efuse), &dev);
+#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
+	ret = uclass_get_device_by_driver(UCLASS_MISC,
+					  DM_DRIVER_GET(rockchip_otp), &dev);
+#endif
+	if (ret) {
+		debug("%s: could not find efuse device\n", __func__);
+		return -1;
+	}
+
+	/* read the cpu_id range from the efuses */
+	ret = misc_read(dev, cpuid_offset, cpuid, cpuid_length);
+	if (ret < 0) {
+		debug("%s: reading cpuid from the efuses failed\n",
+		      __func__);
+		return -1;
+	}
+#endif
+	return 0;
+}
+
+int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
+{
+	u8 low[cpuid_length / 2], high[cpuid_length / 2];
+	char cpuid_str[cpuid_length * 2 + 1];
+	u64 serialno;
+	char serialno_str[17];
+	const char *oldid;
+	int i;
+
+	memset(cpuid_str, 0, sizeof(cpuid_str));
+	for (i = 0; i < cpuid_length; i++)
+		sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
+
+	debug("cpuid: %s\n", cpuid_str);
+
+	/*
+	 * Mix the cpuid bytes using the same rules as in
+	 *   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
+	 */
+	for (i = 0; i < cpuid_length / 2; i++) {
+		low[i] = cpuid[1 + (i << 1)];
+		high[i] = cpuid[i << 1];
+	}
+
+	serialno = crc32_no_comp(0, low, cpuid_length / 2);
+	serialno |= (u64)crc32_no_comp(serialno, high, cpuid_length / 2) << 32;
+	snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
+
+	oldid = env_get("cpuid#");
+	if (oldid && strcmp(oldid, cpuid_str) != 0)
+		printf("cpuid: value %s present in env does not match hardware %s\n",
+		       oldid, cpuid_str);
+
+	env_set("cpuid#", cpuid_str);
+
+	/* Only generate serial# when none is set yet */
+	if (!env_get("serial#"))
+		env_set("serial#", serialno_str);
+
+	return 0;
+}
+
 __weak int rockchip_early_misc_init_r(void)
 {
 	return 0;
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
deleted file mode 100644
index 15397cff009..00000000000
--- a/arch/arm/mach-rockchip/misc.c
+++ /dev/null
@@ -1,135 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * RK3399: Architecture common definitions
- *
- * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
- *      Rohan Garg <rohan.garg@collabora.com>
- *
- * Based on puma-rk3399.c:
- *      (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
- */
-
-#include <common.h>
-#include <env.h>
-#include <dm.h>
-#include <hash.h>
-#include <log.h>
-#include <dm/uclass-internal.h>
-#include <misc.h>
-#include <u-boot/crc.h>
-#include <u-boot/sha256.h>
-
-#include <asm/arch-rockchip/misc.h>
-
-int rockchip_setup_macaddr(void)
-{
-#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
-	int ret;
-	const char *cpuid = env_get("cpuid#");
-	u8 hash[SHA256_SUM_LEN];
-	int size = sizeof(hash);
-	u8 mac_addr[6];
-
-	/* Only generate a MAC address, if none is set in the environment */
-	if (env_get("ethaddr"))
-		return 0;
-
-	if (!cpuid) {
-		debug("%s: could not retrieve 'cpuid#'\n", __func__);
-		return -1;
-	}
-
-	ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, &size);
-	if (ret) {
-		debug("%s: failed to calculate SHA256\n", __func__);
-		return -1;
-	}
-
-	/* Copy 6 bytes of the hash to base the MAC address on */
-	memcpy(mac_addr, hash, 6);
-
-	/* Make this a valid MAC address and set it */
-	mac_addr[0] &= 0xfe;  /* clear multicast bit */
-	mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
-	eth_env_set_enetaddr("ethaddr", mac_addr);
-
-	/* Make a valid MAC address for ethernet1 */
-	mac_addr[5] ^= 0x01;
-	eth_env_set_enetaddr("eth1addr", mac_addr);
-#endif
-	return 0;
-}
-
-int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
-			      const u32 cpuid_length,
-			      u8 *cpuid)
-{
-#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) || IS_ENABLED(CONFIG_ROCKCHIP_OTP)
-	struct udevice *dev;
-	int ret;
-
-	/* retrieve the device */
-#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
-	ret = uclass_get_device_by_driver(UCLASS_MISC,
-					  DM_DRIVER_GET(rockchip_efuse), &dev);
-#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
-	ret = uclass_get_device_by_driver(UCLASS_MISC,
-					  DM_DRIVER_GET(rockchip_otp), &dev);
-#endif
-	if (ret) {
-		debug("%s: could not find efuse device\n", __func__);
-		return -1;
-	}
-
-	/* read the cpu_id range from the efuses */
-	ret = misc_read(dev, cpuid_offset, cpuid, cpuid_length);
-	if (ret < 0) {
-		debug("%s: reading cpuid from the efuses failed\n",
-		      __func__);
-		return -1;
-	}
-#endif
-	return 0;
-}
-
-int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
-{
-	u8 low[cpuid_length / 2], high[cpuid_length / 2];
-	char cpuid_str[cpuid_length * 2 + 1];
-	u64 serialno;
-	char serialno_str[17];
-	const char *oldid;
-	int i;
-
-	memset(cpuid_str, 0, sizeof(cpuid_str));
-	for (i = 0; i < cpuid_length; i++)
-		sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
-
-	debug("cpuid: %s\n", cpuid_str);
-
-	/*
-	 * Mix the cpuid bytes using the same rules as in
-	 *   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
-	 */
-	for (i = 0; i < cpuid_length / 2; i++) {
-		low[i] = cpuid[1 + (i << 1)];
-		high[i] = cpuid[i << 1];
-	}
-
-	serialno = crc32_no_comp(0, low, cpuid_length / 2);
-	serialno |= (u64)crc32_no_comp(serialno, high, cpuid_length / 2) << 32;
-	snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
-
-	oldid = env_get("cpuid#");
-	if (oldid && strcmp(oldid, cpuid_str) != 0)
-		printf("cpuid: value %s present in env does not match hardware %s\n",
-		       oldid, cpuid_str);
-
-	env_set("cpuid#", cpuid_str);
-
-	/* Only generate serial# when none is set yet */
-	if (!env_get("serial#"))
-		env_set("serial#", serialno_str);
-
-	return 0;
-}

-- 
2.43.0

Re: [PATCH 11/18] rockchip: merge misc.c into board.c

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> The functions aren't used anywhere else than in board.c, therefore,
> let's not expose them anymore at all.
>
> This merges misc.c and board.c together and removes the functions from
> the misc.h header file.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/include/asm/arch-rockchip/misc.h |   5 --
>   arch/arm/mach-rockchip/Makefile           |   1 -
>   arch/arm/mach-rockchip/board.c            | 125 +++++++++++++++++++++++++++
>   arch/arm/mach-rockchip/misc.c             | 135 ------------------------------
>   4 files changed, 125 insertions(+), 141 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/misc.h b/arch/arm/include/asm/arch-rockchip/misc.h
> index 4155af8c3b0..ef37ff1661a 100644
> --- a/arch/arm/include/asm/arch-rockchip/misc.h
> +++ b/arch/arm/include/asm/arch-rockchip/misc.h
> @@ -6,9 +6,4 @@
>    *      Rohan Garg <rohan.garg@collabora.com>
>    */
>   
> -int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
> -			      const u32 cpuid_length,
> -			      u8 *cpuid);
> -int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length);
> -int rockchip_setup_macaddr(void);
>   void rockchip_capsule_update_board_setup(void);
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 1dc92066bbf..c07bdaee4c3 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -23,7 +23,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
>   # meaning "turn it off".
>   obj-y += boot_mode.o
>   obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> -obj-$(CONFIG_MISC_INIT_R) += misc.o
>   endif
>   
>   ifeq ($(CONFIG_TPL_BUILD),)
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index d5cb59c10fa..80b4514852f 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -1,20 +1,32 @@
>   // SPDX-License-Identifier: GPL-2.0+
>   /*
>    * (C) Copyright 2019 Rockchip Electronics Co., Ltd.
> + *
> + * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> + *      Rohan Garg <rohan.garg@collabora.com>
> + *
> + * Based on puma-rk3399.c:
> + *      (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
>    */
>   #include <common.h>
>   #include <clk.h>
>   #include <cpu_func.h>
> +#include <env.h>
>   #include <dm.h>
>   #include <efi_loader.h>
>   #include <fastboot.h>
> +#include <hash.h>
>   #include <init.h>
>   #include <log.h>
>   #include <mmc.h>
> +#include <dm/uclass-internal.h>
> +#include <misc.h>
>   #include <part.h>
>   #include <ram.h>
>   #include <syscon.h>
>   #include <uuid.h>
> +#include <u-boot/crc.h>
> +#include <u-boot/sha256.h>
>   #include <asm/cache.h>
>   #include <asm/io.h>
>   #include <asm/arch-rockchip/boot_mode.h>
> @@ -297,6 +309,119 @@ int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
>   #endif
>   
>   #ifdef CONFIG_MISC_INIT_R
> +int rockchip_setup_macaddr(void)
> +{
> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
> +	int ret;
> +	const char *cpuid = env_get("cpuid#");
> +	u8 hash[SHA256_SUM_LEN];
> +	int size = sizeof(hash);
> +	u8 mac_addr[6];
> +
> +	/* Only generate a MAC address, if none is set in the environment */
> +	if (env_get("ethaddr"))
> +		return 0;
> +
> +	if (!cpuid) {
> +		debug("%s: could not retrieve 'cpuid#'\n", __func__);
> +		return -1;
> +	}
> +
> +	ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, &size);
> +	if (ret) {
> +		debug("%s: failed to calculate SHA256\n", __func__);
> +		return -1;
> +	}
> +
> +	/* Copy 6 bytes of the hash to base the MAC address on */
> +	memcpy(mac_addr, hash, 6);
> +
> +	/* Make this a valid MAC address and set it */
> +	mac_addr[0] &= 0xfe;  /* clear multicast bit */
> +	mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
> +	eth_env_set_enetaddr("ethaddr", mac_addr);
> +
> +	/* Make a valid MAC address for ethernet1 */
> +	mac_addr[5] ^= 0x01;
> +	eth_env_set_enetaddr("eth1addr", mac_addr);
> +#endif
> +	return 0;
> +}
> +
> +int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
> +			      const u32 cpuid_length,
> +			      u8 *cpuid)
> +{
> +#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) || IS_ENABLED(CONFIG_ROCKCHIP_OTP)
> +	struct udevice *dev;
> +	int ret;
> +
> +	/* retrieve the device */
> +#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
> +	ret = uclass_get_device_by_driver(UCLASS_MISC,
> +					  DM_DRIVER_GET(rockchip_efuse), &dev);
> +#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
> +	ret = uclass_get_device_by_driver(UCLASS_MISC,
> +					  DM_DRIVER_GET(rockchip_otp), &dev);
> +#endif
> +	if (ret) {
> +		debug("%s: could not find efuse device\n", __func__);
> +		return -1;
> +	}
> +
> +	/* read the cpu_id range from the efuses */
> +	ret = misc_read(dev, cpuid_offset, cpuid, cpuid_length);
> +	if (ret < 0) {
> +		debug("%s: reading cpuid from the efuses failed\n",
> +		      __func__);
> +		return -1;
> +	}
> +#endif
> +	return 0;
> +}
> +
> +int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
> +{
> +	u8 low[cpuid_length / 2], high[cpuid_length / 2];
> +	char cpuid_str[cpuid_length * 2 + 1];
> +	u64 serialno;
> +	char serialno_str[17];
> +	const char *oldid;
> +	int i;
> +
> +	memset(cpuid_str, 0, sizeof(cpuid_str));
> +	for (i = 0; i < cpuid_length; i++)
> +		sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
> +
> +	debug("cpuid: %s\n", cpuid_str);
> +
> +	/*
> +	 * Mix the cpuid bytes using the same rules as in
> +	 *   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
> +	 */
> +	for (i = 0; i < cpuid_length / 2; i++) {
> +		low[i] = cpuid[1 + (i << 1)];
> +		high[i] = cpuid[i << 1];
> +	}
> +
> +	serialno = crc32_no_comp(0, low, cpuid_length / 2);
> +	serialno |= (u64)crc32_no_comp(serialno, high, cpuid_length / 2) << 32;
> +	snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
> +
> +	oldid = env_get("cpuid#");
> +	if (oldid && strcmp(oldid, cpuid_str) != 0)
> +		printf("cpuid: value %s present in env does not match hardware %s\n",
> +		       oldid, cpuid_str);
> +
> +	env_set("cpuid#", cpuid_str);
> +
> +	/* Only generate serial# when none is set yet */
> +	if (!env_get("serial#"))
> +		env_set("serial#", serialno_str);
> +
> +	return 0;
> +}
> +
>   __weak int rockchip_early_misc_init_r(void)
>   {
>   	return 0;
> diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
> deleted file mode 100644
> index 15397cff009..00000000000
> --- a/arch/arm/mach-rockchip/misc.c
> +++ /dev/null
> @@ -1,135 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * RK3399: Architecture common definitions
> - *
> - * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> - *      Rohan Garg <rohan.garg@collabora.com>
> - *
> - * Based on puma-rk3399.c:
> - *      (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
> - */
> -
> -#include <common.h>
> -#include <env.h>
> -#include <dm.h>
> -#include <hash.h>
> -#include <log.h>
> -#include <dm/uclass-internal.h>
> -#include <misc.h>
> -#include <u-boot/crc.h>
> -#include <u-boot/sha256.h>
> -
> -#include <asm/arch-rockchip/misc.h>
> -
> -int rockchip_setup_macaddr(void)
> -{
> -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
> -	int ret;
> -	const char *cpuid = env_get("cpuid#");
> -	u8 hash[SHA256_SUM_LEN];
> -	int size = sizeof(hash);
> -	u8 mac_addr[6];
> -
> -	/* Only generate a MAC address, if none is set in the environment */
> -	if (env_get("ethaddr"))
> -		return 0;
> -
> -	if (!cpuid) {
> -		debug("%s: could not retrieve 'cpuid#'\n", __func__);
> -		return -1;
> -	}
> -
> -	ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, &size);
> -	if (ret) {
> -		debug("%s: failed to calculate SHA256\n", __func__);
> -		return -1;
> -	}
> -
> -	/* Copy 6 bytes of the hash to base the MAC address on */
> -	memcpy(mac_addr, hash, 6);
> -
> -	/* Make this a valid MAC address and set it */
> -	mac_addr[0] &= 0xfe;  /* clear multicast bit */
> -	mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
> -	eth_env_set_enetaddr("ethaddr", mac_addr);
> -
> -	/* Make a valid MAC address for ethernet1 */
> -	mac_addr[5] ^= 0x01;
> -	eth_env_set_enetaddr("eth1addr", mac_addr);
> -#endif
> -	return 0;
> -}
> -
> -int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
> -			      const u32 cpuid_length,
> -			      u8 *cpuid)
> -{
> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE) || IS_ENABLED(CONFIG_ROCKCHIP_OTP)
> -	struct udevice *dev;
> -	int ret;
> -
> -	/* retrieve the device */
> -#if IS_ENABLED(CONFIG_ROCKCHIP_EFUSE)
> -	ret = uclass_get_device_by_driver(UCLASS_MISC,
> -					  DM_DRIVER_GET(rockchip_efuse), &dev);
> -#elif IS_ENABLED(CONFIG_ROCKCHIP_OTP)
> -	ret = uclass_get_device_by_driver(UCLASS_MISC,
> -					  DM_DRIVER_GET(rockchip_otp), &dev);
> -#endif
> -	if (ret) {
> -		debug("%s: could not find efuse device\n", __func__);
> -		return -1;
> -	}
> -
> -	/* read the cpu_id range from the efuses */
> -	ret = misc_read(dev, cpuid_offset, cpuid, cpuid_length);
> -	if (ret < 0) {
> -		debug("%s: reading cpuid from the efuses failed\n",
> -		      __func__);
> -		return -1;
> -	}
> -#endif
> -	return 0;
> -}
> -
> -int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length)
> -{
> -	u8 low[cpuid_length / 2], high[cpuid_length / 2];
> -	char cpuid_str[cpuid_length * 2 + 1];
> -	u64 serialno;
> -	char serialno_str[17];
> -	const char *oldid;
> -	int i;
> -
> -	memset(cpuid_str, 0, sizeof(cpuid_str));
> -	for (i = 0; i < cpuid_length; i++)
> -		sprintf(&cpuid_str[i * 2], "%02x", cpuid[i]);
> -
> -	debug("cpuid: %s\n", cpuid_str);
> -
> -	/*
> -	 * Mix the cpuid bytes using the same rules as in
> -	 *   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
> -	 */
> -	for (i = 0; i < cpuid_length / 2; i++) {
> -		low[i] = cpuid[1 + (i << 1)];
> -		high[i] = cpuid[i << 1];
> -	}
> -
> -	serialno = crc32_no_comp(0, low, cpuid_length / 2);
> -	serialno |= (u64)crc32_no_comp(serialno, high, cpuid_length / 2) << 32;
> -	snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
> -
> -	oldid = env_get("cpuid#");
> -	if (oldid && strcmp(oldid, cpuid_str) != 0)
> -		printf("cpuid: value %s present in env does not match hardware %s\n",
> -		       oldid, cpuid_str);
> -
> -	env_set("cpuid#", cpuid_str);
> -
> -	/* Only generate serial# when none is set yet */
> -	if (!env_get("serial#"))
> -		env_set("serial#", serialno_str);
> -
> -	return 0;
> -}
>

[PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

There's only one user of rockchip_capsule_update_board_setup, which is
in board.c, and only one board defines it, so instead of having a header
only for one function symbol, let's just use a weak symbol instead.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/include/asm/arch-rockchip/misc.h | 9 ---------
 arch/arm/mach-rockchip/board.c            | 5 ++++-
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/misc.h b/arch/arm/include/asm/arch-rockchip/misc.h
deleted file mode 100644
index ef37ff1661a..00000000000
--- a/arch/arm/include/asm/arch-rockchip/misc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * RK3399: Architecture common definitions
- *
- * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
- *      Rohan Garg <rohan.garg@collabora.com>
- */
-
-void rockchip_capsule_update_board_setup(void);
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 80b4514852f..4f666aee706 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -32,7 +32,6 @@
 #include <asm/arch-rockchip/boot_mode.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/periph.h>
-#include <asm/arch-rockchip/misc.h>
 #include <power/regulator.h>
 
 #if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
@@ -148,6 +147,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
 	env_set("dfu_alt_info", buf);
 }
 
+__weak void rockchip_capsule_update_board_setup(void)
+{
+}
+
 static void gpt_capsule_update_setup(void)
 {
 	int p, i, ret;

-- 
2.43.0

Re: [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> There's only one user of rockchip_capsule_update_board_setup, which is
> in board.c, and only one board defines it, so instead of having a header
> only for one function symbol, let's just use a weak symbol instead.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/include/asm/arch-rockchip/misc.h | 9 ---------
>   arch/arm/mach-rockchip/board.c            | 5 ++++-
>   2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/misc.h b/arch/arm/include/asm/arch-rockchip/misc.h
> deleted file mode 100644
> index ef37ff1661a..00000000000
> --- a/arch/arm/include/asm/arch-rockchip/misc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * RK3399: Architecture common definitions
> - *
> - * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> - *      Rohan Garg <rohan.garg@collabora.com>
> - */
> -
> -void rockchip_capsule_update_board_setup(void);
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 80b4514852f..4f666aee706 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -32,7 +32,6 @@
>   #include <asm/arch-rockchip/boot_mode.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/periph.h>
> -#include <asm/arch-rockchip/misc.h>
>   #include <power/regulator.h>
>   
>   #if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
> @@ -148,6 +147,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
>   	env_set("dfu_alt_info", buf);
>   }
>   
> +__weak void rockchip_capsule_update_board_setup(void)
> +{
> +}
> +
>   static void gpt_capsule_update_setup(void)
>   {
>   	int p, i, ret;
>

[PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
work really well.[00] The Linux kernel disables it for all SoCs[01], so
U-Boot needs to do the same in order to fix issues related to SD card on
RK3588. This autoswitching is enabled (by default) via the force_jtag
bitfield in SYS_GRF_SOC_CON6 in the TRM part1.

For some reason, when booting from SD card, the BootROM does mux the
SDMMC controller in the proper configuration for the RK3588-Jaguar. But
when we don't boot from SD card, U-Boot needs to set it up correctly to
allow accessing SD cards in that configuration.

Therefore, let's disable the JTAG mode for the SDMMC pins so that the SD
controller can be used either as a fallback mechanism to find U-Boot
proper when the boot medium used to load TPL/SPL cannot find U-Boot
proper, or to be used in U-Boot CLI.

Note that soc_con[0] is reserved. But considering that it's way more
user-friendly to access soc_con1 from the TRM with soc_con[1] than
soc_con[0], and that soc_con0 would actually be located at 4 bytes
before soc_con1, let's just make soc_con0 part of the soc_con array.

[00] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c9b75d51c940c25587a2ad72ec7ec60490abfb6c
[01] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/include/asm/arch-rockchip/grf_rk3588.h | 24 ++++++++++++++++++++++++
 arch/arm/mach-rockchip/rk3588/rk3588.c          |  7 +++++++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
index e0694068bb1..f0ecff97f0b 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -32,4 +32,28 @@ struct rk3588_pmu1grf {
 
 check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
 
+#define SYS_GRF_BASE	0xfd58c000
+
+struct rk3588_sysgrf {
+	unsigned int wdt_con0;
+	unsigned int reserved0[(0x0010 - 0x0000) / 4 - 1];
+	unsigned int uart_con[2];
+	unsigned int reserved1[(0x00c0 - 0x0014) / 4 - 1];
+	unsigned int gic_con0;
+	unsigned int reserved2[(0x0200 - 0x00c0) / 4 - 1];
+	unsigned int memcfg_con[32];
+	unsigned int reserved3[(0x0300 - 0x027c) / 4 - 1];
+	/* soc_con0 is reserved */
+	unsigned int soc_con[14];
+	unsigned int reserved4[(0x0380 - 0x0334) / 4 - 1];
+	unsigned int soc_status[4];
+	unsigned int reserved5[(0x0500 - 0x038c) / 4 - 1];
+	unsigned int otp_key08;
+	unsigned int otp_key0d;
+	unsigned int otp_key0e;
+	unsigned int reserved6[(0x0600 - 0x0508) / 4 - 1];
+	unsigned int chip_id;
+};
+
+check_member(rk3588_sysgrf, chip_id, 0x0600);
 #endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 38e95a6e2b2..c5eeda9d751 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -11,6 +11,7 @@
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/ioc_rk3588.h>
+#include <asm/arch-rockchip/grf_rk3588.h>
 
 #define FIREWALL_DDR_BASE		0xfe030000
 #define FW_DDR_MST5_REG			0x54
@@ -35,6 +36,8 @@
 #define BUS_IOC_GPIO2D_IOMUX_SEL_H	0x5c
 #define BUS_IOC_GPIO3A_IOMUX_SEL_L	0x60
 
+#define SYS_GRF_FORCE_JTAG		BIT(14)
+
 /**
  * Boot-device identifiers used by the BROM on RK3588 when device is booted
  * from SPI flash. IOMUX used for SPI flash affect the value used by the BROM
@@ -134,6 +137,7 @@ void rockchip_stimer_init(void)
 int arch_cpu_init(void)
 {
 #ifdef CONFIG_SPL_BUILD
+	static struct rk3588_sysgrf * const sys_grf = (void *)SYS_GRF_BASE;
 	int secure_reg;
 
 	/* Set the SDMMC eMMC crypto_ns FSPI access secure area */
@@ -168,6 +172,9 @@ int arch_cpu_init(void)
 	secure_reg = readl(FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
 	secure_reg &= 0xffff0000;
 	writel(secure_reg, FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
+
+	/* Disable JTAG exposed on SDMMC */
+	rk_clrreg(&sys_grf->soc_con[6], SYS_GRF_FORCE_JTAG);
 #endif
 
 	return 0;

-- 
2.43.0

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Kever Yang]

Hi Quentin,

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
> work really well.[00] The Linux kernel disables it for all SoCs[01], so
> U-Boot needs to do the same in order to fix issues related to SD card on
> RK3588. This autoswitching is enabled (by default) via the force_jtag
> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>
> For some reason, when booting from SD card, the BootROM does mux the
> SDMMC controller in the proper configuration for the RK3588-Jaguar. But
> when we don't boot from SD card, U-Boot needs to set it up correctly to
> allow accessing SD cards in that configuration.

Could you share what's the really issue you met in your board?

The SD card will need to enable SD-DET for SD card function int he 
hardware design,

which is rockchip reference design and followed by most of the customer 
and boards.

This feature works in all the rk3588 boards we known, and no need to 
disable this auto switching.


Thanks,

- Kever

>
> Therefore, let's disable the JTAG mode for the SDMMC pins so that the SD
> controller can be used either as a fallback mechanism to find U-Boot
> proper when the boot medium used to load TPL/SPL cannot find U-Boot
> proper, or to be used in U-Boot CLI.
>
> Note that soc_con[0] is reserved. But considering that it's way more
> user-friendly to access soc_con1 from the TRM with soc_con[1] than
> soc_con[0], and that soc_con0 would actually be located at 4 bytes
> before soc_con1, let's just make soc_con0 part of the soc_con array.
>
> [00] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c9b75d51c940c25587a2ad72ec7ec60490abfb6c
> [01] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>   arch/arm/include/asm/arch-rockchip/grf_rk3588.h | 24 ++++++++++++++++++++++++
>   arch/arm/mach-rockchip/rk3588/rk3588.c          |  7 +++++++
>   2 files changed, 31 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
> index e0694068bb1..f0ecff97f0b 100644
> --- a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
> @@ -32,4 +32,28 @@ struct rk3588_pmu1grf {
>   
>   check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
>   
> +#define SYS_GRF_BASE	0xfd58c000
> +
> +struct rk3588_sysgrf {
> +	unsigned int wdt_con0;
> +	unsigned int reserved0[(0x0010 - 0x0000) / 4 - 1];
> +	unsigned int uart_con[2];
> +	unsigned int reserved1[(0x00c0 - 0x0014) / 4 - 1];
> +	unsigned int gic_con0;
> +	unsigned int reserved2[(0x0200 - 0x00c0) / 4 - 1];
> +	unsigned int memcfg_con[32];
> +	unsigned int reserved3[(0x0300 - 0x027c) / 4 - 1];
> +	/* soc_con0 is reserved */
> +	unsigned int soc_con[14];
> +	unsigned int reserved4[(0x0380 - 0x0334) / 4 - 1];
> +	unsigned int soc_status[4];
> +	unsigned int reserved5[(0x0500 - 0x038c) / 4 - 1];
> +	unsigned int otp_key08;
> +	unsigned int otp_key0d;
> +	unsigned int otp_key0e;
> +	unsigned int reserved6[(0x0600 - 0x0508) / 4 - 1];
> +	unsigned int chip_id;
> +};
> +
> +check_member(rk3588_sysgrf, chip_id, 0x0600);
>   #endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
> diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c b/arch/arm/mach-rockchip/rk3588/rk3588.c
> index 38e95a6e2b2..c5eeda9d751 100644
> --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
> +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
> @@ -11,6 +11,7 @@
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/ioc_rk3588.h>
> +#include <asm/arch-rockchip/grf_rk3588.h>
>   
>   #define FIREWALL_DDR_BASE		0xfe030000
>   #define FW_DDR_MST5_REG			0x54
> @@ -35,6 +36,8 @@
>   #define BUS_IOC_GPIO2D_IOMUX_SEL_H	0x5c
>   #define BUS_IOC_GPIO3A_IOMUX_SEL_L	0x60
>   
> +#define SYS_GRF_FORCE_JTAG		BIT(14)
> +
>   /**
>    * Boot-device identifiers used by the BROM on RK3588 when device is booted
>    * from SPI flash. IOMUX used for SPI flash affect the value used by the BROM
> @@ -134,6 +137,7 @@ void rockchip_stimer_init(void)
>   int arch_cpu_init(void)
>   {
>   #ifdef CONFIG_SPL_BUILD
> +	static struct rk3588_sysgrf * const sys_grf = (void *)SYS_GRF_BASE;
>   	int secure_reg;
>   
>   	/* Set the SDMMC eMMC crypto_ns FSPI access secure area */
> @@ -168,6 +172,9 @@ int arch_cpu_init(void)
>   	secure_reg = readl(FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
>   	secure_reg &= 0xffff0000;
>   	writel(secure_reg, FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
> +
> +	/* Disable JTAG exposed on SDMMC */
> +	rk_clrreg(&sys_grf->soc_con[6], SYS_GRF_FORCE_JTAG);
>   #endif
>   
>   	return 0;
>

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

Hi Kever,

On 1/24/24 11:19, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/23 22:49, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
>> work really well.[00] The Linux kernel disables it for all SoCs[01], so
>> U-Boot needs to do the same in order to fix issues related to SD card on
>> RK3588. This autoswitching is enabled (by default) via the force_jtag
>> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>>
>> For some reason, when booting from SD card, the BootROM does mux the
>> SDMMC controller in the proper configuration for the RK3588-Jaguar. But
>> when we don't boot from SD card, U-Boot needs to set it up correctly to
>> allow accessing SD cards in that configuration.
> 
> Could you share what's the really issue you met in your board?
> 

I revert the patch and then I have the following when booting from eMMC:

"""
DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
Manufacturer ID:0x1
CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
CH1 RX Vref:30.1%, TX Vref:20.8%,0.0%
CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out

U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
Trying to boot from MMC1
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
NOTICE:  BL31: Built : 10:14:29, May  9 2023
INFO:    spec: 0x1
INFO:    ext 32k is not valid
INFO:    ddr: stride-en 4CH
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
INFO:    system boots from cpu-hwid-0
INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
INFO:    BL31: Initialising Exception Handling Framework
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without 
OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0xa00000
INFO:    SPSR = 0x3c9


U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)

Model: Theobroma Systems RK3588-SBC Jaguar
DRAM:  4 GiB (effective 3.7 GiB)
Core:  327 devices, 26 uclasses, devicetree: separate
MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default 
environment

In:    serial@feb50000
Out:   serial@feb50000
Err:   serial@feb50000
Model: Theobroma Systems RK3588-SBC Jaguar
Net:   eth0: ethernet@fe1b0000
Hit any key to stop autoboot:  0
=> mmc dev 1
unable to select a mode
=>
"""

> The SD card will need to enable SD-DET for SD card function int he 
> hardware design,
> 

We do not have an SD-DET on that board, this is not possible (the 
connector doesn't support it).

SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the 
state by default since we expose it on an external connector) but we 
plan to let customer use it as a GPIO.

> which is rockchip reference design and followed by most of the customer 
> and boards.
> 
> This feature works in all the rk3588 boards we known, and no need to 
> disable this auto switching.
> 

This is clearly not what people have experienced, c.f. the Linux kernel 
patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=6f6878ec6faf16a5f36761c93da6ea9cf09adb33

Note that jtag_switching has been disabled for all Rockchip SoCs in the 
kernel, for a long long time already, c.f. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=4c58063d4258f6beb4fd5647db6b58f49e337c8f

Cheers,
Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Kever Yang]

Hi Quentin,

On 2024/1/24 18:50, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/24/24 11:19, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>
>>> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
>>> work really well.[00] The Linux kernel disables it for all SoCs[01], so
>>> U-Boot needs to do the same in order to fix issues related to SD 
>>> card on
>>> RK3588. This autoswitching is enabled (by default) via the force_jtag
>>> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>>>
>>> For some reason, when booting from SD card, the BootROM does mux the
>>> SDMMC controller in the proper configuration for the RK3588-Jaguar. But
>>> when we don't boot from SD card, U-Boot needs to set it up correctly to
>>> allow accessing SD cards in that configuration.
>>
>> Could you share what's the really issue you met in your board?
>>
>
> I revert the patch and then I have the following when booting from eMMC:
>
> """
> DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
> LPDDR4X, 2112MHz
> channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> Manufacturer ID:0x1
> CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
> CH1 RX Vref:30.1%, TX Vref:20.8%,0.0%
> CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
> CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
> change to F1: 528MHz
> change to F2: 1068MHz
> change to F3: 1560MHz
> change to F0: 2112MHz
> out
>
> U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
> Trying to boot from MMC1
> ## Checking hash(es) for config config-1 ... OK
> ## Checking hash(es) for Image atf-1 ... sha256+ OK
> ## Checking hash(es) for Image u-boot ... sha256+ OK
> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
> ## Checking hash(es) for Image atf-2 ... sha256+ OK
> ## Checking hash(es) for Image atf-3 ... sha256+ OK
> INFO:    Preloader serial: 2
> NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
> NOTICE:  BL31: Built : 10:14:29, May  9 2023
> INFO:    spec: 0x1
> INFO:    ext 32k is not valid
> INFO:    ddr: stride-en 4CH
> INFO:    GICv3 without legacy support detected.
> INFO:    ARM GICv3 driver initialized in EL3
> INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
> INFO:    system boots from cpu-hwid-0
> INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
> INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
> INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
> INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
> INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
> INFO:    BL31: Initialising Exception Handling Framework
> INFO:    BL31: Initializing runtime services
> WARNING: No OPTEE provided by BL2 boot loader, Booting device without 
> OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
> ERROR:   Error initializing runtime service opteed_fast
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0xa00000
> INFO:    SPSR = 0x3c9
>
>
> U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>
> Model: Theobroma Systems RK3588-SBC Jaguar
> DRAM:  4 GiB (effective 3.7 GiB)
> Core:  327 devices, 26 uclasses, devicetree: separate
> MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default 
> environment
>
> In:    serial@feb50000
> Out:   serial@feb50000
> Err:   serial@feb50000
> Model: Theobroma Systems RK3588-SBC Jaguar
> Net:   eth0: ethernet@fe1b0000
> Hit any key to stop autoboot:  0
> => mmc dev 1
> unable to select a mode
> =>
> """
>
>> The SD card will need to enable SD-DET for SD card function int he 
>> hardware design,
>>
>
> We do not have an SD-DET on that board, this is not possible (the 
> connector doesn't support it).
>
> SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the 
> state by default since we expose it on an external connector) but we 
> plan to let customer use it as a GPIO.


I didn't follow this issue closely in kernel side before, but I would 
like to know why this happen.
Is it possible to share the schematic of your board? I want to 
understand why you didn't use SDMMC_DET for the card slot in hardware 
design, which always need an IO for driver to detect the card.
What I know is if the SD card using all the IO including SDMMC_DET with 
its iomux set to sdmmc function, then the force_jtag should work correctly.
If you only use IO signal other than SDMMC_DET as sdmmc function, and 
set SDMMC_DET iomux work as GPIO, then yes, you need to disable the 
force_jtag.
Since SDMMC_DET in rk3588 is an IO only have one function(not like other 
GPIOs may have more than 2 functions for choice), this IO can always be 
used as SDMMC_DET without conflict when the board has SDcard support.


Thanks,
- Kever
>
>> which is rockchip reference design and followed by most of the 
>> customer and boards.
>>
>> This feature works in all the rk3588 boards we known, and no need to 
>> disable this auto switching.
>>
>
> This is clearly not what people have experienced, c.f. the Linux 
> kernel patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=6f6878ec6faf16a5f36761c93da6ea9cf09adb33 
>
>
> Note that jtag_switching has been disabled for all Rockchip SoCs in 
> the kernel, for a long long time already, c.f. 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=4c58063d4258f6beb4fd5647db6b58f49e337c8f
>
> Cheers,
> Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

Hi Kever,

On 1/25/24 11:29, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/24 18:50, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 1/24/24 11:19, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>
>>>> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
>>>> work really well.[00] The Linux kernel disables it for all SoCs[01], so
>>>> U-Boot needs to do the same in order to fix issues related to SD 
>>>> card on
>>>> RK3588. This autoswitching is enabled (by default) via the force_jtag
>>>> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>>>>
>>>> For some reason, when booting from SD card, the BootROM does mux the
>>>> SDMMC controller in the proper configuration for the RK3588-Jaguar. But
>>>> when we don't boot from SD card, U-Boot needs to set it up correctly to
>>>> allow accessing SD cards in that configuration.
>>>
>>> Could you share what's the really issue you met in your board?
>>>
>>
>> I revert the patch and then I have the following when booting from eMMC:
>>
>> """
>> DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
>> LPDDR4X, 2112MHz
>> channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> Manufacturer ID:0x1
>> CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
>> CH1 RX Vref:30.1%, TX Vref:20.8%,0.0%
>> CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
>> CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
>> change to F1: 528MHz
>> change to F2: 1068MHz
>> change to F3: 1560MHz
>> change to F0: 2112MHz
>> out
>>
>> U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>> Trying to boot from MMC1
>> ## Checking hash(es) for config config-1 ... OK
>> ## Checking hash(es) for Image atf-1 ... sha256+ OK
>> ## Checking hash(es) for Image u-boot ... sha256+ OK
>> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>> ## Checking hash(es) for Image atf-3 ... sha256+ OK
>> INFO:    Preloader serial: 2
>> NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
>> NOTICE:  BL31: Built : 10:14:29, May  9 2023
>> INFO:    spec: 0x1
>> INFO:    ext 32k is not valid
>> INFO:    ddr: stride-en 4CH
>> INFO:    GICv3 without legacy support detected.
>> INFO:    ARM GICv3 driver initialized in EL3
>> INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
>> INFO:    system boots from cpu-hwid-0
>> INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
>> INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
>> INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
>> INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
>> INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
>> INFO:    BL31: Initialising Exception Handling Framework
>> INFO:    BL31: Initializing runtime services
>> WARNING: No OPTEE provided by BL2 boot loader, Booting device without 
>> OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
>> ERROR:   Error initializing runtime service opteed_fast
>> INFO:    BL31: Preparing for EL3 exit to normal world
>> INFO:    Entry point address = 0xa00000
>> INFO:    SPSR = 0x3c9
>>
>>
>> U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>>
>> Model: Theobroma Systems RK3588-SBC Jaguar
>> DRAM:  4 GiB (effective 3.7 GiB)
>> Core:  327 devices, 26 uclasses, devicetree: separate
>> MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>> environment
>>
>> In:    serial@feb50000
>> Out:   serial@feb50000
>> Err:   serial@feb50000
>> Model: Theobroma Systems RK3588-SBC Jaguar
>> Net:   eth0: ethernet@fe1b0000
>> Hit any key to stop autoboot:  0
>> => mmc dev 1
>> unable to select a mode
>> =>
>> """
>>
>>> The SD card will need to enable SD-DET for SD card function int he 
>>> hardware design,
>>>
>>
>> We do not have an SD-DET on that board, this is not possible (the 
>> connector doesn't support it).
>>
>> SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the 
>> state by default since we expose it on an external connector) but we 
>> plan to let customer use it as a GPIO.
> 
> 
> I didn't follow this issue closely in kernel side before, but I would 
> like to know why this happen.
> Is it possible to share the schematic of your board? I want to 
> understand why you didn't use SDMMC_DET for the card slot in hardware 
> design, which always need an IO for driver to detect the card.

We don't have a dedicated CD pin for the SD card connector.

https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is 
the SD card connector we use.

This is allowed by the SD spec, c.f. Table 3-1 : SD Memory Card Pad 
Assignment[1]

"""
1 CD/DAT3(2) I/O/PP(3) Card Detect/Data Line [Bit 3]

2) The extended DAT lines (DAT1-DAT3) are input on power up. They start 
to operate as DAT lines after SET_BUS_WIDTH command. The Host shall keep 
its own DAT1-DAT3 lines in input mode, as well, while they are not used.
3) At power up this line has a 50KOhm pull up enabled in the card. This 
resistor serves two functions Card detection and Mode Selection. For 
Mode Selection, the host can drive the line high or let it be pulled 
high to select SD mode. If the host wants to select SPI mode it should 
drive the line low. For Card detection, the host detects that the line 
is pulled high. This pull-up should be disconnected by the user, during 
regular data transfer, with SET_CLR_CARD_DETECT (ACMD42) command
"""

[1] https://academy.cba.mit.edu/classes/networking_communications/SD/SD.pdf

> What I know is if the SD card using all the IO including SDMMC_DET with 
> its iomux set to sdmmc function, then the force_jtag should work correctly.
> If you only use IO signal other than SDMMC_DET as sdmmc function, and 
> set SDMMC_DET iomux work as GPIO, then yes, you need to disable the 
> force_jtag.
> Since SDMMC_DET in rk3588 is an IO only have one function(not like other 
> GPIOs may have more than 2 functions for choice), this IO can always be 
> used as SDMMC_DET without conflict when the board has SDcard support.
> 

We don't use SDMMC_DET for card detection, but in GPIO mode **and** we 
cannot use SDMMC_DET for card detection because the connector doesn't 
expose a card detect pin.

We just use broken-cd; property (c.f. 
https://elixir.bootlin.com/linux/v6.8-rc1/source/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts#L402) 
to do polling for card detect in the kernel, but we wouldn't mind too 
much if there's no detection for the SD card anyway as it is cumbersome 
to replace the SD card (which is the purpose of this connector, it needs 
be extra secure since the board is supposed to be used in moving robots) 
so not much of a use-case to detect an insertion/removal at runtime.

Cheers,
Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Kever Yang]

Hi Quentin,

On 2024/1/25 19:02, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/25/24 11:29, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/24 18:50, Quentin Schulz wrote:
>>> Hi Kever,
>>>
>>> On 1/24/24 11:19, Kever Yang wrote:
>>>> Hi Quentin,
>>>>
>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>
>>>>> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
>>>>> work really well.[00] The Linux kernel disables it for all 
>>>>> SoCs[01], so
>>>>> U-Boot needs to do the same in order to fix issues related to SD 
>>>>> card on
>>>>> RK3588. This autoswitching is enabled (by default) via the force_jtag
>>>>> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>>>>>
>>>>> For some reason, when booting from SD card, the BootROM does mux the
>>>>> SDMMC controller in the proper configuration for the 
>>>>> RK3588-Jaguar. But
>>>>> when we don't boot from SD card, U-Boot needs to set it up 
>>>>> correctly to
>>>>> allow accessing SD cards in that configuration.
>>>>
>>>> Could you share what's the really issue you met in your board?
>>>>
>>>
>>> I revert the patch and then I have the following when booting from 
>>> eMMC:
>>>
>>> """
>>> DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
>>> LPDDR4X, 2112MHz
>>> channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>> channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>> channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>> channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>> Manufacturer ID:0x1
>>> CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
>>> CH1 RX Vref:30.1%, TX Vref:20.8%,0.0%
>>> CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
>>> CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
>>> change to F1: 528MHz
>>> change to F2: 1068MHz
>>> change to F3: 1560MHz
>>> change to F0: 2112MHz
>>> out
>>>
>>> U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>>> Trying to boot from MMC1
>>> ## Checking hash(es) for config config-1 ... OK
>>> ## Checking hash(es) for Image atf-1 ... sha256+ OK
>>> ## Checking hash(es) for Image u-boot ... sha256+ OK
>>> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>>> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>>> ## Checking hash(es) for Image atf-3 ... sha256+ OK
>>> INFO:    Preloader serial: 2
>>> NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
>>> NOTICE:  BL31: Built : 10:14:29, May  9 2023
>>> INFO:    spec: 0x1
>>> INFO:    ext 32k is not valid
>>> INFO:    ddr: stride-en 4CH
>>> INFO:    GICv3 without legacy support detected.
>>> INFO:    ARM GICv3 driver initialized in EL3
>>> INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
>>> INFO:    system boots from cpu-hwid-0
>>> INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
>>> INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
>>> INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
>>> INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
>>> INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
>>> INFO:    BL31: Initialising Exception Handling Framework
>>> INFO:    BL31: Initializing runtime services
>>> WARNING: No OPTEE provided by BL2 boot loader, Booting device 
>>> without OPTEE initialization. SMC`s destined for OPTEE will return 
>>> SMC_UNK
>>> ERROR:   Error initializing runtime service opteed_fast
>>> INFO:    BL31: Preparing for EL3 exit to normal world
>>> INFO:    Entry point address = 0xa00000
>>> INFO:    SPSR = 0x3c9
>>>
>>>
>>> U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>>>
>>> Model: Theobroma Systems RK3588-SBC Jaguar
>>> DRAM:  4 GiB (effective 3.7 GiB)
>>> Core:  327 devices, 26 uclasses, devicetree: separate
>>> MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
>>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>>> environment
>>>
>>> In:    serial@feb50000
>>> Out:   serial@feb50000
>>> Err:   serial@feb50000
>>> Model: Theobroma Systems RK3588-SBC Jaguar
>>> Net:   eth0: ethernet@fe1b0000
>>> Hit any key to stop autoboot:  0
>>> => mmc dev 1
>>> unable to select a mode
>>> =>
>>> """
>>>
>>>> The SD card will need to enable SD-DET for SD card function int he 
>>>> hardware design,
>>>>
>>>
>>> We do not have an SD-DET on that board, this is not possible (the 
>>> connector doesn't support it).
>>>
>>> SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating 
>>> (the state by default since we expose it on an external connector) 
>>> but we plan to let customer use it as a GPIO.
>>
>>
>> I didn't follow this issue closely in kernel side before, but I would 
>> like to know why this happen.
>> Is it possible to share the schematic of your board? I want to 
>> understand why you didn't use SDMMC_DET for the card slot in hardware 
>> design, which always need an IO for driver to detect the card.
>
> We don't have a dedicated CD pin for the SD card connector.
>
> https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is 
> the SD card connector we use.

Thanks for your information, but I think you are using the wrong microSD 
connector for rk3588 and maybe also for other rockchip SoCs.
Here are four microSD card connector from the web you provide, all of 
them have card detect signal available for pcb:
https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>
> This is allowed by the SD spec, c.f. Table 3-1 : SD Memory Card Pad 
> Assignment[1]
>
> """
> 1 CD/DAT3(2) I/O/PP(3) Card Detect/Data Line [Bit 3]
>
> 2) The extended DAT lines (DAT1-DAT3) are input on power up. They 
> start to operate as DAT lines after SET_BUS_WIDTH command. The Host 
> shall keep its own DAT1-DAT3 lines in input mode, as well, while they 
> are not used.
> 3) At power up this line has a 50KOhm pull up enabled in the card. 
> This resistor serves two functions Card detection and Mode Selection. 
> For Mode Selection, the host can drive the line high or let it be 
> pulled high to select SD mode. If the host wants to select SPI mode it 
> should drive the line low. For Card detection, the host detects that 
> the line is pulled high. This pull-up should be disconnected by the 
> user, during regular data transfer, with SET_CLR_CARD_DETECT (ACMD42) 
> command
> """

Yes, you are right for the SD spec, there is another design for Card 
detection, which need the controller
supports SET_CLR_CARD_DETECT command, and like many other SoCs, rk3588 
does not support it.
Only RTS5208(a Realtek PCI-E Card Reader) supports this command when I 
search this cmd in kernel code.

Back to this patch, I think it would be better to turn off the 
force_jtag in board level instead of soc level for now.


Thanks,
- Kever
>
> [1] 
> https://academy.cba.mit.edu/classes/networking_communications/SD/SD.pdf
>
>> What I know is if the SD card using all the IO including SDMMC_DET 
>> with its iomux set to sdmmc function, then the force_jtag should work 
>> correctly.
>> If you only use IO signal other than SDMMC_DET as sdmmc function, and 
>> set SDMMC_DET iomux work as GPIO, then yes, you need to disable the 
>> force_jtag.
>> Since SDMMC_DET in rk3588 is an IO only have one function(not like 
>> other GPIOs may have more than 2 functions for choice), this IO can 
>> always be used as SDMMC_DET without conflict when the board has 
>> SDcard support.
>>
>
> We don't use SDMMC_DET for card detection, but in GPIO mode **and** we 
> cannot use SDMMC_DET for card detection because the connector doesn't 
> expose a card detect pin.
>
> We just use broken-cd; property (c.f. 
> https://elixir.bootlin.com/linux/v6.8-rc1/source/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts#L402) 
> to do polling for card detect in the kernel, but we wouldn't mind too 
> much if there's no detection for the SD card anyway as it is 
> cumbersome to replace the SD card (which is the purpose of this 
> connector, it needs be extra secure since the board is supposed to be 
> used in moving robots) so not much of a use-case to detect an 
> insertion/removal at runtime.
>
> Cheers,
> Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

Hi Kever,

On 1/26/24 03:57, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/25 19:02, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 1/25/24 11:29, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/1/24 18:50, Quentin Schulz wrote:
>>>> Hi Kever,
>>>>
>>>> On 1/24/24 11:19, Kever Yang wrote:
>>>>> Hi Quentin,
>>>>>
>>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>>
>>>>>> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
>>>>>> work really well.[00] The Linux kernel disables it for all 
>>>>>> SoCs[01], so
>>>>>> U-Boot needs to do the same in order to fix issues related to SD 
>>>>>> card on
>>>>>> RK3588. This autoswitching is enabled (by default) via the force_jtag
>>>>>> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>>>>>>
>>>>>> For some reason, when booting from SD card, the BootROM does mux the
>>>>>> SDMMC controller in the proper configuration for the 
>>>>>> RK3588-Jaguar. But
>>>>>> when we don't boot from SD card, U-Boot needs to set it up 
>>>>>> correctly to
>>>>>> allow accessing SD cards in that configuration.
>>>>>
>>>>> Could you share what's the really issue you met in your board?
>>>>>
>>>>
>>>> I revert the patch and then I have the following when booting from 
>>>> eMMC:
>>>>
>>>> """
>>>> DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
>>>> LPDDR4X, 2112MHz
>>>> channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>>> channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>>> channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>>> channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>>>> Manufacturer ID:0x1
>>>> CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
>>>> CH1 RX Vref:30.1%, TX Vref:20.8%,0.0%
>>>> CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
>>>> CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
>>>> change to F1: 528MHz
>>>> change to F2: 1068MHz
>>>> change to F3: 1560MHz
>>>> change to F0: 2112MHz
>>>> out
>>>>
>>>> U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>>>> Trying to boot from MMC1
>>>> ## Checking hash(es) for config config-1 ... OK
>>>> ## Checking hash(es) for Image atf-1 ... sha256+ OK
>>>> ## Checking hash(es) for Image u-boot ... sha256+ OK
>>>> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>>>> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>>>> ## Checking hash(es) for Image atf-3 ... sha256+ OK
>>>> INFO:    Preloader serial: 2
>>>> NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
>>>> NOTICE:  BL31: Built : 10:14:29, May  9 2023
>>>> INFO:    spec: 0x1
>>>> INFO:    ext 32k is not valid
>>>> INFO:    ddr: stride-en 4CH
>>>> INFO:    GICv3 without legacy support detected.
>>>> INFO:    ARM GICv3 driver initialized in EL3
>>>> INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
>>>> INFO:    system boots from cpu-hwid-0
>>>> INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
>>>> INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
>>>> INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
>>>> INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
>>>> INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
>>>> INFO:    BL31: Initialising Exception Handling Framework
>>>> INFO:    BL31: Initializing runtime services
>>>> WARNING: No OPTEE provided by BL2 boot loader, Booting device 
>>>> without OPTEE initialization. SMC`s destined for OPTEE will return 
>>>> SMC_UNK
>>>> ERROR:   Error initializing runtime service opteed_fast
>>>> INFO:    BL31: Preparing for EL3 exit to normal world
>>>> INFO:    Entry point address = 0xa00000
>>>> INFO:    SPSR = 0x3c9
>>>>
>>>>
>>>> U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>>>>
>>>> Model: Theobroma Systems RK3588-SBC Jaguar
>>>> DRAM:  4 GiB (effective 3.7 GiB)
>>>> Core:  327 devices, 26 uclasses, devicetree: separate
>>>> MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
>>>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>>>> environment
>>>>
>>>> In:    serial@feb50000
>>>> Out:   serial@feb50000
>>>> Err:   serial@feb50000
>>>> Model: Theobroma Systems RK3588-SBC Jaguar
>>>> Net:   eth0: ethernet@fe1b0000
>>>> Hit any key to stop autoboot:  0
>>>> => mmc dev 1
>>>> unable to select a mode
>>>> =>
>>>> """
>>>>
>>>>> The SD card will need to enable SD-DET for SD card function int he 
>>>>> hardware design,
>>>>>
>>>>
>>>> We do not have an SD-DET on that board, this is not possible (the 
>>>> connector doesn't support it).
>>>>
>>>> SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating 
>>>> (the state by default since we expose it on an external connector) 
>>>> but we plan to let customer use it as a GPIO.
>>>
>>>
>>> I didn't follow this issue closely in kernel side before, but I would 
>>> like to know why this happen.
>>> Is it possible to share the schematic of your board? I want to 
>>> understand why you didn't use SDMMC_DET for the card slot in hardware 
>>> design, which always need an IO for driver to detect the card.
>>
>> We don't have a dedicated CD pin for the SD card connector.
>>
>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is the SD card connector we use.
> 
> Thanks for your information, but I think you are using the wrong microSD 
> connector for rk3588 and maybe also for other rockchip SoCs.
> Here are four microSD card connector from the web you provide, all of 
> them have card detect signal available for pcb:
> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors

None of those fit our requirements. We need a safe system that doesn't 
break because of vibrations or shocks. Push-pull connectors are out of 
question for our design. We have had issues with our Q7 devkit with 
push-pull connector with SD cards slightly smaller or inserted somewhat 
the wrong way. I can recall also countless of discussions in the early 
days of the Raspberry Pis where there were a lot of issues related to SD 
cards.

This is basically the mechanism we are using 
https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg

I can admit on our pictures of Jaguar and on the Digikey link I provided 
earlier that it is not clear it is THAT kind of connector and not a 
push-pull one.

Also.... It works just fine in Linux kernel with broken-cd and in U-Boot 
with this patch, sooooooo I don't think it is "the wrong microSD 
connector for rk3588 and maybe also for other rockchip SoCs." :)

>>
>> This is allowed by the SD spec, c.f. Table 3-1 : SD Memory Card Pad 
>> Assignment[1]
>>
>> """
>> 1 CD/DAT3(2) I/O/PP(3) Card Detect/Data Line [Bit 3]
>>
>> 2) The extended DAT lines (DAT1-DAT3) are input on power up. They 
>> start to operate as DAT lines after SET_BUS_WIDTH command. The Host 
>> shall keep its own DAT1-DAT3 lines in input mode, as well, while they 
>> are not used.
>> 3) At power up this line has a 50KOhm pull up enabled in the card. 
>> This resistor serves two functions Card detection and Mode Selection. 
>> For Mode Selection, the host can drive the line high or let it be 
>> pulled high to select SD mode. If the host wants to select SPI mode it 
>> should drive the line low. For Card detection, the host detects that 
>> the line is pulled high. This pull-up should be disconnected by the 
>> user, during regular data transfer, with SET_CLR_CARD_DETECT (ACMD42) 
>> command
>> """
> 
> Yes, you are right for the SD spec, there is another design for Card 
> detection, which need the controller
> supports SET_CLR_CARD_DETECT command, and like many other SoCs, rk3588 
> does not support it.

Thanks for the confirmation, I indeed hadn't found anything in the TRM 
for it... which is fine, we are not expecting it anyway, we use 
broken-cd; for it now.

My understanding is that only if none of broken-cd, cd-gpios or 
non-removable are passed that this kind of card detect mechanism is 
used. I don't think I should have given this information, as this is not 
what we're using, so I may have introduced confusing information into 
the discussion, sorry.

In U-Boot, broken-cd means that we assume the card is always present.

In the Linux kernel, as far as I could tell, the check is done with 
mmc_sd_detect() which calls _mmc_detect_card_removed() which calls 
host->bus_ops->alive() which is mmc_sd_alive() which sends CMD_13 to the 
SD card. It'll wait for the command to return, which it won't if the 
card isn't present, thus detecting card presence. The implementation of 
the CMD13 command is required by the spec.

According to the SD spec:
"""
The host may poll the status of the card with a SEND_STATUS command 
(CMD13) at any time, and the card will respond with
its status.
"""

So this is perfectly fine for using SD cards on a system without a CD 
pin and without relying on the DAT3 pin to be used as CD pin (which 
Rockchip SoCs - at least RK3588 - doesn't support).

> Only RTS5208(a Realtek PCI-E Card Reader) supports this command when I 
> search this cmd in kernel code.
> 
> Back to this patch, I think it would be better to turn off the 
> force_jtag in board level instead of soc level for now.
> 

I strongly disagree with this. This is making the bring-up of boards 
unnecessarily complex. I'm lucky I'm working with Heiko who encountered 
this issue years ago and remembered some funny things happening with the 
force_jtag feature, otherwise it'd have taken me much longer to figure 
all this out.

What is the benefit for keeping force_jtag enabled? Especially since the 
kernel has disabled it for almost a decade already? In my opinion this 
is a debugging feature, if you need it you can enable it again by 
removing this line or writing to the register manually. And this would 
make it even more explicit that such a feature exist because there is 
now some comment for it.

Cheers,
Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Dragan Simic]

Hello Quentin,

On 2024-01-26 11:37, Quentin Schulz wrote:
> On 1/26/24 03:57, Kever Yang wrote:
>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>> We don't have a dedicated CD pin for the SD card connector.
>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807 
>>> is the SD card connector we use.
>> 
>> Thanks for your information, but I think you are using the wrong 
>> microSD connector for rk3588 and maybe also for other rockchip SoCs.
>> Here are four microSD card connector from the web you provide, all of 
>> them have card detect signal available for pcb:
>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
> 
> None of those fit our requirements. We need a safe system that doesn't
> break because of vibrations or shocks. Push-pull connectors are out of
> question for our design. We have had issues with our Q7 devkit with
> push-pull connector with SD cards slightly smaller or inserted
> somewhat the wrong way. I can recall also countless of discussions in
> the early days of the Raspberry Pis where there were a lot of issues
> related to SD cards.
> 
> This is basically the mechanism we are using
> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg

Please, allow me to interject...  I'm really curious why don't you
use eMMC chips instead of microSD cards?  I mean, if the reliability
is of utmost importance, I wouldn't even consider microSD cards, not
even the high-endurance variants.

> I can admit on our pictures of Jaguar and on the Digikey link I
> provided earlier that it is not clear it is THAT kind of connector and
> not a push-pull one.

It was clear to me, because I've already used hinged microSD slots. :)

> Also.... It works just fine in Linux kernel with broken-cd and in
> U-Boot with this patch, sooooooo I don't think it is "the wrong
> microSD connector for rk3588 and maybe also for other rockchip SoCs."
> :)

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

Hi Dragan,

On 1/26/24 12:04, Dragan Simic wrote:
> [Some people who received this message don't often get email from 
> dsimic@manjaro.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello Quentin,
> 
> On 2024-01-26 11:37, Quentin Schulz wrote:
>> On 1/26/24 03:57, Kever Yang wrote:
>>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>>> We don't have a dedicated CD pin for the SD card connector.
>>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807
>>>> is the SD card connector we use.
>>>
>>> Thanks for your information, but I think you are using the wrong
>>> microSD connector for rk3588 and maybe also for other rockchip SoCs.
>>> Here are four microSD card connector from the web you provide, all of
>>> them have card detect signal available for pcb:
>>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>>
>> None of those fit our requirements. We need a safe system that doesn't
>> break because of vibrations or shocks. Push-pull connectors are out of
>> question for our design. We have had issues with our Q7 devkit with
>> push-pull connector with SD cards slightly smaller or inserted
>> somewhat the wrong way. I can recall also countless of discussions in
>> the early days of the Raspberry Pis where there were a lot of issues
>> related to SD cards.
>>
>> This is basically the mechanism we are using
>> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg
> 
> Please, allow me to interject...  I'm really curious why don't you
> use eMMC chips instead of microSD cards?  I mean, if the reliability
> is of utmost importance, I wouldn't even consider microSD cards, not
> even the high-endurance variants.
> 

We have both :)

Just to name one potential use-case, you may want to save some data on 
SD card for investigation without the need for the system to run to dump 
data from the eMMC. It's there anyway, so now my job as a SW guy is to 
support it :)

Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Dragan Simic]

On 2024-01-26 12:09, Quentin Schulz wrote:
> On 1/26/24 12:04, Dragan Simic wrote:
>> On 2024-01-26 11:37, Quentin Schulz wrote:
>>> On 1/26/24 03:57, Kever Yang wrote:
>>>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>>>> We don't have a dedicated CD pin for the SD card connector.
>>>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807
>>>>> is the SD card connector we use.
>>>> 
>>>> Thanks for your information, but I think you are using the wrong
>>>> microSD connector for rk3588 and maybe also for other rockchip SoCs.
>>>> Here are four microSD card connector from the web you provide, all 
>>>> of
>>>> them have card detect signal available for pcb:
>>>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>>> 
>>> None of those fit our requirements. We need a safe system that 
>>> doesn't
>>> break because of vibrations or shocks. Push-pull connectors are out 
>>> of
>>> question for our design. We have had issues with our Q7 devkit with
>>> push-pull connector with SD cards slightly smaller or inserted
>>> somewhat the wrong way. I can recall also countless of discussions in
>>> the early days of the Raspberry Pis where there were a lot of issues
>>> related to SD cards.
>>> 
>>> This is basically the mechanism we are using
>>> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg
>> 
>> Please, allow me to interject...  I'm really curious why don't you
>> use eMMC chips instead of microSD cards?  I mean, if the reliability
>> is of utmost importance, I wouldn't even consider microSD cards, not
>> even the high-endurance variants.
> 
> We have both :)

Ah, I see. :)  Perhaps my question wasn't precise enough;  actually,
now I'd like to know what do you use as the primary storage for the
operating system installation -- eMMC chip or microSD cards?  Is the
eMMC chip soldered?  I'm just curious. :)

> Just to name one potential use-case, you may want to save some data on
> SD card for investigation without the need for the system to run to
> dump data from the eMMC. It's there anyway, so now my job as a SW guy
> is to support it :)

Sure, it needs to be supported, no matter what.  The microSD slot is
presumably there to be used as the secondary storage, or to perform
operating system rescue, debugging and similar operations, as needed.

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

On 1/26/24 12:24, Dragan Simic wrote:
> [Some people who received this message don't often get email from 
> dsimic@manjaro.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 2024-01-26 12:09, Quentin Schulz wrote:
>> On 1/26/24 12:04, Dragan Simic wrote:
>>> On 2024-01-26 11:37, Quentin Schulz wrote:
>>>> On 1/26/24 03:57, Kever Yang wrote:
>>>>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>>>>> We don't have a dedicated CD pin for the SD card connector.
>>>>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807
>>>>>> is the SD card connector we use.
>>>>>
>>>>> Thanks for your information, but I think you are using the wrong
>>>>> microSD connector for rk3588 and maybe also for other rockchip SoCs.
>>>>> Here are four microSD card connector from the web you provide, all
>>>>> of
>>>>> them have card detect signal available for pcb:
>>>>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>>>>
>>>> None of those fit our requirements. We need a safe system that
>>>> doesn't
>>>> break because of vibrations or shocks. Push-pull connectors are out
>>>> of
>>>> question for our design. We have had issues with our Q7 devkit with
>>>> push-pull connector with SD cards slightly smaller or inserted
>>>> somewhat the wrong way. I can recall also countless of discussions in
>>>> the early days of the Raspberry Pis where there were a lot of issues
>>>> related to SD cards.
>>>>
>>>> This is basically the mechanism we are using
>>>> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg
>>>
>>> Please, allow me to interject...  I'm really curious why don't you
>>> use eMMC chips instead of microSD cards?  I mean, if the reliability
>>> is of utmost importance, I wouldn't even consider microSD cards, not
>>> even the high-endurance variants.
>>
>> We have both :)
> 
> Ah, I see. :)  Perhaps my question wasn't precise enough;  actually,
> now I'd like to know what do you use as the primary storage for the
> operating system installation -- eMMC chip or microSD cards?  Is the
> eMMC chip soldered?  I'm just curious. :)
> 

Soldered eMMC is the primary (expected) storage. If both eMMC and SD 
card are inserted and properly flashed, it'll boot from eMMC except if 
the BIOS button is pressed, in which case SD card will be selected 
instead. If SD card is missing/improperly flashed, it'll boot into USB 
flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed 
(similar to when no storage media is properly flashed).

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Dragan Simic]

On 2024-01-26 12:29, Quentin Schulz wrote:
> On 1/26/24 12:24, Dragan Simic wrote:
>> On 2024-01-26 12:09, Quentin Schulz wrote:
>>> On 1/26/24 12:04, Dragan Simic wrote:
>>>> On 2024-01-26 11:37, Quentin Schulz wrote:
>>>>> On 1/26/24 03:57, Kever Yang wrote:
>>>>>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>>>>>> We don't have a dedicated CD pin for the SD card connector.
>>>>>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807
>>>>>>> is the SD card connector we use.
>>>>>> 
>>>>>> Thanks for your information, but I think you are using the wrong
>>>>>> microSD connector for rk3588 and maybe also for other rockchip 
>>>>>> SoCs.
>>>>>> Here are four microSD card connector from the web you provide, all
>>>>>> of
>>>>>> them have card detect signal available for pcb:
>>>>>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>>>>> 
>>>>> None of those fit our requirements. We need a safe system that
>>>>> doesn't
>>>>> break because of vibrations or shocks. Push-pull connectors are out
>>>>> of
>>>>> question for our design. We have had issues with our Q7 devkit with
>>>>> push-pull connector with SD cards slightly smaller or inserted
>>>>> somewhat the wrong way. I can recall also countless of discussions 
>>>>> in
>>>>> the early days of the Raspberry Pis where there were a lot of 
>>>>> issues
>>>>> related to SD cards.
>>>>> 
>>>>> This is basically the mechanism we are using
>>>>> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg
>>>> 
>>>> Please, allow me to interject...  I'm really curious why don't you
>>>> use eMMC chips instead of microSD cards?  I mean, if the reliability
>>>> is of utmost importance, I wouldn't even consider microSD cards, not
>>>> even the high-endurance variants.
>>> 
>>> We have both :)
>> 
>> Ah, I see. :)  Perhaps my question wasn't precise enough;  actually,
>> now I'd like to know what do you use as the primary storage for the
>> operating system installation -- eMMC chip or microSD cards?  Is the
>> eMMC chip soldered?  I'm just curious. :)
>> 
> Soldered eMMC is the primary (expected) storage. If both eMMC and SD
> card are inserted and properly flashed, it'll boot from eMMC except if
> the BIOS button is pressed, in which case SD card will be selected
> instead. If SD card is missing/improperly flashed, it'll boot into USB
> flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed
> (similar to when no storage media is properly flashed).

Thanks for the clarification.  Just one more question, please:  is the
BIOS button handled in software (i.e. in U-Boot), or does it disable the
eMMC chip by shorting its clock or a data line to ground?

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

Hi Dragan,

On 1/26/24 12:33, Dragan Simic wrote:
> On 2024-01-26 12:29, Quentin Schulz wrote:
>> On 1/26/24 12:24, Dragan Simic wrote:
>>> On 2024-01-26 12:09, Quentin Schulz wrote:
>>>> On 1/26/24 12:04, Dragan Simic wrote:
>>>>> On 2024-01-26 11:37, Quentin Schulz wrote:
>>>>>> On 1/26/24 03:57, Kever Yang wrote:
>>>>>>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>>>>>>> We don't have a dedicated CD pin for the SD card connector.
>>>>>>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807
>>>>>>>> is the SD card connector we use.
>>>>>>>
>>>>>>> Thanks for your information, but I think you are using the wrong
>>>>>>> microSD connector for rk3588 and maybe also for other rockchip SoCs.
>>>>>>> Here are four microSD card connector from the web you provide, all
>>>>>>> of
>>>>>>> them have card detect signal available for pcb:
>>>>>>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>>>>>>
>>>>>> None of those fit our requirements. We need a safe system that
>>>>>> doesn't
>>>>>> break because of vibrations or shocks. Push-pull connectors are out
>>>>>> of
>>>>>> question for our design. We have had issues with our Q7 devkit with
>>>>>> push-pull connector with SD cards slightly smaller or inserted
>>>>>> somewhat the wrong way. I can recall also countless of discussions in
>>>>>> the early days of the Raspberry Pis where there were a lot of issues
>>>>>> related to SD cards.
>>>>>>
>>>>>> This is basically the mechanism we are using
>>>>>> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg
>>>>>
>>>>> Please, allow me to interject...  I'm really curious why don't you
>>>>> use eMMC chips instead of microSD cards?  I mean, if the reliability
>>>>> is of utmost importance, I wouldn't even consider microSD cards, not
>>>>> even the high-endurance variants.
>>>>
>>>> We have both :)
>>>
>>> Ah, I see. :)  Perhaps my question wasn't precise enough;  actually,
>>> now I'd like to know what do you use as the primary storage for the
>>> operating system installation -- eMMC chip or microSD cards?  Is the
>>> eMMC chip soldered?  I'm just curious. :)
>>>
>> Soldered eMMC is the primary (expected) storage. If both eMMC and SD
>> card are inserted and properly flashed, it'll boot from eMMC except if
>> the BIOS button is pressed, in which case SD card will be selected
>> instead. If SD card is missing/improperly flashed, it'll boot into USB
>> flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed
>> (similar to when no storage media is properly flashed).
> 
> Thanks for the clarification.  Just one more question, please:  is the
> BIOS button handled in software (i.e. in U-Boot), or does it disable the
> eMMC chip by shorting its clock or a data line to ground?

None of those options :)

On RK3588, the boot media selection and order is done via the channel 0 
of the SARADC. So a specific voltage is provided to boot from eMMC or 
from SD card.

Quentin

Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

[Dragan Simic]

On 2024-01-26 14:46, Quentin Schulz wrote:
> On 1/26/24 12:33, Dragan Simic wrote:
>> On 2024-01-26 12:29, Quentin Schulz wrote:
>>> On 1/26/24 12:24, Dragan Simic wrote:
>>>> On 2024-01-26 12:09, Quentin Schulz wrote:
>>>>> On 1/26/24 12:04, Dragan Simic wrote:
>>>>>> On 2024-01-26 11:37, Quentin Schulz wrote:
>>>>>>> On 1/26/24 03:57, Kever Yang wrote:
>>>>>>>> On 2024/1/25 19:02, Quentin Schulz wrote:
>>>>>>>>> We don't have a dedicated CD pin for the SD card connector.
>>>>>>>>> https://www.digikey.com/en/products/detail/molex/0472192001/3044807
>>>>>>>>> is the SD card connector we use.
>>>>>>>> 
>>>>>>>> Thanks for your information, but I think you are using the wrong
>>>>>>>> microSD connector for rk3588 and maybe also for other rockchip 
>>>>>>>> SoCs.
>>>>>>>> Here are four microSD card connector from the web you provide, 
>>>>>>>> all
>>>>>>>> of
>>>>>>>> them have card detect signal available for pcb:
>>>>>>>> https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-card-connectors
>>>>>>> 
>>>>>>> None of those fit our requirements. We need a safe system that
>>>>>>> doesn't
>>>>>>> break because of vibrations or shocks. Push-pull connectors are 
>>>>>>> out
>>>>>>> of
>>>>>>> question for our design. We have had issues with our Q7 devkit 
>>>>>>> with
>>>>>>> push-pull connector with SD cards slightly smaller or inserted
>>>>>>> somewhat the wrong way. I can recall also countless of 
>>>>>>> discussions in
>>>>>>> the early days of the Raspberry Pis where there were a lot of 
>>>>>>> issues
>>>>>>> related to SD cards.
>>>>>>> 
>>>>>>> This is basically the mechanism we are using
>>>>>>> https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-500901-0801-30161714-01.jpg
>>>>>> 
>>>>>> Please, allow me to interject...  I'm really curious why don't you
>>>>>> use eMMC chips instead of microSD cards?  I mean, if the 
>>>>>> reliability
>>>>>> is of utmost importance, I wouldn't even consider microSD cards, 
>>>>>> not
>>>>>> even the high-endurance variants.
>>>>> 
>>>>> We have both :)
>>>> 
>>>> Ah, I see. :)  Perhaps my question wasn't precise enough;  actually,
>>>> now I'd like to know what do you use as the primary storage for the
>>>> operating system installation -- eMMC chip or microSD cards?  Is the
>>>> eMMC chip soldered?  I'm just curious. :)
>>>> 
>>> Soldered eMMC is the primary (expected) storage. If both eMMC and SD
>>> card are inserted and properly flashed, it'll boot from eMMC except 
>>> if
>>> the BIOS button is pressed, in which case SD card will be selected
>>> instead. If SD card is missing/improperly flashed, it'll boot into 
>>> USB
>>> flashing mode (rkdeveloptool/rockusb) if the BIOS button is pressed
>>> (similar to when no storage media is properly flashed).
>> 
>> Thanks for the clarification.  Just one more question, please:  is the
>> BIOS button handled in software (i.e. in U-Boot), or does it disable 
>> the
>> eMMC chip by shorting its clock or a data line to ground?
> 
> None of those options :)
> 
> On RK3588, the boot media selection and order is done via the channel
> 0 of the SARADC. So a specific voltage is provided to boot from eMMC
> or from SD card.

Ah, it's nice to see that RK3588 feature actually used.  Thanks for
the clarification!

[PATCH 14/18] rockchip: rk3588: add constants for some register address spaces

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

It's one thing to have the register mapped via a well-defined struct but
it's another to be able to make use of it. For that to happen, one needs
to cast the physical address memory of the beginning of the register
address space with the struct. Since this cannot change, let's hardcode
it in the include files so that users do not need to duplicate this line
of code in their own implementation.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/include/asm/arch-rockchip/cru_rk3588.h | 2 ++
 arch/arm/include/asm/arch-rockchip/ioc_rk3588.h | 6 ++++++
 arch/arm/mach-rockchip/rk3588/rk3588.c          | 4 ----
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
index 7f4a9085392..a4507e5fdd7 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
@@ -63,6 +63,8 @@ struct rk3588_pll {
 	unsigned int reserved0[3];
 };
 
+#define CRU_BASE	0xfd7c0000
+
 struct rk3588_cru {
 	struct rk3588_pll pll[18];
 	unsigned int reserved0[16];/* Address Offset: 0x0240 */
diff --git a/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h b/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
index 5a656f850c7..7ad98466c39 100644
--- a/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
@@ -5,6 +5,8 @@
 #ifndef _ASM_ARCH_IOC_RK3588_H
 #define _ASM_ARCH_IOC_RK3588_H
 
+#define BUS_IOC_BASE	0xfd5f8000
+
 struct rk3588_bus_ioc {
 	unsigned int reserved0000[3];      /* Address Offset: 0x0000 */
 	unsigned int gpio0b_iomux_sel_h;   /* Address Offset: 0x000C */
@@ -48,6 +50,8 @@ struct rk3588_bus_ioc {
 
 check_member(rk3588_bus_ioc, gpio4d_iomux_sel_h, 0x009C);
 
+#define PMU1_IOC_BASE	0xfd5f0000
+
 struct rk3588_pmu1_ioc {
 	unsigned int gpio0a_iomux_sel_l;   /* Address Offset: 0x0000 */
 	unsigned int gpio0a_iomux_sel_h;   /* Address Offset: 0x0004 */
@@ -70,6 +74,8 @@ struct rk3588_pmu1_ioc {
 
 check_member(rk3588_pmu1_ioc, xin_con, 0x0040);
 
+#define PMU2_IOC_BASE	0xfd5f4000
+
 struct rk3588_pmu2_ioc {
 	unsigned int gpio0b_iomux_sel_h;  /* Address Offset: 0x0000 */
 	unsigned int gpio0c_iomux_sel_l;  /* Address Offset: 0x0004 */
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c b/arch/arm/mach-rockchip/rk3588/rk3588.c
index c5eeda9d751..53ee9f1cebc 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -26,10 +26,6 @@
 #define FW_SYSM_MST26_REG		0xa8
 #define FW_SYSM_MST27_REG		0xac
 
-#define PMU1_IOC_BASE			0xfd5f0000
-#define PMU2_IOC_BASE			0xfd5f4000
-
-#define BUS_IOC_BASE			0xfd5f8000
 #define BUS_IOC_GPIO2A_IOMUX_SEL_L	0x40
 #define BUS_IOC_GPIO2B_IOMUX_SEL_L	0x48
 #define BUS_IOC_GPIO2D_IOMUX_SEL_L	0x58

-- 
2.43.0

Re: [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> It's one thing to have the register mapped via a well-defined struct but
> it's another to be able to make use of it. For that to happen, one needs
> to cast the physical address memory of the beginning of the register
> address space with the struct. Since this cannot change, let's hardcode
> it in the include files so that users do not need to duplicate this line
> of code in their own implementation.
Usually only one place using these base address when the dts is not 
using, so it's not a
big issue to define at where it's used.


Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever

>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>   arch/arm/include/asm/arch-rockchip/cru_rk3588.h | 2 ++
>   arch/arm/include/asm/arch-rockchip/ioc_rk3588.h | 6 ++++++
>   arch/arm/mach-rockchip/rk3588/rk3588.c          | 4 ----
>   3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
> index 7f4a9085392..a4507e5fdd7 100644
> --- a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
> +++ b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
> @@ -63,6 +63,8 @@ struct rk3588_pll {
>   	unsigned int reserved0[3];
>   };
>   
> +#define CRU_BASE	0xfd7c0000
> +
>   struct rk3588_cru {
>   	struct rk3588_pll pll[18];
>   	unsigned int reserved0[16];/* Address Offset: 0x0240 */
> diff --git a/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h b/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
> index 5a656f850c7..7ad98466c39 100644
> --- a/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
> +++ b/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
> @@ -5,6 +5,8 @@
>   #ifndef _ASM_ARCH_IOC_RK3588_H
>   #define _ASM_ARCH_IOC_RK3588_H
>   
> +#define BUS_IOC_BASE	0xfd5f8000
> +
>   struct rk3588_bus_ioc {
>   	unsigned int reserved0000[3];      /* Address Offset: 0x0000 */
>   	unsigned int gpio0b_iomux_sel_h;   /* Address Offset: 0x000C */
> @@ -48,6 +50,8 @@ struct rk3588_bus_ioc {
>   
>   check_member(rk3588_bus_ioc, gpio4d_iomux_sel_h, 0x009C);
>   
> +#define PMU1_IOC_BASE	0xfd5f0000
> +
>   struct rk3588_pmu1_ioc {
>   	unsigned int gpio0a_iomux_sel_l;   /* Address Offset: 0x0000 */
>   	unsigned int gpio0a_iomux_sel_h;   /* Address Offset: 0x0004 */
> @@ -70,6 +74,8 @@ struct rk3588_pmu1_ioc {
>   
>   check_member(rk3588_pmu1_ioc, xin_con, 0x0040);
>   
> +#define PMU2_IOC_BASE	0xfd5f4000
> +
>   struct rk3588_pmu2_ioc {
>   	unsigned int gpio0b_iomux_sel_h;  /* Address Offset: 0x0000 */
>   	unsigned int gpio0c_iomux_sel_l;  /* Address Offset: 0x0004 */
> diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c b/arch/arm/mach-rockchip/rk3588/rk3588.c
> index c5eeda9d751..53ee9f1cebc 100644
> --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
> +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
> @@ -26,10 +26,6 @@
>   #define FW_SYSM_MST26_REG		0xa8
>   #define FW_SYSM_MST27_REG		0xac
>   
> -#define PMU1_IOC_BASE			0xfd5f0000
> -#define PMU2_IOC_BASE			0xfd5f4000
> -
> -#define BUS_IOC_BASE			0xfd5f8000
>   #define BUS_IOC_GPIO2A_IOMUX_SEL_L	0x40
>   #define BUS_IOC_GPIO2B_IOMUX_SEL_L	0x48
>   #define BUS_IOC_GPIO2D_IOMUX_SEL_L	0x58
>

[PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Nothing of the hardware.h is used in include/configs, therefore, let's
move that include to the files that actually require this include.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/mach-rockchip/rk3066/rk3066.c | 1 +
 drivers/ram/rockchip/dmc-rk3368.c      | 1 +
 drivers/ram/rockchip/sdram_rk3188.c    | 1 +
 drivers/ram/rockchip/sdram_rk3288.c    | 1 +
 include/configs/rk3036_common.h        | 1 -
 include/configs/rk3066_common.h        | 1 -
 include/configs/rk3188_common.h        | 1 -
 include/configs/rk322x_common.h        | 1 -
 include/configs/rk3288_common.h        | 1 -
 include/configs/rk3368_common.h        | 1 -
 include/configs/rv1108_common.h        | 1 -
 11 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3066/rk3066.c b/arch/arm/mach-rockchip/rk3066/rk3066.c
index 78c7d894f90..6661b788295 100644
--- a/arch/arm/mach-rockchip/rk3066/rk3066.c
+++ b/arch/arm/mach-rockchip/rk3066/rk3066.c
@@ -7,6 +7,7 @@
 #include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/grf_rk3066.h>
+#include <asm/arch-rockchip/hardware.h>
 
 #define GRF_BASE	0x20008000
 
diff --git a/drivers/ram/rockchip/dmc-rk3368.c b/drivers/ram/rockchip/dmc-rk3368.c
index f36be941a38..74d8aed571c 100644
--- a/drivers/ram/rockchip/dmc-rk3368.c
+++ b/drivers/ram/rockchip/dmc-rk3368.c
@@ -20,6 +20,7 @@
 #include <asm/arch-rockchip/ddr_rk3368.h>
 #include <asm/arch-rockchip/sdram.h>
 #include <asm/arch-rockchip/sdram_rk3288.h>
+#include <asm/arch-rockchip/hardware.h>
 #include <linux/bitops.h>
 #include <linux/delay.h>
 #include <linux/err.h>
diff --git a/drivers/ram/rockchip/sdram_rk3188.c b/drivers/ram/rockchip/sdram_rk3188.c
index ad9f936df55..16a68885f1f 100644
--- a/drivers/ram/rockchip/sdram_rk3188.c
+++ b/drivers/ram/rockchip/sdram_rk3188.c
@@ -25,6 +25,7 @@
 #include <asm/arch-rockchip/pmu_rk3188.h>
 #include <asm/arch-rockchip/sdram.h>
 #include <asm/arch-rockchip/sdram_rk3288.h>
+#include <asm/arch-rockchip/hardware.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 
diff --git a/drivers/ram/rockchip/sdram_rk3288.c b/drivers/ram/rockchip/sdram_rk3288.c
index c99118fd612..ec6bdcb2015 100644
--- a/drivers/ram/rockchip/sdram_rk3288.c
+++ b/drivers/ram/rockchip/sdram_rk3288.c
@@ -25,6 +25,7 @@
 #include <asm/arch-rockchip/pmu_rk3288.h>
 #include <asm/arch-rockchip/sdram.h>
 #include <asm/arch-rockchip/sdram_rk3288.h>
+#include <asm/arch-rockchip/hardware.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <power/regulator.h>
diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h
index c2abd14e114..0bf9e8b9a2e 100644
--- a/include/configs/rk3036_common.h
+++ b/include/configs/rk3036_common.h
@@ -5,7 +5,6 @@
 #ifndef __CONFIG_RK3036_COMMON_H
 #define __CONFIG_RK3036_COMMON_H
 
-#include <asm/arch-rockchip/hardware.h>
 #include "rockchip-common.h"
 
 #define CFG_SYS_HZ_CLOCK		24000000
diff --git a/include/configs/rk3066_common.h b/include/configs/rk3066_common.h
index d70c8f77d48..6a3b6900463 100644
--- a/include/configs/rk3066_common.h
+++ b/include/configs/rk3066_common.h
@@ -6,7 +6,6 @@
 #ifndef __CONFIG_RK3066_COMMON_H
 #define __CONFIG_RK3066_COMMON_H
 
-#include <asm/arch-rockchip/hardware.h>
 #include "rockchip-common.h"
 
 #define CFG_IRAM_BASE		0x10080000
diff --git a/include/configs/rk3188_common.h b/include/configs/rk3188_common.h
index a8cee1e44d4..98f2c25f3cf 100644
--- a/include/configs/rk3188_common.h
+++ b/include/configs/rk3188_common.h
@@ -6,7 +6,6 @@
 #ifndef __CONFIG_RK3188_COMMON_H
 #define __CONFIG_RK3188_COMMON_H
 
-#include <asm/arch-rockchip/hardware.h>
 #include "rockchip-common.h"
 
 #define CFG_IRAM_BASE	0x10080000
diff --git a/include/configs/rk322x_common.h b/include/configs/rk322x_common.h
index 15f77df3e17..bab4ca015f7 100644
--- a/include/configs/rk322x_common.h
+++ b/include/configs/rk322x_common.h
@@ -5,7 +5,6 @@
 #ifndef __CONFIG_RK322X_COMMON_H
 #define __CONFIG_RK322X_COMMON_H
 
-#include <asm/arch-rockchip/hardware.h>
 #include "rockchip-common.h"
 
 #define CFG_SYS_HZ_CLOCK		24000000
diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 3063076a97a..0c449e31099 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -6,7 +6,6 @@
 #ifndef __CONFIG_RK3288_COMMON_H
 #define __CONFIG_RK3288_COMMON_H
 
-#include <asm/arch-rockchip/hardware.h>
 #include "rockchip-common.h"
 
 #define CFG_SYS_HZ_CLOCK		24000000
diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
index ccb5369b901..d488f8d477a 100644
--- a/include/configs/rk3368_common.h
+++ b/include/configs/rk3368_common.h
@@ -8,7 +8,6 @@
 
 #include "rockchip-common.h"
 
-#include <asm/arch-rockchip/hardware.h>
 #include <linux/sizes.h>
 
 #define CFG_SYS_SDRAM_BASE		0
diff --git a/include/configs/rv1108_common.h b/include/configs/rv1108_common.h
index 3bf70a0e0ae..ff28236a21d 100644
--- a/include/configs/rv1108_common.h
+++ b/include/configs/rv1108_common.h
@@ -5,7 +5,6 @@
 #ifndef __CONFIG_RV1108_COMMON_H
 #define __CONFIG_RV1108_COMMON_H
 
-#include <asm/arch-rockchip/hardware.h>
 #include "rockchip-common.h"
 
 #define CFG_IRAM_BASE		0x10080000

-- 
2.43.0

Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files

[Kever Yang]

Hi Quentin,

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Nothing of the hardware.h is used in include/configs, therefore, let's
> move that include to the files that actually require this include.

hardware.h is one of common header for soc level, it's reasonable in the 
soc_common.h.

Thanks,

- Kever

>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>   arch/arm/mach-rockchip/rk3066/rk3066.c | 1 +
>   drivers/ram/rockchip/dmc-rk3368.c      | 1 +
>   drivers/ram/rockchip/sdram_rk3188.c    | 1 +
>   drivers/ram/rockchip/sdram_rk3288.c    | 1 +
>   include/configs/rk3036_common.h        | 1 -
>   include/configs/rk3066_common.h        | 1 -
>   include/configs/rk3188_common.h        | 1 -
>   include/configs/rk322x_common.h        | 1 -
>   include/configs/rk3288_common.h        | 1 -
>   include/configs/rk3368_common.h        | 1 -
>   include/configs/rv1108_common.h        | 1 -
>   11 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3066/rk3066.c b/arch/arm/mach-rockchip/rk3066/rk3066.c
> index 78c7d894f90..6661b788295 100644
> --- a/arch/arm/mach-rockchip/rk3066/rk3066.c
> +++ b/arch/arm/mach-rockchip/rk3066/rk3066.c
> @@ -7,6 +7,7 @@
>   #include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/grf_rk3066.h>
> +#include <asm/arch-rockchip/hardware.h>
>   
>   #define GRF_BASE	0x20008000
>   
> diff --git a/drivers/ram/rockchip/dmc-rk3368.c b/drivers/ram/rockchip/dmc-rk3368.c
> index f36be941a38..74d8aed571c 100644
> --- a/drivers/ram/rockchip/dmc-rk3368.c
> +++ b/drivers/ram/rockchip/dmc-rk3368.c
> @@ -20,6 +20,7 @@
>   #include <asm/arch-rockchip/ddr_rk3368.h>
>   #include <asm/arch-rockchip/sdram.h>
>   #include <asm/arch-rockchip/sdram_rk3288.h>
> +#include <asm/arch-rockchip/hardware.h>
>   #include <linux/bitops.h>
>   #include <linux/delay.h>
>   #include <linux/err.h>
> diff --git a/drivers/ram/rockchip/sdram_rk3188.c b/drivers/ram/rockchip/sdram_rk3188.c
> index ad9f936df55..16a68885f1f 100644
> --- a/drivers/ram/rockchip/sdram_rk3188.c
> +++ b/drivers/ram/rockchip/sdram_rk3188.c
> @@ -25,6 +25,7 @@
>   #include <asm/arch-rockchip/pmu_rk3188.h>
>   #include <asm/arch-rockchip/sdram.h>
>   #include <asm/arch-rockchip/sdram_rk3288.h>
> +#include <asm/arch-rockchip/hardware.h>
>   #include <linux/delay.h>
>   #include <linux/err.h>
>   
> diff --git a/drivers/ram/rockchip/sdram_rk3288.c b/drivers/ram/rockchip/sdram_rk3288.c
> index c99118fd612..ec6bdcb2015 100644
> --- a/drivers/ram/rockchip/sdram_rk3288.c
> +++ b/drivers/ram/rockchip/sdram_rk3288.c
> @@ -25,6 +25,7 @@
>   #include <asm/arch-rockchip/pmu_rk3288.h>
>   #include <asm/arch-rockchip/sdram.h>
>   #include <asm/arch-rockchip/sdram_rk3288.h>
> +#include <asm/arch-rockchip/hardware.h>
>   #include <linux/delay.h>
>   #include <linux/err.h>
>   #include <power/regulator.h>
> diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h
> index c2abd14e114..0bf9e8b9a2e 100644
> --- a/include/configs/rk3036_common.h
> +++ b/include/configs/rk3036_common.h
> @@ -5,7 +5,6 @@
>   #ifndef __CONFIG_RK3036_COMMON_H
>   #define __CONFIG_RK3036_COMMON_H
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include "rockchip-common.h"
>   
>   #define CFG_SYS_HZ_CLOCK		24000000
> diff --git a/include/configs/rk3066_common.h b/include/configs/rk3066_common.h
> index d70c8f77d48..6a3b6900463 100644
> --- a/include/configs/rk3066_common.h
> +++ b/include/configs/rk3066_common.h
> @@ -6,7 +6,6 @@
>   #ifndef __CONFIG_RK3066_COMMON_H
>   #define __CONFIG_RK3066_COMMON_H
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include "rockchip-common.h"
>   
>   #define CFG_IRAM_BASE		0x10080000
> diff --git a/include/configs/rk3188_common.h b/include/configs/rk3188_common.h
> index a8cee1e44d4..98f2c25f3cf 100644
> --- a/include/configs/rk3188_common.h
> +++ b/include/configs/rk3188_common.h
> @@ -6,7 +6,6 @@
>   #ifndef __CONFIG_RK3188_COMMON_H
>   #define __CONFIG_RK3188_COMMON_H
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include "rockchip-common.h"
>   
>   #define CFG_IRAM_BASE	0x10080000
> diff --git a/include/configs/rk322x_common.h b/include/configs/rk322x_common.h
> index 15f77df3e17..bab4ca015f7 100644
> --- a/include/configs/rk322x_common.h
> +++ b/include/configs/rk322x_common.h
> @@ -5,7 +5,6 @@
>   #ifndef __CONFIG_RK322X_COMMON_H
>   #define __CONFIG_RK322X_COMMON_H
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include "rockchip-common.h"
>   
>   #define CFG_SYS_HZ_CLOCK		24000000
> diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
> index 3063076a97a..0c449e31099 100644
> --- a/include/configs/rk3288_common.h
> +++ b/include/configs/rk3288_common.h
> @@ -6,7 +6,6 @@
>   #ifndef __CONFIG_RK3288_COMMON_H
>   #define __CONFIG_RK3288_COMMON_H
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include "rockchip-common.h"
>   
>   #define CFG_SYS_HZ_CLOCK		24000000
> diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h
> index ccb5369b901..d488f8d477a 100644
> --- a/include/configs/rk3368_common.h
> +++ b/include/configs/rk3368_common.h
> @@ -8,7 +8,6 @@
>   
>   #include "rockchip-common.h"
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include <linux/sizes.h>
>   
>   #define CFG_SYS_SDRAM_BASE		0
> diff --git a/include/configs/rv1108_common.h b/include/configs/rv1108_common.h
> index 3bf70a0e0ae..ff28236a21d 100644
> --- a/include/configs/rv1108_common.h
> +++ b/include/configs/rv1108_common.h
> @@ -5,7 +5,6 @@
>   #ifndef __CONFIG_RV1108_COMMON_H
>   #define __CONFIG_RV1108_COMMON_H
>   
> -#include <asm/arch-rockchip/hardware.h>
>   #include "rockchip-common.h"
>   
>   #define CFG_IRAM_BASE		0x10080000
>

Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files

[Quentin Schulz]

Hi Kever,

On 1/24/24 11:46, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/23 22:49, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> Nothing of the hardware.h is used in include/configs, therefore, let's
>> move that include to the files that actually require this include.
> 
> hardware.h is one of common header for soc level, it's reasonable in the 
> soc_common.h.
> 

hardware.h is only defining macros which are "wrappers" around writel().

writel() is NOT available in hardware.h, we need to include <asm/io.h>. 
Which means someone who wants to use the wrappers defined in hardware.h 
also needs to include the <asm/io.h> header, which doesn't make much sense.

Why this is done is because if I include <asm/io.h> in hardware.h but do 
not remove hardware.h from the SoC configs header files, some boards 
stop compiling in arch/arm/cpu/armv8/u-boot.lds with a non-existing 
ALIGN signature (expects two arguments instead of 1). I assume this is 
because there's an ALIGN macro somewhere in asm/io.h that redefines the 
ALIGN assembly directive (c.f. 
https://developer.arm.com/documentation/dui0473/m/directives-reference/align) 
and that u-boot.lds somehow includes the SoC config header file (because 
IIRC this is also included in the autogenerated include/config.h which 
is included by "everything" ?)

Basically, if I don't do that, then I need to manually add <asm/io.h> to 
any file that also include <asm/mach-rockchip/hardware.h>, which isn't 
really nice (but doable, we've done this until now).

If you still prefer to keep hardware.h include in the SoC config header 
file, then lemme know and I'll drop the hardware.h and io.h patches from 
that patch series.

Cheers,
Quentin

Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files

[Kever Yang]

On 2024/1/24 19:12, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/24/24 11:46, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>
>>> Nothing of the hardware.h is used in include/configs, therefore, let's
>>> move that include to the files that actually require this include.
>>
>> hardware.h is one of common header for soc level, it's reasonable in 
>> the soc_common.h.
>>
>
> hardware.h is only defining macros which are "wrappers" around writel().
>
> writel() is NOT available in hardware.h, we need to include 
> <asm/io.h>. Which means someone who wants to use the wrappers defined 
> in hardware.h also needs to include the <asm/io.h> header, which 
> doesn't make much sense.
>
> Why this is done is because if I include <asm/io.h> in hardware.h but 
> do not remove hardware.h from the SoC configs header files, some 
> boards stop compiling in arch/arm/cpu/armv8/u-boot.lds with a 
> non-existing ALIGN signature (expects two arguments instead of 1). I 
> assume this is because there's an ALIGN macro somewhere in asm/io.h 
> that redefines the ALIGN assembly directive (c.f. 
> https://developer.arm.com/documentation/dui0473/m/directives-reference/align) 
> and that u-boot.lds somehow includes the SoC config header file 
> (because IIRC this is also included in the autogenerated 
> include/config.h which is included by "everything" ?)
>
> Basically, if I don't do that, then I need to manually add <asm/io.h> 
> to any file that also include <asm/mach-rockchip/hardware.h>, which 
> isn't really nice (but doable, we've done this until now).

Yes,  you are right.

This hardware.h is already there for the very beginning of the first 
rockchip soc support.

It's reasonable if all the soc related header file and its dependent 
header all included, but it's all around different files now.

So I will take this patch.


Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever

>
> If you still prefer to keep hardware.h include in the SoC config 
> header file, then lemme know and I'll drop the hardware.h and io.h 
> patches from that patch series.
>
> Cheers,
> Quentin

[PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

The different macros use writel which is defined in asm/io.h, so let's
include the header so users of hardware.h do not need to include
asm/io.h as well.

While at it, remove asm/io.h includes wherever
asm/arch-rockchip/hardware.h is included already.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/include/asm/arch-rockchip/hardware.h            | 2 ++
 arch/arm/mach-rockchip/cpu-info.c                        | 1 -
 arch/arm/mach-rockchip/px30/px30.c                       | 1 -
 arch/arm/mach-rockchip/rk3036/rk3036.c                   | 1 -
 arch/arm/mach-rockchip/rk3036/sdram_rk3036.c             | 1 -
 arch/arm/mach-rockchip/rk3066/rk3066.c                   | 1 -
 arch/arm/mach-rockchip/rk3188/rk3188.c                   | 1 -
 arch/arm/mach-rockchip/rk322x/rk322x.c                   | 1 -
 arch/arm/mach-rockchip/rk3288/rk3288.c                   | 1 -
 arch/arm/mach-rockchip/rk3308/rk3308.c                   | 1 -
 arch/arm/mach-rockchip/rk3328/rk3328.c                   | 1 -
 arch/arm/mach-rockchip/rk3368/rk3368.c                   | 1 -
 arch/arm/mach-rockchip/rk3399/rk3399.c                   | 1 -
 arch/arm/mach-rockchip/rk3568/rk3568.c                   | 1 -
 arch/arm/mach-rockchip/rk3588/rk3588.c                   | 1 -
 arch/arm/mach-rockchip/rv1126/rv1126.c                   | 1 -
 board/elgin/elgin_rv1108/elgin_rv1108.c                  | 1 -
 board/firefly/firefly-rk3308/roc_cc_rk3308.c             | 1 -
 board/google/gru/gru.c                                   | 1 -
 board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c   | 1 -
 board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c | 1 -
 board/pine64/rockpro64_rk3399/rockpro64-rk3399.c         | 1 -
 board/rockchip/evb_rv1108/evb_rv1108.c                   | 1 -
 board/theobroma-systems/puma_rk3399/puma-rk3399.c        | 1 -
 board/vamrs/rock960_rk3399/rock960-rk3399.c              | 1 -
 drivers/clk/rockchip/clk_pll.c                           | 1 -
 drivers/clk/rockchip/clk_px30.c                          | 1 -
 drivers/clk/rockchip/clk_rk3036.c                        | 1 -
 drivers/clk/rockchip/clk_rk3066.c                        | 1 -
 drivers/clk/rockchip/clk_rk3128.c                        | 1 -
 drivers/clk/rockchip/clk_rk3188.c                        | 1 -
 drivers/clk/rockchip/clk_rk322x.c                        | 1 -
 drivers/clk/rockchip/clk_rk3288.c                        | 1 -
 drivers/clk/rockchip/clk_rk3308.c                        | 1 -
 drivers/clk/rockchip/clk_rk3328.c                        | 1 -
 drivers/clk/rockchip/clk_rk3368.c                        | 1 -
 drivers/clk/rockchip/clk_rk3399.c                        | 1 -
 drivers/clk/rockchip/clk_rk3568.c                        | 1 -
 drivers/clk/rockchip/clk_rk3588.c                        | 1 -
 drivers/clk/rockchip/clk_rv1108.c                        | 1 -
 drivers/clk/rockchip/clk_rv1126.c                        | 1 -
 drivers/gpio/rk_gpio.c                                   | 1 -
 drivers/net/gmac_rockchip.c                              | 1 -
 drivers/ram/rockchip/dmc-rk3368.c                        | 1 -
 drivers/ram/rockchip/sdram_px30.c                        | 1 -
 drivers/ram/rockchip/sdram_rk3066.c                      | 1 -
 drivers/ram/rockchip/sdram_rk3188.c                      | 1 -
 drivers/ram/rockchip/sdram_rk322x.c                      | 1 -
 drivers/ram/rockchip/sdram_rk3288.c                      | 1 -
 drivers/ram/rockchip/sdram_rk3399.c                      | 1 -
 drivers/ram/rockchip/sdram_rv1126.c                      | 1 -
 drivers/rng/rockchip_rng.c                               | 1 -
 drivers/sysreset/sysreset_rockchip.c                     | 1 -
 drivers/video/rockchip/dw_mipi_dsi_rockchip.c            | 1 -
 drivers/video/rockchip/rk3288_hdmi.c                     | 1 -
 drivers/video/rockchip/rk3288_mipi.c                     | 1 -
 drivers/video/rockchip/rk3288_vop.c                      | 1 -
 drivers/video/rockchip/rk3399_hdmi.c                     | 1 -
 drivers/video/rockchip/rk3399_mipi.c                     | 1 -
 drivers/video/rockchip/rk3399_vop.c                      | 1 -
 drivers/video/rockchip/rk_edp.c                          | 1 -
 drivers/video/rockchip/rk_hdmi.c                         | 1 -
 drivers/video/rockchip/rk_lvds.c                         | 1 -
 63 files changed, 2 insertions(+), 62 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/hardware.h b/arch/arm/include/asm/arch-rockchip/hardware.h
index 62e8bed8f31..e4662a2d52d 100644
--- a/arch/arm/include/asm/arch-rockchip/hardware.h
+++ b/arch/arm/include/asm/arch-rockchip/hardware.h
@@ -6,6 +6,8 @@
 #ifndef _ASM_ARCH_HARDWARE_H
 #define _ASM_ARCH_HARDWARE_H
 
+#include <asm/io.h>
+
 #define RK_CLRSETBITS(clr, set)		((((clr) | (set)) << 16) | (set))
 #define RK_SETBITS(set)			RK_CLRSETBITS(0, set)
 #define RK_CLRBITS(clr)			RK_CLRSETBITS(clr, 0)
diff --git a/arch/arm/mach-rockchip/cpu-info.c b/arch/arm/mach-rockchip/cpu-info.c
index dac24910e0c..a62ff53c6a0 100644
--- a/arch/arm/mach-rockchip/cpu-info.c
+++ b/arch/arm/mach-rockchip/cpu-info.c
@@ -7,7 +7,6 @@
 #include <common.h>
 #include <env.h>
 #include <init.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/arch/arm/mach-rockchip/px30/px30.c b/arch/arm/mach-rockchip/px30/px30.c
index fc7456e680c..b4f655fa4b3 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -9,7 +9,6 @@
 #include <init.h>
 #include <spl.h>
 #include <asm/armv8/mmu.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/grf_px30.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/arch/arm/mach-rockchip/rk3036/rk3036.c b/arch/arm/mach-rockchip/rk3036/rk3036.c
index 0a072cf03a8..e8130abdd77 100644
--- a/arch/arm/mach-rockchip/rk3036/rk3036.c
+++ b/arch/arm/mach-rockchip/rk3036/rk3036.c
@@ -6,7 +6,6 @@
 #include <common.h>
 #include <init.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/grf_rk3036.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/sdram_rk3036.h>
diff --git a/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c b/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
index fcae65b2e5a..07cd29a33e6 100644
--- a/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
+++ b/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
@@ -4,7 +4,6 @@
  */
 #include <common.h>
 #include <init.h>
-#include <asm/io.h>
 #include <asm/types.h>
 #include <asm/arch-rockchip/cru_rk3036.h>
 #include <asm/arch-rockchip/grf_rk3036.h>
diff --git a/arch/arm/mach-rockchip/rk3066/rk3066.c b/arch/arm/mach-rockchip/rk3066/rk3066.c
index 6661b788295..9a95ff85041 100644
--- a/arch/arm/mach-rockchip/rk3066/rk3066.c
+++ b/arch/arm/mach-rockchip/rk3066/rk3066.c
@@ -4,7 +4,6 @@
  */
 
 #include <common.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/grf_rk3066.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c b/arch/arm/mach-rockchip/rk3188/rk3188.c
index c807221f33f..ffdcaa49a1e 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -10,7 +10,6 @@
 #include <log.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3188.h>
diff --git a/arch/arm/mach-rockchip/rk322x/rk322x.c b/arch/arm/mach-rockchip/rk322x/rk322x.c
index a304795fec6..712c0524266 100644
--- a/arch/arm/mach-rockchip/rk322x/rk322x.c
+++ b/arch/arm/mach-rockchip/rk322x/rk322x.c
@@ -3,7 +3,6 @@
  * (C) Copyright 2019 Rockchip Electronics Co., Ltd
  */
 #include <init.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/grf_rk322x.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c b/arch/arm/mach-rockchip/rk3288/rk3288.c
index 26c7e41cd89..38080aeecc3 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -11,7 +11,6 @@
 #include <malloc.h>
 #include <asm/armv7.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cpu_rk3288.h>
diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c b/arch/arm/mach-rockchip/rk3308/rk3308.c
index 6f121bf1304..27a748327e3 100644
--- a/arch/arm/mach-rockchip/rk3308/rk3308.c
+++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
@@ -5,7 +5,6 @@
 #include <common.h>
 #include <init.h>
 #include <malloc.h>
-#include <asm/io.h>
 #include <asm/arch/grf_rk3308.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c b/arch/arm/mach-rockchip/rk3328/rk3328.c
index b591d38fe41..b8e657e9bf4 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -10,7 +10,6 @@
 #include <asm/arch-rockchip/grf_rk3328.h>
 #include <asm/arch-rockchip/uart.h>
 #include <asm/armv8/mmu.h>
-#include <asm/io.h>
 
 #define CRU_BASE		0xFF440000
 #define GRF_BASE		0xFF100000
diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c b/arch/arm/mach-rockchip/rk3368/rk3368.c
index d009b8758e5..651ba109020 100644
--- a/arch/arm/mach-rockchip/rk3368/rk3368.c
+++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
@@ -8,7 +8,6 @@
 #include <init.h>
 #include <syscon.h>
 #include <asm/armv8/mmu.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3368.h>
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
index a1aa0e3e8b5..7fa1d7c7b7a 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -11,7 +11,6 @@
 #include <spl_gpio.h>
 #include <syscon.h>
 #include <asm/armv8/mmu.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru.h>
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 69ef19cc85a..b30ea04f737 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -6,7 +6,6 @@
 #include <common.h>
 #include <dm.h>
 #include <asm/armv8/mmu.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/grf_rk3568.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 53ee9f1cebc..d9e04ede092 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -7,7 +7,6 @@
 #include <common.h>
 #include <spl.h>
 #include <asm/armv8/mmu.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/ioc_rk3588.h>
diff --git a/arch/arm/mach-rockchip/rv1126/rv1126.c b/arch/arm/mach-rockchip/rv1126/rv1126.c
index b9b898756f7..8589c46f10a 100644
--- a/arch/arm/mach-rockchip/rv1126/rv1126.c
+++ b/arch/arm/mach-rockchip/rv1126/rv1126.c
@@ -5,7 +5,6 @@
  */
 
 #include <common.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/grf_rv1126.h>
diff --git a/board/elgin/elgin_rv1108/elgin_rv1108.c b/board/elgin/elgin_rv1108/elgin_rv1108.c
index eb7a322d847..10398e7f712 100644
--- a/board/elgin/elgin_rv1108/elgin_rv1108.c
+++ b/board/elgin/elgin_rv1108/elgin_rv1108.c
@@ -8,7 +8,6 @@
 #include <init.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rv1108.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/board/firefly/firefly-rk3308/roc_cc_rk3308.c b/board/firefly/firefly-rk3308/roc_cc_rk3308.c
index bdf3cc03dc5..99a52a77116 100644
--- a/board/firefly/firefly-rk3308/roc_cc_rk3308.c
+++ b/board/firefly/firefly-rk3308/roc_cc_rk3308.c
@@ -5,7 +5,6 @@
 
 #include <common.h>
 #include <adc.h>
-#include <asm/io.h>
 #include <asm/arch/grf_rk3308.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <linux/bitops.h>
diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
index ecbf702b035..9cb3a525204 100644
--- a/board/google/gru/gru.c
+++ b/board/google/gru/gru.c
@@ -7,7 +7,6 @@
 #include <dm.h>
 #include <init.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
index 2408a367305..5e758ea6cd9 100644
--- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
+++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
@@ -7,7 +7,6 @@
 #include <common.h>
 #include <dm.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
index de75ee329d8..c9b0d5a061d 100644
--- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
+++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
@@ -8,7 +8,6 @@
 #include <dm.h>
 #include <init.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
index d0a694ead1d..fd78ad60d14 100644
--- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
+++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
@@ -7,7 +7,6 @@
 #include <dm.h>
 #include <init.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/board/rockchip/evb_rv1108/evb_rv1108.c b/board/rockchip/evb_rv1108/evb_rv1108.c
index e6ac598648d..0d7a486bed7 100644
--- a/board/rockchip/evb_rv1108/evb_rv1108.c
+++ b/board/rockchip/evb_rv1108/evb_rv1108.c
@@ -8,7 +8,6 @@
 #include <init.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rv1108.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 98a818b135d..8b998ef4556 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -6,7 +6,6 @@
 #include <dm.h>
 #include <syscon.h>
 #include <dm/pinctrl.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
diff --git a/board/vamrs/rock960_rk3399/rock960-rk3399.c b/board/vamrs/rock960_rk3399/rock960-rk3399.c
index a7fc38d42f8..876be8ed9e1 100644
--- a/board/vamrs/rock960_rk3399/rock960-rk3399.c
+++ b/board/vamrs/rock960_rk3399/rock960-rk3399.c
@@ -5,7 +5,6 @@
 
 #include <common.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_pll.c b/drivers/clk/rockchip/clk_pll.c
index 1bb31b3313b..66f8bb16695 100644
--- a/drivers/clk/rockchip/clk_pll.c
+++ b/drivers/clk/rockchip/clk_pll.c
@@ -8,7 +8,6 @@
 #include <dm.h>
 #include <errno.h>
 #include <log.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <div64.h>
diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c
index 93b76538509..2875c152b20 100644
--- a/drivers/clk/rockchip/clk_px30.c
+++ b/drivers/clk/rockchip/clk_px30.c
@@ -15,7 +15,6 @@
 #include <asm/arch-rockchip/cru_px30.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 #include <dt-bindings/clock/px30-cru.h>
diff --git a/drivers/clk/rockchip/clk_rk3036.c b/drivers/clk/rockchip/clk_rk3036.c
index 6bc6d41ad61..6238b14c29e 100644
--- a/drivers/clk/rockchip/clk_rk3036.c
+++ b/drivers/clk/rockchip/clk_rk3036.c
@@ -10,7 +10,6 @@
 #include <log.h>
 #include <malloc.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3036.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_rk3066.c b/drivers/clk/rockchip/clk_rk3066.c
index 2c12f6e0441..f83335df6db 100644
--- a/drivers/clk/rockchip/clk_rk3066.c
+++ b/drivers/clk/rockchip/clk_rk3066.c
@@ -14,7 +14,6 @@
 #include <malloc.h>
 #include <mapmem.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3066.h>
 #include <asm/arch-rockchip/grf_rk3066.h>
diff --git a/drivers/clk/rockchip/clk_rk3128.c b/drivers/clk/rockchip/clk_rk3128.c
index 13e176cdad1..182754e7052 100644
--- a/drivers/clk/rockchip/clk_rk3128.c
+++ b/drivers/clk/rockchip/clk_rk3128.c
@@ -10,7 +10,6 @@
 #include <log.h>
 #include <malloc.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3128.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_rk3188.c b/drivers/clk/rockchip/clk_rk3188.c
index ebdd1b3f99a..f98b46a0f73 100644
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -13,7 +13,6 @@
 #include <malloc.h>
 #include <mapmem.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3188.h>
 #include <asm/arch-rockchip/grf_rk3188.h>
diff --git a/drivers/clk/rockchip/clk_rk322x.c b/drivers/clk/rockchip/clk_rk322x.c
index 28cdba75758..9371c4f63a4 100644
--- a/drivers/clk/rockchip/clk_rk322x.c
+++ b/drivers/clk/rockchip/clk_rk322x.c
@@ -10,7 +10,6 @@
 #include <log.h>
 #include <malloc.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk322x.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_rk3288.c b/drivers/clk/rockchip/clk_rk3288.c
index e24c32c0a2a..0b7eefad15f 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -15,7 +15,6 @@
 #include <mapmem.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru.h>
 #include <asm/arch-rockchip/grf_rk3288.h>
diff --git a/drivers/clk/rockchip/clk_rk3308.c b/drivers/clk/rockchip/clk_rk3308.c
index d0a3f654466..7755b016111 100644
--- a/drivers/clk/rockchip/clk_rk3308.c
+++ b/drivers/clk/rockchip/clk_rk3308.c
@@ -12,7 +12,6 @@
 #include <malloc.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch/cru_rk3308.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_rk3328.c b/drivers/clk/rockchip/clk_rk3328.c
index ef97381f0ed..cfec1d974ac 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -15,7 +15,6 @@
 #include <asm/arch-rockchip/cru_rk3328.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/grf_rk3328.h>
-#include <asm/io.h>
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 #include <dt-bindings/clock/rk3328-cru.h>
diff --git a/drivers/clk/rockchip/clk_rk3368.c b/drivers/clk/rockchip/clk_rk3368.c
index 3406ff592e1..1c5dfaa3800 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -18,7 +18,6 @@
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3368.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/io.h>
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 #include <dt-bindings/clock/rk3368-cru.h>
diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c
index c37e8a53a26..80f65a237e8 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -14,7 +14,6 @@
 #include <mapmem.h>
 #include <syscon.h>
 #include <bitfield.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_rk3568.c b/drivers/clk/rockchip/clk_rk3568.c
index 68f5bbbb9e5..57ef27dda89 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -13,7 +13,6 @@
 #include <asm/arch-rockchip/cru_rk3568.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/io.h>
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 #include <dt-bindings/clock/rk3568-cru.h>
diff --git a/drivers/clk/rockchip/clk_rk3588.c b/drivers/clk/rockchip/clk_rk3588.c
index a995dd5591d..8f33843179b 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -14,7 +14,6 @@
 #include <asm/arch-rockchip/cru_rk3588.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/io.h>
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 #include <dt-bindings/clock/rockchip,rk3588-cru.h>
diff --git a/drivers/clk/rockchip/clk_rv1108.c b/drivers/clk/rockchip/clk_rv1108.c
index b0c889ae156..fc442f7eebe 100644
--- a/drivers/clk/rockchip/clk_rv1108.c
+++ b/drivers/clk/rockchip/clk_rv1108.c
@@ -13,7 +13,6 @@
 #include <malloc.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rv1108.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/clk/rockchip/clk_rv1126.c b/drivers/clk/rockchip/clk_rv1126.c
index 580c0b1b0cf..cfdfcbdb0f4 100644
--- a/drivers/clk/rockchip/clk_rv1126.c
+++ b/drivers/clk/rockchip/clk_rv1126.c
@@ -16,7 +16,6 @@
 #include <asm/arch-rockchip/grf_rv1126.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <dm/device-internal.h>
-#include <asm/io.h>
 #include <dm/lists.h>
 #include <dt-bindings/clock/rockchip,rv1126-cru.h>
 
diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 4a6ae554bf7..c5e096bb1ad 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -11,7 +11,6 @@
 #include <syscon.h>
 #include <linux/errno.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/gpio.h>
diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 04008d2b198..c1bae3f68bd 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -13,7 +13,6 @@
 #include <phy.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/periph.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/ram/rockchip/dmc-rk3368.c b/drivers/ram/rockchip/dmc-rk3368.c
index 74d8aed571c..c0a60be7f11 100644
--- a/drivers/ram/rockchip/dmc-rk3368.c
+++ b/drivers/ram/rockchip/dmc-rk3368.c
@@ -13,7 +13,6 @@
 #include <ram.h>
 #include <regmap.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3368.h>
 #include <asm/arch-rockchip/grf_rk3368.h>
diff --git a/drivers/ram/rockchip/sdram_px30.c b/drivers/ram/rockchip/sdram_px30.c
index 2728d93be32..21498e89570 100644
--- a/drivers/ram/rockchip/sdram_px30.c
+++ b/drivers/ram/rockchip/sdram_px30.c
@@ -10,7 +10,6 @@
 #include <log.h>
 #include <ram.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_px30.h>
 #include <asm/arch-rockchip/grf_px30.h>
diff --git a/drivers/ram/rockchip/sdram_rk3066.c b/drivers/ram/rockchip/sdram_rk3066.c
index 39c0be56a6e..562cf544c90 100644
--- a/drivers/ram/rockchip/sdram_rk3066.c
+++ b/drivers/ram/rockchip/sdram_rk3066.c
@@ -17,7 +17,6 @@
 #include <ram.h>
 #include <regmap.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3066.h>
 #include <asm/arch-rockchip/ddr_rk3188.h>
diff --git a/drivers/ram/rockchip/sdram_rk3188.c b/drivers/ram/rockchip/sdram_rk3188.c
index 16a68885f1f..f689235b13d 100644
--- a/drivers/ram/rockchip/sdram_rk3188.c
+++ b/drivers/ram/rockchip/sdram_rk3188.c
@@ -17,7 +17,6 @@
 #include <ram.h>
 #include <regmap.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3188.h>
 #include <asm/arch-rockchip/ddr_rk3188.h>
diff --git a/drivers/ram/rockchip/sdram_rk322x.c b/drivers/ram/rockchip/sdram_rk322x.c
index 892766a8b43..5fc23c11193 100644
--- a/drivers/ram/rockchip/sdram_rk322x.c
+++ b/drivers/ram/rockchip/sdram_rk322x.c
@@ -12,7 +12,6 @@
 #include <regmap.h>
 #include <syscon.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk322x.h>
 #include <asm/arch-rockchip/grf_rk322x.h>
diff --git a/drivers/ram/rockchip/sdram_rk3288.c b/drivers/ram/rockchip/sdram_rk3288.c
index ec6bdcb2015..2c1afa93ecf 100644
--- a/drivers/ram/rockchip/sdram_rk3288.c
+++ b/drivers/ram/rockchip/sdram_rk3288.c
@@ -17,7 +17,6 @@
 #include <ram.h>
 #include <regmap.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru.h>
 #include <asm/arch-rockchip/ddr_rk3288.h>
diff --git a/drivers/ram/rockchip/sdram_rk3399.c b/drivers/ram/rockchip/sdram_rk3399.c
index 2bf8d48d25a..02cc4a38cf0 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -14,7 +14,6 @@
 #include <ram.h>
 #include <regmap.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
diff --git a/drivers/ram/rockchip/sdram_rv1126.c b/drivers/ram/rockchip/sdram_rv1126.c
index 9e1376a940f..4377871e092 100644
--- a/drivers/ram/rockchip/sdram_rv1126.c
+++ b/drivers/ram/rockchip/sdram_rv1126.c
@@ -9,7 +9,6 @@
 #include <dm.h>
 #include <ram.h>
 #include <syscon.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/cru_rv1126.h>
diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
index 705b424cf3d..9dec7e45dde 100644
--- a/drivers/rng/rockchip_rng.c
+++ b/drivers/rng/rockchip_rng.c
@@ -3,7 +3,6 @@
  * Copyright (c) 2020 Fuzhou Rockchip Electronics Co., Ltd
  */
 #include <asm/arch-rockchip/hardware.h>
-#include <asm/io.h>
 #include <common.h>
 #include <dm.h>
 #include <linux/bitops.h>
diff --git a/drivers/sysreset/sysreset_rockchip.c b/drivers/sysreset/sysreset_rockchip.c
index 0fc6b683f2b..f353f9b4c79 100644
--- a/drivers/sysreset/sysreset_rockchip.c
+++ b/drivers/sysreset/sysreset_rockchip.c
@@ -7,7 +7,6 @@
 #include <dm.h>
 #include <errno.h>
 #include <sysreset.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/cru_rk3328.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
index 5e75b6ec68c..fb784636e87 100644
--- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
+++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
@@ -27,7 +27,6 @@
 #include <common.h>
 #include <log.h>
 #include <video.h>
-#include <asm/io.h>
 #include <dm/device-internal.h>
 #include <linux/bitops.h>
 #include <linux/time.h>
diff --git a/drivers/video/rockchip/rk3288_hdmi.c b/drivers/video/rockchip/rk3288_hdmi.c
index 327ae787125..9cbe31e9abd 100644
--- a/drivers/video/rockchip/rk3288_hdmi.c
+++ b/drivers/video/rockchip/rk3288_hdmi.c
@@ -14,7 +14,6 @@
 #include <regmap.h>
 #include <syscon.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/grf_rk3288.h>
diff --git a/drivers/video/rockchip/rk3288_mipi.c b/drivers/video/rockchip/rk3288_mipi.c
index c0dffa3cba2..9d42119c826 100644
--- a/drivers/video/rockchip/rk3288_mipi.c
+++ b/drivers/video/rockchip/rk3288_mipi.c
@@ -14,7 +14,6 @@
 #include "rk_mipi.h"
 #include <syscon.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <dm/uclass-internal.h>
 #include <linux/err.h>
 #include <linux/kernel.h>
diff --git a/drivers/video/rockchip/rk3288_vop.c b/drivers/video/rockchip/rk3288_vop.c
index 44f32bb5fa2..a4683852ea0 100644
--- a/drivers/video/rockchip/rk3288_vop.c
+++ b/drivers/video/rockchip/rk3288_vop.c
@@ -12,7 +12,6 @@
 #include <syscon.h>
 #include <video.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3288.h>
 #include <asm/arch-rockchip/hardware.h>
diff --git a/drivers/video/rockchip/rk3399_hdmi.c b/drivers/video/rockchip/rk3399_hdmi.c
index 3041360c6ed..5f3f5d26886 100644
--- a/drivers/video/rockchip/rk3399_hdmi.c
+++ b/drivers/video/rockchip/rk3399_hdmi.c
@@ -12,7 +12,6 @@
 #include <regmap.h>
 #include <syscon.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
diff --git a/drivers/video/rockchip/rk3399_mipi.c b/drivers/video/rockchip/rk3399_mipi.c
index 7fc79ba9045..b62d8086674 100644
--- a/drivers/video/rockchip/rk3399_mipi.c
+++ b/drivers/video/rockchip/rk3399_mipi.c
@@ -14,7 +14,6 @@
 #include "rk_mipi.h"
 #include <syscon.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <dm/uclass-internal.h>
 #include <linux/err.h>
 #include <linux/kernel.h>
diff --git a/drivers/video/rockchip/rk3399_vop.c b/drivers/video/rockchip/rk3399_vop.c
index a34b491058f..cb589c7537e 100644
--- a/drivers/video/rockchip/rk3399_vop.c
+++ b/drivers/video/rockchip/rk3399_vop.c
@@ -13,7 +13,6 @@
 #include <video.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/global_data.h>
-#include <asm/io.h>
 #include "rk_vop.h"
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c
index 3697d582510..67bfa788367 100644
--- a/drivers/video/rockchip/rk_edp.c
+++ b/drivers/video/rockchip/rk_edp.c
@@ -17,7 +17,6 @@
 #include <reset.h>
 #include <syscon.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include <asm/arch-rockchip/edp_rk3288.h>
diff --git a/drivers/video/rockchip/rk_hdmi.c b/drivers/video/rockchip/rk_hdmi.c
index 8dcd4d59645..044a29ee47a 100644
--- a/drivers/video/rockchip/rk_hdmi.c
+++ b/drivers/video/rockchip/rk_hdmi.c
@@ -15,7 +15,6 @@
 #include <regmap.h>
 #include <syscon.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/hardware.h>
 #include "rk_hdmi.h"
diff --git a/drivers/video/rockchip/rk_lvds.c b/drivers/video/rockchip/rk_lvds.c
index 9cf3e3ca768..d0a015e31ee 100644
--- a/drivers/video/rockchip/rk_lvds.c
+++ b/drivers/video/rockchip/rk_lvds.c
@@ -13,7 +13,6 @@
 #include <syscon.h>
 #include <asm/global_data.h>
 #include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch-rockchip/clock.h>
 #include <asm/arch-rockchip/grf_rk3288.h>
 #include <asm/arch-rockchip/hardware.h>

-- 
2.43.0

Re: [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> The different macros use writel which is defined in asm/io.h, so let's
> include the header so users of hardware.h do not need to include
> asm/io.h as well.
>
> While at it, remove asm/io.h includes wherever
> asm/arch-rockchip/hardware.h is included already.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/include/asm/arch-rockchip/hardware.h            | 2 ++
>   arch/arm/mach-rockchip/cpu-info.c                        | 1 -
>   arch/arm/mach-rockchip/px30/px30.c                       | 1 -
>   arch/arm/mach-rockchip/rk3036/rk3036.c                   | 1 -
>   arch/arm/mach-rockchip/rk3036/sdram_rk3036.c             | 1 -
>   arch/arm/mach-rockchip/rk3066/rk3066.c                   | 1 -
>   arch/arm/mach-rockchip/rk3188/rk3188.c                   | 1 -
>   arch/arm/mach-rockchip/rk322x/rk322x.c                   | 1 -
>   arch/arm/mach-rockchip/rk3288/rk3288.c                   | 1 -
>   arch/arm/mach-rockchip/rk3308/rk3308.c                   | 1 -
>   arch/arm/mach-rockchip/rk3328/rk3328.c                   | 1 -
>   arch/arm/mach-rockchip/rk3368/rk3368.c                   | 1 -
>   arch/arm/mach-rockchip/rk3399/rk3399.c                   | 1 -
>   arch/arm/mach-rockchip/rk3568/rk3568.c                   | 1 -
>   arch/arm/mach-rockchip/rk3588/rk3588.c                   | 1 -
>   arch/arm/mach-rockchip/rv1126/rv1126.c                   | 1 -
>   board/elgin/elgin_rv1108/elgin_rv1108.c                  | 1 -
>   board/firefly/firefly-rk3308/roc_cc_rk3308.c             | 1 -
>   board/google/gru/gru.c                                   | 1 -
>   board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c   | 1 -
>   board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c | 1 -
>   board/pine64/rockpro64_rk3399/rockpro64-rk3399.c         | 1 -
>   board/rockchip/evb_rv1108/evb_rv1108.c                   | 1 -
>   board/theobroma-systems/puma_rk3399/puma-rk3399.c        | 1 -
>   board/vamrs/rock960_rk3399/rock960-rk3399.c              | 1 -
>   drivers/clk/rockchip/clk_pll.c                           | 1 -
>   drivers/clk/rockchip/clk_px30.c                          | 1 -
>   drivers/clk/rockchip/clk_rk3036.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3066.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3128.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3188.c                        | 1 -
>   drivers/clk/rockchip/clk_rk322x.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3288.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3308.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3328.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3368.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3399.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3568.c                        | 1 -
>   drivers/clk/rockchip/clk_rk3588.c                        | 1 -
>   drivers/clk/rockchip/clk_rv1108.c                        | 1 -
>   drivers/clk/rockchip/clk_rv1126.c                        | 1 -
>   drivers/gpio/rk_gpio.c                                   | 1 -
>   drivers/net/gmac_rockchip.c                              | 1 -
>   drivers/ram/rockchip/dmc-rk3368.c                        | 1 -
>   drivers/ram/rockchip/sdram_px30.c                        | 1 -
>   drivers/ram/rockchip/sdram_rk3066.c                      | 1 -
>   drivers/ram/rockchip/sdram_rk3188.c                      | 1 -
>   drivers/ram/rockchip/sdram_rk322x.c                      | 1 -
>   drivers/ram/rockchip/sdram_rk3288.c                      | 1 -
>   drivers/ram/rockchip/sdram_rk3399.c                      | 1 -
>   drivers/ram/rockchip/sdram_rv1126.c                      | 1 -
>   drivers/rng/rockchip_rng.c                               | 1 -
>   drivers/sysreset/sysreset_rockchip.c                     | 1 -
>   drivers/video/rockchip/dw_mipi_dsi_rockchip.c            | 1 -
>   drivers/video/rockchip/rk3288_hdmi.c                     | 1 -
>   drivers/video/rockchip/rk3288_mipi.c                     | 1 -
>   drivers/video/rockchip/rk3288_vop.c                      | 1 -
>   drivers/video/rockchip/rk3399_hdmi.c                     | 1 -
>   drivers/video/rockchip/rk3399_mipi.c                     | 1 -
>   drivers/video/rockchip/rk3399_vop.c                      | 1 -
>   drivers/video/rockchip/rk_edp.c                          | 1 -
>   drivers/video/rockchip/rk_hdmi.c                         | 1 -
>   drivers/video/rockchip/rk_lvds.c                         | 1 -
>   63 files changed, 2 insertions(+), 62 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/hardware.h b/arch/arm/include/asm/arch-rockchip/hardware.h
> index 62e8bed8f31..e4662a2d52d 100644
> --- a/arch/arm/include/asm/arch-rockchip/hardware.h
> +++ b/arch/arm/include/asm/arch-rockchip/hardware.h
> @@ -6,6 +6,8 @@
>   #ifndef _ASM_ARCH_HARDWARE_H
>   #define _ASM_ARCH_HARDWARE_H
>   
> +#include <asm/io.h>
> +
>   #define RK_CLRSETBITS(clr, set)		((((clr) | (set)) << 16) | (set))
>   #define RK_SETBITS(set)			RK_CLRSETBITS(0, set)
>   #define RK_CLRBITS(clr)			RK_CLRSETBITS(clr, 0)
> diff --git a/arch/arm/mach-rockchip/cpu-info.c b/arch/arm/mach-rockchip/cpu-info.c
> index dac24910e0c..a62ff53c6a0 100644
> --- a/arch/arm/mach-rockchip/cpu-info.c
> +++ b/arch/arm/mach-rockchip/cpu-info.c
> @@ -7,7 +7,6 @@
>   #include <common.h>
>   #include <env.h>
>   #include <init.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/arch/arm/mach-rockchip/px30/px30.c b/arch/arm/mach-rockchip/px30/px30.c
> index fc7456e680c..b4f655fa4b3 100644
> --- a/arch/arm/mach-rockchip/px30/px30.c
> +++ b/arch/arm/mach-rockchip/px30/px30.c
> @@ -9,7 +9,6 @@
>   #include <init.h>
>   #include <spl.h>
>   #include <asm/armv8/mmu.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/grf_px30.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/arch/arm/mach-rockchip/rk3036/rk3036.c b/arch/arm/mach-rockchip/rk3036/rk3036.c
> index 0a072cf03a8..e8130abdd77 100644
> --- a/arch/arm/mach-rockchip/rk3036/rk3036.c
> +++ b/arch/arm/mach-rockchip/rk3036/rk3036.c
> @@ -6,7 +6,6 @@
>   #include <common.h>
>   #include <init.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/grf_rk3036.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/sdram_rk3036.h>
> diff --git a/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c b/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
> index fcae65b2e5a..07cd29a33e6 100644
> --- a/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
> +++ b/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
> @@ -4,7 +4,6 @@
>    */
>   #include <common.h>
>   #include <init.h>
> -#include <asm/io.h>
>   #include <asm/types.h>
>   #include <asm/arch-rockchip/cru_rk3036.h>
>   #include <asm/arch-rockchip/grf_rk3036.h>
> diff --git a/arch/arm/mach-rockchip/rk3066/rk3066.c b/arch/arm/mach-rockchip/rk3066/rk3066.c
> index 6661b788295..9a95ff85041 100644
> --- a/arch/arm/mach-rockchip/rk3066/rk3066.c
> +++ b/arch/arm/mach-rockchip/rk3066/rk3066.c
> @@ -4,7 +4,6 @@
>    */
>   
>   #include <common.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/grf_rk3066.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c b/arch/arm/mach-rockchip/rk3188/rk3188.c
> index c807221f33f..ffdcaa49a1e 100644
> --- a/arch/arm/mach-rockchip/rk3188/rk3188.c
> +++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
> @@ -10,7 +10,6 @@
>   #include <log.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3188.h>
> diff --git a/arch/arm/mach-rockchip/rk322x/rk322x.c b/arch/arm/mach-rockchip/rk322x/rk322x.c
> index a304795fec6..712c0524266 100644
> --- a/arch/arm/mach-rockchip/rk322x/rk322x.c
> +++ b/arch/arm/mach-rockchip/rk322x/rk322x.c
> @@ -3,7 +3,6 @@
>    * (C) Copyright 2019 Rockchip Electronics Co., Ltd
>    */
>   #include <init.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/grf_rk322x.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c b/arch/arm/mach-rockchip/rk3288/rk3288.c
> index 26c7e41cd89..38080aeecc3 100644
> --- a/arch/arm/mach-rockchip/rk3288/rk3288.c
> +++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
> @@ -11,7 +11,6 @@
>   #include <malloc.h>
>   #include <asm/armv7.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cpu_rk3288.h>
> diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c b/arch/arm/mach-rockchip/rk3308/rk3308.c
> index 6f121bf1304..27a748327e3 100644
> --- a/arch/arm/mach-rockchip/rk3308/rk3308.c
> +++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
> @@ -5,7 +5,6 @@
>   #include <common.h>
>   #include <init.h>
>   #include <malloc.h>
> -#include <asm/io.h>
>   #include <asm/arch/grf_rk3308.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c b/arch/arm/mach-rockchip/rk3328/rk3328.c
> index b591d38fe41..b8e657e9bf4 100644
> --- a/arch/arm/mach-rockchip/rk3328/rk3328.c
> +++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
> @@ -10,7 +10,6 @@
>   #include <asm/arch-rockchip/grf_rk3328.h>
>   #include <asm/arch-rockchip/uart.h>
>   #include <asm/armv8/mmu.h>
> -#include <asm/io.h>
>   
>   #define CRU_BASE		0xFF440000
>   #define GRF_BASE		0xFF100000
> diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c b/arch/arm/mach-rockchip/rk3368/rk3368.c
> index d009b8758e5..651ba109020 100644
> --- a/arch/arm/mach-rockchip/rk3368/rk3368.c
> +++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
> @@ -8,7 +8,6 @@
>   #include <init.h>
>   #include <syscon.h>
>   #include <asm/armv8/mmu.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3368.h>
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index a1aa0e3e8b5..7fa1d7c7b7a 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -11,7 +11,6 @@
>   #include <spl_gpio.h>
>   #include <syscon.h>
>   #include <asm/armv8/mmu.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru.h>
> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c b/arch/arm/mach-rockchip/rk3568/rk3568.c
> index 69ef19cc85a..b30ea04f737 100644
> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> @@ -6,7 +6,6 @@
>   #include <common.h>
>   #include <dm.h>
>   #include <asm/armv8/mmu.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/grf_rk3568.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c b/arch/arm/mach-rockchip/rk3588/rk3588.c
> index 53ee9f1cebc..d9e04ede092 100644
> --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
> +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
> @@ -7,7 +7,6 @@
>   #include <common.h>
>   #include <spl.h>
>   #include <asm/armv8/mmu.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/ioc_rk3588.h>
> diff --git a/arch/arm/mach-rockchip/rv1126/rv1126.c b/arch/arm/mach-rockchip/rv1126/rv1126.c
> index b9b898756f7..8589c46f10a 100644
> --- a/arch/arm/mach-rockchip/rv1126/rv1126.c
> +++ b/arch/arm/mach-rockchip/rv1126/rv1126.c
> @@ -5,7 +5,6 @@
>    */
>   
>   #include <common.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/grf_rv1126.h>
> diff --git a/board/elgin/elgin_rv1108/elgin_rv1108.c b/board/elgin/elgin_rv1108/elgin_rv1108.c
> index eb7a322d847..10398e7f712 100644
> --- a/board/elgin/elgin_rv1108/elgin_rv1108.c
> +++ b/board/elgin/elgin_rv1108/elgin_rv1108.c
> @@ -8,7 +8,6 @@
>   #include <init.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rv1108.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/board/firefly/firefly-rk3308/roc_cc_rk3308.c b/board/firefly/firefly-rk3308/roc_cc_rk3308.c
> index bdf3cc03dc5..99a52a77116 100644
> --- a/board/firefly/firefly-rk3308/roc_cc_rk3308.c
> +++ b/board/firefly/firefly-rk3308/roc_cc_rk3308.c
> @@ -5,7 +5,6 @@
>   
>   #include <common.h>
>   #include <adc.h>
> -#include <asm/io.h>
>   #include <asm/arch/grf_rk3308.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <linux/bitops.h>
> diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
> index ecbf702b035..9cb3a525204 100644
> --- a/board/google/gru/gru.c
> +++ b/board/google/gru/gru.c
> @@ -7,7 +7,6 @@
>   #include <dm.h>
>   #include <init.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> index 2408a367305..5e758ea6cd9 100644
> --- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> +++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> @@ -7,7 +7,6 @@
>   #include <common.h>
>   #include <dm.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> index de75ee329d8..c9b0d5a061d 100644
> --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> @@ -8,7 +8,6 @@
>   #include <dm.h>
>   #include <init.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> index d0a694ead1d..fd78ad60d14 100644
> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> @@ -7,7 +7,6 @@
>   #include <dm.h>
>   #include <init.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/board/rockchip/evb_rv1108/evb_rv1108.c b/board/rockchip/evb_rv1108/evb_rv1108.c
> index e6ac598648d..0d7a486bed7 100644
> --- a/board/rockchip/evb_rv1108/evb_rv1108.c
> +++ b/board/rockchip/evb_rv1108/evb_rv1108.c
> @@ -8,7 +8,6 @@
>   #include <init.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rv1108.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index 98a818b135d..8b998ef4556 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -6,7 +6,6 @@
>   #include <dm.h>
>   #include <syscon.h>
>   #include <dm/pinctrl.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
> diff --git a/board/vamrs/rock960_rk3399/rock960-rk3399.c b/board/vamrs/rock960_rk3399/rock960-rk3399.c
> index a7fc38d42f8..876be8ed9e1 100644
> --- a/board/vamrs/rock960_rk3399/rock960-rk3399.c
> +++ b/board/vamrs/rock960_rk3399/rock960-rk3399.c
> @@ -5,7 +5,6 @@
>   
>   #include <common.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_pll.c b/drivers/clk/rockchip/clk_pll.c
> index 1bb31b3313b..66f8bb16695 100644
> --- a/drivers/clk/rockchip/clk_pll.c
> +++ b/drivers/clk/rockchip/clk_pll.c
> @@ -8,7 +8,6 @@
>   #include <dm.h>
>   #include <errno.h>
>   #include <log.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <div64.h>
> diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c
> index 93b76538509..2875c152b20 100644
> --- a/drivers/clk/rockchip/clk_px30.c
> +++ b/drivers/clk/rockchip/clk_px30.c
> @@ -15,7 +15,6 @@
>   #include <asm/arch-rockchip/cru_px30.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <dm/device-internal.h>
>   #include <dm/lists.h>
>   #include <dt-bindings/clock/px30-cru.h>
> diff --git a/drivers/clk/rockchip/clk_rk3036.c b/drivers/clk/rockchip/clk_rk3036.c
> index 6bc6d41ad61..6238b14c29e 100644
> --- a/drivers/clk/rockchip/clk_rk3036.c
> +++ b/drivers/clk/rockchip/clk_rk3036.c
> @@ -10,7 +10,6 @@
>   #include <log.h>
>   #include <malloc.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3036.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_rk3066.c b/drivers/clk/rockchip/clk_rk3066.c
> index 2c12f6e0441..f83335df6db 100644
> --- a/drivers/clk/rockchip/clk_rk3066.c
> +++ b/drivers/clk/rockchip/clk_rk3066.c
> @@ -14,7 +14,6 @@
>   #include <malloc.h>
>   #include <mapmem.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3066.h>
>   #include <asm/arch-rockchip/grf_rk3066.h>
> diff --git a/drivers/clk/rockchip/clk_rk3128.c b/drivers/clk/rockchip/clk_rk3128.c
> index 13e176cdad1..182754e7052 100644
> --- a/drivers/clk/rockchip/clk_rk3128.c
> +++ b/drivers/clk/rockchip/clk_rk3128.c
> @@ -10,7 +10,6 @@
>   #include <log.h>
>   #include <malloc.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3128.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_rk3188.c b/drivers/clk/rockchip/clk_rk3188.c
> index ebdd1b3f99a..f98b46a0f73 100644
> --- a/drivers/clk/rockchip/clk_rk3188.c
> +++ b/drivers/clk/rockchip/clk_rk3188.c
> @@ -13,7 +13,6 @@
>   #include <malloc.h>
>   #include <mapmem.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3188.h>
>   #include <asm/arch-rockchip/grf_rk3188.h>
> diff --git a/drivers/clk/rockchip/clk_rk322x.c b/drivers/clk/rockchip/clk_rk322x.c
> index 28cdba75758..9371c4f63a4 100644
> --- a/drivers/clk/rockchip/clk_rk322x.c
> +++ b/drivers/clk/rockchip/clk_rk322x.c
> @@ -10,7 +10,6 @@
>   #include <log.h>
>   #include <malloc.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk322x.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_rk3288.c b/drivers/clk/rockchip/clk_rk3288.c
> index e24c32c0a2a..0b7eefad15f 100644
> --- a/drivers/clk/rockchip/clk_rk3288.c
> +++ b/drivers/clk/rockchip/clk_rk3288.c
> @@ -15,7 +15,6 @@
>   #include <mapmem.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru.h>
>   #include <asm/arch-rockchip/grf_rk3288.h>
> diff --git a/drivers/clk/rockchip/clk_rk3308.c b/drivers/clk/rockchip/clk_rk3308.c
> index d0a3f654466..7755b016111 100644
> --- a/drivers/clk/rockchip/clk_rk3308.c
> +++ b/drivers/clk/rockchip/clk_rk3308.c
> @@ -12,7 +12,6 @@
>   #include <malloc.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch/cru_rk3308.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_rk3328.c b/drivers/clk/rockchip/clk_rk3328.c
> index ef97381f0ed..cfec1d974ac 100644
> --- a/drivers/clk/rockchip/clk_rk3328.c
> +++ b/drivers/clk/rockchip/clk_rk3328.c
> @@ -15,7 +15,6 @@
>   #include <asm/arch-rockchip/cru_rk3328.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/grf_rk3328.h>
> -#include <asm/io.h>
>   #include <dm/device-internal.h>
>   #include <dm/lists.h>
>   #include <dt-bindings/clock/rk3328-cru.h>
> diff --git a/drivers/clk/rockchip/clk_rk3368.c b/drivers/clk/rockchip/clk_rk3368.c
> index 3406ff592e1..1c5dfaa3800 100644
> --- a/drivers/clk/rockchip/clk_rk3368.c
> +++ b/drivers/clk/rockchip/clk_rk3368.c
> @@ -18,7 +18,6 @@
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3368.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/io.h>
>   #include <dm/device-internal.h>
>   #include <dm/lists.h>
>   #include <dt-bindings/clock/rk3368-cru.h>
> diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c
> index c37e8a53a26..80f65a237e8 100644
> --- a/drivers/clk/rockchip/clk_rk3399.c
> +++ b/drivers/clk/rockchip/clk_rk3399.c
> @@ -14,7 +14,6 @@
>   #include <mapmem.h>
>   #include <syscon.h>
>   #include <bitfield.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_rk3568.c b/drivers/clk/rockchip/clk_rk3568.c
> index 68f5bbbb9e5..57ef27dda89 100644
> --- a/drivers/clk/rockchip/clk_rk3568.c
> +++ b/drivers/clk/rockchip/clk_rk3568.c
> @@ -13,7 +13,6 @@
>   #include <asm/arch-rockchip/cru_rk3568.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/io.h>
>   #include <dm/device-internal.h>
>   #include <dm/lists.h>
>   #include <dt-bindings/clock/rk3568-cru.h>
> diff --git a/drivers/clk/rockchip/clk_rk3588.c b/drivers/clk/rockchip/clk_rk3588.c
> index a995dd5591d..8f33843179b 100644
> --- a/drivers/clk/rockchip/clk_rk3588.c
> +++ b/drivers/clk/rockchip/clk_rk3588.c
> @@ -14,7 +14,6 @@
>   #include <asm/arch-rockchip/cru_rk3588.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/io.h>
>   #include <dm/device-internal.h>
>   #include <dm/lists.h>
>   #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> diff --git a/drivers/clk/rockchip/clk_rv1108.c b/drivers/clk/rockchip/clk_rv1108.c
> index b0c889ae156..fc442f7eebe 100644
> --- a/drivers/clk/rockchip/clk_rv1108.c
> +++ b/drivers/clk/rockchip/clk_rv1108.c
> @@ -13,7 +13,6 @@
>   #include <malloc.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rv1108.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/clk/rockchip/clk_rv1126.c b/drivers/clk/rockchip/clk_rv1126.c
> index 580c0b1b0cf..cfdfcbdb0f4 100644
> --- a/drivers/clk/rockchip/clk_rv1126.c
> +++ b/drivers/clk/rockchip/clk_rv1126.c
> @@ -16,7 +16,6 @@
>   #include <asm/arch-rockchip/grf_rv1126.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <dm/device-internal.h>
> -#include <asm/io.h>
>   #include <dm/lists.h>
>   #include <dt-bindings/clock/rockchip,rv1126-cru.h>
>   
> diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
> index 4a6ae554bf7..c5e096bb1ad 100644
> --- a/drivers/gpio/rk_gpio.c
> +++ b/drivers/gpio/rk_gpio.c
> @@ -11,7 +11,6 @@
>   #include <syscon.h>
>   #include <linux/errno.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/gpio.h>
> diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
> index 04008d2b198..c1bae3f68bd 100644
> --- a/drivers/net/gmac_rockchip.c
> +++ b/drivers/net/gmac_rockchip.c
> @@ -13,7 +13,6 @@
>   #include <phy.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/periph.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/ram/rockchip/dmc-rk3368.c b/drivers/ram/rockchip/dmc-rk3368.c
> index 74d8aed571c..c0a60be7f11 100644
> --- a/drivers/ram/rockchip/dmc-rk3368.c
> +++ b/drivers/ram/rockchip/dmc-rk3368.c
> @@ -13,7 +13,6 @@
>   #include <ram.h>
>   #include <regmap.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3368.h>
>   #include <asm/arch-rockchip/grf_rk3368.h>
> diff --git a/drivers/ram/rockchip/sdram_px30.c b/drivers/ram/rockchip/sdram_px30.c
> index 2728d93be32..21498e89570 100644
> --- a/drivers/ram/rockchip/sdram_px30.c
> +++ b/drivers/ram/rockchip/sdram_px30.c
> @@ -10,7 +10,6 @@
>   #include <log.h>
>   #include <ram.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_px30.h>
>   #include <asm/arch-rockchip/grf_px30.h>
> diff --git a/drivers/ram/rockchip/sdram_rk3066.c b/drivers/ram/rockchip/sdram_rk3066.c
> index 39c0be56a6e..562cf544c90 100644
> --- a/drivers/ram/rockchip/sdram_rk3066.c
> +++ b/drivers/ram/rockchip/sdram_rk3066.c
> @@ -17,7 +17,6 @@
>   #include <ram.h>
>   #include <regmap.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3066.h>
>   #include <asm/arch-rockchip/ddr_rk3188.h>
> diff --git a/drivers/ram/rockchip/sdram_rk3188.c b/drivers/ram/rockchip/sdram_rk3188.c
> index 16a68885f1f..f689235b13d 100644
> --- a/drivers/ram/rockchip/sdram_rk3188.c
> +++ b/drivers/ram/rockchip/sdram_rk3188.c
> @@ -17,7 +17,6 @@
>   #include <ram.h>
>   #include <regmap.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3188.h>
>   #include <asm/arch-rockchip/ddr_rk3188.h>
> diff --git a/drivers/ram/rockchip/sdram_rk322x.c b/drivers/ram/rockchip/sdram_rk322x.c
> index 892766a8b43..5fc23c11193 100644
> --- a/drivers/ram/rockchip/sdram_rk322x.c
> +++ b/drivers/ram/rockchip/sdram_rk322x.c
> @@ -12,7 +12,6 @@
>   #include <regmap.h>
>   #include <syscon.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk322x.h>
>   #include <asm/arch-rockchip/grf_rk322x.h>
> diff --git a/drivers/ram/rockchip/sdram_rk3288.c b/drivers/ram/rockchip/sdram_rk3288.c
> index ec6bdcb2015..2c1afa93ecf 100644
> --- a/drivers/ram/rockchip/sdram_rk3288.c
> +++ b/drivers/ram/rockchip/sdram_rk3288.c
> @@ -17,7 +17,6 @@
>   #include <ram.h>
>   #include <regmap.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru.h>
>   #include <asm/arch-rockchip/ddr_rk3288.h>
> diff --git a/drivers/ram/rockchip/sdram_rk3399.c b/drivers/ram/rockchip/sdram_rk3399.c
> index 2bf8d48d25a..02cc4a38cf0 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ b/drivers/ram/rockchip/sdram_rk3399.c
> @@ -14,7 +14,6 @@
>   #include <ram.h>
>   #include <regmap.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
> diff --git a/drivers/ram/rockchip/sdram_rv1126.c b/drivers/ram/rockchip/sdram_rv1126.c
> index 9e1376a940f..4377871e092 100644
> --- a/drivers/ram/rockchip/sdram_rv1126.c
> +++ b/drivers/ram/rockchip/sdram_rv1126.c
> @@ -9,7 +9,6 @@
>   #include <dm.h>
>   #include <ram.h>
>   #include <syscon.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/cru_rv1126.h>
> diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
> index 705b424cf3d..9dec7e45dde 100644
> --- a/drivers/rng/rockchip_rng.c
> +++ b/drivers/rng/rockchip_rng.c
> @@ -3,7 +3,6 @@
>    * Copyright (c) 2020 Fuzhou Rockchip Electronics Co., Ltd
>    */
>   #include <asm/arch-rockchip/hardware.h>
> -#include <asm/io.h>
>   #include <common.h>
>   #include <dm.h>
>   #include <linux/bitops.h>
> diff --git a/drivers/sysreset/sysreset_rockchip.c b/drivers/sysreset/sysreset_rockchip.c
> index 0fc6b683f2b..f353f9b4c79 100644
> --- a/drivers/sysreset/sysreset_rockchip.c
> +++ b/drivers/sysreset/sysreset_rockchip.c
> @@ -7,7 +7,6 @@
>   #include <dm.h>
>   #include <errno.h>
>   #include <sysreset.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/cru_rk3328.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
> index 5e75b6ec68c..fb784636e87 100644
> --- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
> +++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
> @@ -27,7 +27,6 @@
>   #include <common.h>
>   #include <log.h>
>   #include <video.h>
> -#include <asm/io.h>
>   #include <dm/device-internal.h>
>   #include <linux/bitops.h>
>   #include <linux/time.h>
> diff --git a/drivers/video/rockchip/rk3288_hdmi.c b/drivers/video/rockchip/rk3288_hdmi.c
> index 327ae787125..9cbe31e9abd 100644
> --- a/drivers/video/rockchip/rk3288_hdmi.c
> +++ b/drivers/video/rockchip/rk3288_hdmi.c
> @@ -14,7 +14,6 @@
>   #include <regmap.h>
>   #include <syscon.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/grf_rk3288.h>
> diff --git a/drivers/video/rockchip/rk3288_mipi.c b/drivers/video/rockchip/rk3288_mipi.c
> index c0dffa3cba2..9d42119c826 100644
> --- a/drivers/video/rockchip/rk3288_mipi.c
> +++ b/drivers/video/rockchip/rk3288_mipi.c
> @@ -14,7 +14,6 @@
>   #include "rk_mipi.h"
>   #include <syscon.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <dm/uclass-internal.h>
>   #include <linux/err.h>
>   #include <linux/kernel.h>
> diff --git a/drivers/video/rockchip/rk3288_vop.c b/drivers/video/rockchip/rk3288_vop.c
> index 44f32bb5fa2..a4683852ea0 100644
> --- a/drivers/video/rockchip/rk3288_vop.c
> +++ b/drivers/video/rockchip/rk3288_vop.c
> @@ -12,7 +12,6 @@
>   #include <syscon.h>
>   #include <video.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3288.h>
>   #include <asm/arch-rockchip/hardware.h>
> diff --git a/drivers/video/rockchip/rk3399_hdmi.c b/drivers/video/rockchip/rk3399_hdmi.c
> index 3041360c6ed..5f3f5d26886 100644
> --- a/drivers/video/rockchip/rk3399_hdmi.c
> +++ b/drivers/video/rockchip/rk3399_hdmi.c
> @@ -12,7 +12,6 @@
>   #include <regmap.h>
>   #include <syscon.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
> diff --git a/drivers/video/rockchip/rk3399_mipi.c b/drivers/video/rockchip/rk3399_mipi.c
> index 7fc79ba9045..b62d8086674 100644
> --- a/drivers/video/rockchip/rk3399_mipi.c
> +++ b/drivers/video/rockchip/rk3399_mipi.c
> @@ -14,7 +14,6 @@
>   #include "rk_mipi.h"
>   #include <syscon.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <dm/uclass-internal.h>
>   #include <linux/err.h>
>   #include <linux/kernel.h>
> diff --git a/drivers/video/rockchip/rk3399_vop.c b/drivers/video/rockchip/rk3399_vop.c
> index a34b491058f..cb589c7537e 100644
> --- a/drivers/video/rockchip/rk3399_vop.c
> +++ b/drivers/video/rockchip/rk3399_vop.c
> @@ -13,7 +13,6 @@
>   #include <video.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/global_data.h>
> -#include <asm/io.h>
>   #include "rk_vop.h"
>   
>   DECLARE_GLOBAL_DATA_PTR;
> diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c
> index 3697d582510..67bfa788367 100644
> --- a/drivers/video/rockchip/rk_edp.c
> +++ b/drivers/video/rockchip/rk_edp.c
> @@ -17,7 +17,6 @@
>   #include <reset.h>
>   #include <syscon.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include <asm/arch-rockchip/edp_rk3288.h>
> diff --git a/drivers/video/rockchip/rk_hdmi.c b/drivers/video/rockchip/rk_hdmi.c
> index 8dcd4d59645..044a29ee47a 100644
> --- a/drivers/video/rockchip/rk_hdmi.c
> +++ b/drivers/video/rockchip/rk_hdmi.c
> @@ -15,7 +15,6 @@
>   #include <regmap.h>
>   #include <syscon.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/hardware.h>
>   #include "rk_hdmi.h"
> diff --git a/drivers/video/rockchip/rk_lvds.c b/drivers/video/rockchip/rk_lvds.c
> index 9cf3e3ca768..d0a015e31ee 100644
> --- a/drivers/video/rockchip/rk_lvds.c
> +++ b/drivers/video/rockchip/rk_lvds.c
> @@ -13,7 +13,6 @@
>   #include <syscon.h>
>   #include <asm/global_data.h>
>   #include <asm/gpio.h>
> -#include <asm/io.h>
>   #include <asm/arch-rockchip/clock.h>
>   #include <asm/arch-rockchip/grf_rk3288.h>
>   #include <asm/arch-rockchip/hardware.h>
>

[PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.

While this is usually not much of an issue, it is when there's a lookup
for devices by code running before the relocation. Such is the case of
env_init() which calls env_driver_lookup() which calls
env_get_location() which is a weak symbol and may call
arch_env_get_location() also a weak symbol. Those are two functions that
may traverse UCLASS to find some devices (e.g.
board/theobroma-systems/common/common.c:arch_env_get_location()).

This allows something in the env_init() call stack to be able to use
uclasses for SD and eMMC controller on RK3588S/RK3588. This aligns the
behavior with what seems to be all SoCs except RK356x family.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rk3588s-u-boot.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index 960ac4abda3..bdfe13836b2 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -187,12 +187,12 @@
 };
 
 &sdmmc {
-	bootph-pre-ram;
+	bootph-all;
 	u-boot,spl-fifo-mode;
 };
 
 &sdhci {
-	bootph-pre-ram;
+	bootph-all;
 	u-boot,spl-fifo-mode;
 };
 

-- 
2.43.0

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Kever Yang]

Hi Quentin,

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
> bind the device before relocation.
>
> While this is usually not much of an issue, it is when there's a lookup
> for devices by code running before the relocation. Such is the case of
> env_init() which calls env_driver_lookup() which calls
> env_get_location() which is a weak symbol and may call
> arch_env_get_location() also a weak symbol. Those are two functions that
> may traverse UCLASS to find some devices (e.g.
> board/theobroma-systems/common/common.c:arch_env_get_location()).

This sounds like we need to update arch_env_get_location() instead of 
enable mmc driver

before relocate, because you we don't really need the mmc driver works 
here, there is no

access requirement to mmc at this point, right?


Thanks,

- Kever

>
> This allows something in the env_init() call stack to be able to use
> uclasses for SD and eMMC controller on RK3588S/RK3588. This aligns the
> behavior with what seems to be all SoCs except RK356x family.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>   arch/arm/dts/rk3588s-u-boot.dtsi | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
> index 960ac4abda3..bdfe13836b2 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -187,12 +187,12 @@
>   };
>   
>   &sdmmc {
> -	bootph-pre-ram;
> +	bootph-all;
>   	u-boot,spl-fifo-mode;
>   };
>   
>   &sdhci {
> -	bootph-pre-ram;
> +	bootph-all;
>   	u-boot,spl-fifo-mode;
>   };
>   
>

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Quentin Schulz]

Hi Kever,

On 1/24/24 11:35, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/23 22:49, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
>> bind the device before relocation.
>>
>> While this is usually not much of an issue, it is when there's a lookup
>> for devices by code running before the relocation. Such is the case of
>> env_init() which calls env_driver_lookup() which calls
>> env_get_location() which is a weak symbol and may call
>> arch_env_get_location() also a weak symbol. Those are two functions that
>> may traverse UCLASS to find some devices (e.g.
>> board/theobroma-systems/common/common.c:arch_env_get_location()).
> 
> This sounds like we need to update arch_env_get_location() instead of 
> enable mmc driver
> 
> before relocate, because you we don't really need the mmc driver works 
> here, there is no
> 
> access requirement to mmc at this point, right?
> 

All Rockchip SoCs except RK3588(S) and RK356x have it done this way, a 
little bit of consistency wouldn't hurt :)

I need to be able to find out if the device that was used to load U-Boot 
proper is an MMC device so that I can tell arch_env_get_location() to 
return ENVL_MMC; in that case.

For that, I've used uclass_find_device_by_ofnode() which parses the list 
of devices registered in the UCLASS_MMC (for that scenario). I assume 
the only requirement is that the device needs to be bound, not probed 
(haven't checked). If there's another way to do this **properly**, I'm 
all ears. I would likely need to do the same for the SPI controllers but 
since none of our RK3588-based products have SPI-NOR, I don't need those 
(but it works on RK3399 just fine).

I still think there's value in having consistency between all Rockchip 
SoCs (and if applicable to other SoC vendors, then those as well). We 
could still do both though, have this and then fix the need for 
requiring sdmmc/sdhci devices to be bound/probed for env_init() 
(arch_env_get_location()) to work.

What is bothering you in enabling those drivers in U-Boot proper before 
relocation?

Cheers,
Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Kever Yang]

Hi Quentin,

On 2024/1/24 19:04, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/24/24 11:35, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>
>>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram 
>>> node as
>>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
>>> bind the device before relocation.
>>>
>>> While this is usually not much of an issue, it is when there's a lookup
>>> for devices by code running before the relocation. Such is the case of
>>> env_init() which calls env_driver_lookup() which calls
>>> env_get_location() which is a weak symbol and may call
>>> arch_env_get_location() also a weak symbol. Those are two functions 
>>> that
>>> may traverse UCLASS to find some devices (e.g.
>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>
>> This sounds like we need to update arch_env_get_location() instead of 
>> enable mmc driver
>>
>> before relocate, because you we don't really need the mmc driver 
>> works here, there is no
>>
>> access requirement to mmc at this point, right?
>>
>
> All Rockchip SoCs except RK3588(S) and RK356x have it done this way, a 
> little bit of consistency wouldn't hurt :)

My point is not about you can not enabe the emmc before relocate, maybe 
I'm not clear enough for the reason.

All the driver bind/probed before the relocation will have to do the 
init sequence again later after relocation.

The emmc driver cost pretty much time at init, we should avoid to 
duplicate the init process if possible.

For this patch, you want to make it pre-relocate because you want to 
make sure the emmc is available for ENVL_MMC,

but there is no read or write requirement to the emmc at this point, 
which means we don't have to init the emmc at this point,

maybe we can check if the driver is enable if enough.

> I need to be able to find out if the device that was used to load 
> U-Boot proper is an MMC device so that I can tell 
> arch_env_get_location() to return ENVL_MMC; in that case.
>
> For that, I've used uclass_find_device_by_ofnode() which parses the 
> list of devices registered in the UCLASS_MMC (for that scenario). I 
> assume the only requirement is that the device needs to be bound, not 
> probed (haven't checked). If there's another way to do this 
> **properly**, I'm all ears. I would likely need to do the same for the 
> SPI controllers but since none of our RK3588-based products have 
> SPI-NOR, I don't need those (but it works on RK3399 just fine).
>
> I still think there's value in having consistency between all Rockchip 
> SoCs (and if applicable to other SoC vendors, then those as well). 


This is the point I do care, because I don't want the boot loader too 
heavy, especially the SPL and the U-Boot proper before relocate, 
although we can enable all the feature in it in technically.

Even for the rk3588 which is kind of powerful soc, still many project 
need it to boot fast, which require to remove all the redundant 
operation in the boot process.


For the feature record "spl-boot-device" in SPL and read in out in 
U-Boot proper,  and then Swap mmc0 and mmc1 in boot_targets if booted 
from SD-Card.

It's OK for Theobroma-Systems's board to enable it, but seems not also 
required by other boards.

Usually we consider the system in two stage: bootloader/BIOS 
stage(including all firmware before kernel) and OS stage(including 
kernel and Linux/Android OS),

and for those boards(eg. PC like) do have two different storage medium, 
they put bootloader in SPI flash and put OS firmware in other storage 
like emmc/SSD/SDcard.

In this case the U-Boot boot target does not need to know where it's from;

in another case which supports firmware update from SD card, the U-Boot 
boot target needs to set SDCard as highest priority, also no need to 
know where the U-Boot from.


Thanks,
- Kever
> We could still do both though, have this and then fix the need for 
> requiring sdmmc/sdhci devices to be bound/probed for env_init() 
> (arch_env_get_location()) to work.
>
> What is bothering you in enabling those drivers in U-Boot proper 
> before relocation?
>
> Cheers,
> Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Quentin Schulz]

Hi Kever,

On 1/26/24 09:58, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/24 19:04, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 1/24/24 11:35, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>
>>>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram 
>>>> node as
>>>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
>>>> bind the device before relocation.
>>>>
>>>> While this is usually not much of an issue, it is when there's a lookup
>>>> for devices by code running before the relocation. Such is the case of
>>>> env_init() which calls env_driver_lookup() which calls
>>>> env_get_location() which is a weak symbol and may call
>>>> arch_env_get_location() also a weak symbol. Those are two functions 
>>>> that
>>>> may traverse UCLASS to find some devices (e.g.
>>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>>
>>> This sounds like we need to update arch_env_get_location() instead of 
>>> enable mmc driver
>>>
>>> before relocate, because you we don't really need the mmc driver 
>>> works here, there is no
>>>
>>> access requirement to mmc at this point, right?
>>>
>>
>> All Rockchip SoCs except RK3588(S) and RK356x have it done this way, a 
>> little bit of consistency wouldn't hurt :)
> 
> My point is not about you can not enabe the emmc before relocate, maybe 
> I'm not clear enough for the reason.
> 
> All the driver bind/probed before the relocation will have to do the 
> init sequence again later after relocation.
> 
> The emmc driver cost pretty much time at init, we should avoid to 
> duplicate the init process if possible.
> 
> For this patch, you want to make it pre-relocate because you want to 
> make sure the emmc is available for ENVL_MMC,
> 
> but there is no read or write requirement to the emmc at this point, 
> which means we don't have to init the emmc at this point,
> 
> maybe we can check if the driver is enable if enough.
> 

Now I need to know which SoC we are booting at build time so I can check 
which drivers are supposed to be built, check those symbols are enabled, 
then traverse the Device Tree with hardcoded DT node to locations of 
MMC, SPI flash controllers, check if those are enabled and finger-cross 
that those drivers will actually bind/probe properly later on. That's A 
LOT of checks to be made.

>> I need to be able to find out if the device that was used to load 
>> U-Boot proper is an MMC device so that I can tell 
>> arch_env_get_location() to return ENVL_MMC; in that case.
>>
>> For that, I've used uclass_find_device_by_ofnode() which parses the 
>> list of devices registered in the UCLASS_MMC (for that scenario). I 
>> assume the only requirement is that the device needs to be bound, not 
>> probed (haven't checked). If there's another way to do this 
>> **properly**, I'm all ears. I would likely need to do the same for the 
>> SPI controllers but since none of our RK3588-based products have 
>> SPI-NOR, I don't need those (but it works on RK3399 just fine).
>>
>> I still think there's value in having consistency between all Rockchip 
>> SoCs (and if applicable to other SoC vendors, then those as well). 
> 
> 
> This is the point I do care, because I don't want the boot loader too 
> heavy, especially the SPL and the U-Boot proper before relocate, 
> although we can enable all the feature in it in technically.
> 
> Even for the rk3588 which is kind of powerful soc, still many project 
> need it to boot fast, which require to remove all the redundant 
> operation in the boot process.
> 

It's a bit surprising to start caring about boot speed to justify not 
binding some drivers on the fastest (to date) Rockchip SoC while all 
much slower SoCs have this enabled :)

> 
> For the feature record "spl-boot-device" in SPL and read in out in 
> U-Boot proper,  and then Swap mmc0 and mmc1 in boot_targets if booted 
> from SD-Card.
> 
> It's OK for Theobroma-Systems's board to enable it, but seems not also 
> required by other boards.
> 
> Usually we consider the system in two stage: bootloader/BIOS 
> stage(including all firmware before kernel) and OS stage(including 
> kernel and Linux/Android OS),
> 
> and for those boards(eg. PC like) do have two different storage medium, 
> they put bootloader in SPI flash and put OS firmware in other storage 
> like emmc/SSD/SDcard.
> 
> In this case the U-Boot boot target does not need to know where it's from;
> 
> in another case which supports firmware update from SD card, the U-Boot 
> boot target needs to set SDCard as highest priority, also no need to 
> know where the U-Boot from.
> 

So... this means we need a different U-Boot if we're booting from SD 
card so it can know which boot target to use by default? Or a different 
environment for SD card? or requiring the user to stop the boot process 
and manually change the priority? Or what are you suggesting?

It all boils down to sane defaults. If I understand correctly, you want 
people to have systems which can boot really fast by default but don't 
mind if people need to tinker to get things working properly. I would 
prefer to have most things working by default and let people tinker to 
make things faster.

There are a couple of drivers that are selected when using Rockchip 
boards that shouldn't be necessary, e.g. ADC support, SPI flash 
controller (to name the few that we have on RK3588 that we don't need 
for Jaguar now), there are also DT nodes that are enabled by default in 
rk3588(s)-u-boot.dtsi that aren't necessary for my use case, this also 
increases the size of the DTB. I don't really get where you want the 
line between convenience and speed be right now. It'd be nice to have 
some kind of consensus/guideline if you already have one in mind, at 
least I'd know where we want to go with this :)

Reminder that if people want to make things faster, they can still 
override this in their own -u-boot.dtsi by deleting bootph-all and 
adding bootph-pre-ream instead.

I can keep this in rk3588-jaguar-u-boot.dtsi sure, I'll have to do the 
same for another RK3588 board soon as well.

So, up to you. I gather you'd prefer we have this in 
rk3588-jaguar-u-boot.dtsi so will do this for v2 except if you're saying 
otherwise.

Cheers,
Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Kever Yang]

Hi Quentin,

On 2024/1/26 17:32, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/26/24 09:58, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/24 19:04, Quentin Schulz wrote:
>>> Hi Kever,
>>>
>>> On 1/24/24 11:35, Kever Yang wrote:
>>>> Hi Quentin,
>>>>
>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>
>>>>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram 
>>>>> node as
>>>>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot 
>>>>> proper
>>>>> bind the device before relocation.
>>>>>
>>>>> While this is usually not much of an issue, it is when there's a 
>>>>> lookup
>>>>> for devices by code running before the relocation. Such is the 
>>>>> case of
>>>>> env_init() which calls env_driver_lookup() which calls
>>>>> env_get_location() which is a weak symbol and may call
>>>>> arch_env_get_location() also a weak symbol. Those are two 
>>>>> functions that
>>>>> may traverse UCLASS to find some devices (e.g.
>>>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>>>
>>>> This sounds like we need to update arch_env_get_location() instead 
>>>> of enable mmc driver
>>>>
>>>> before relocate, because you we don't really need the mmc driver 
>>>> works here, there is no
>>>>
>>>> access requirement to mmc at this point, right?
>>>>
>>>
>>> All Rockchip SoCs except RK3588(S) and RK356x have it done this way, 
>>> a little bit of consistency wouldn't hurt :)
>>
>> My point is not about you can not enabe the emmc before relocate, 
>> maybe I'm not clear enough for the reason.
>>
>> All the driver bind/probed before the relocation will have to do the 
>> init sequence again later after relocation.
>>
>> The emmc driver cost pretty much time at init, we should avoid to 
>> duplicate the init process if possible.
>>
>> For this patch, you want to make it pre-relocate because you want to 
>> make sure the emmc is available for ENVL_MMC,
>>
>> but there is no read or write requirement to the emmc at this point, 
>> which means we don't have to init the emmc at this point,
>>
>> maybe we can check if the driver is enable if enough.
>>
>
> Now I need to know which SoC we are booting at build time so I can 
> check which drivers are supposed to be built, check those symbols are 
> enabled, then traverse the Device Tree with hardcoded DT node to 
> locations of MMC, SPI flash controllers, check if those are enabled 
> and finger-cross that those drivers will actually bind/probe properly 
> later on. That's A LOT of checks to be made.

This is not what I want to say.

What I mean is something  like this for arch_env_get_location() is 
enough, you don't have to bind/probe the emmc for env.

1623                 if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) && 
IS_ENABLED(CONFIG_MMC))
1624                         return ENVL_MMC;

>
>>> I need to be able to find out if the device that was used to load 
>>> U-Boot proper is an MMC device so that I can tell 
>>> arch_env_get_location() to return ENVL_MMC; in that case.
>>>
>>> For that, I've used uclass_find_device_by_ofnode() which parses the 
>>> list of devices registered in the UCLASS_MMC (for that scenario). I 
>>> assume the only requirement is that the device needs to be bound, 
>>> not probed (haven't checked). If there's another way to do this 
>>> **properly**, I'm all ears. I would likely need to do the same for 
>>> the SPI controllers but since none of our RK3588-based products have 
>>> SPI-NOR, I don't need those (but it works on RK3399 just fine).
>>>
>>> I still think there's value in having consistency between all 
>>> Rockchip SoCs (and if applicable to other SoC vendors, then those as 
>>> well). 
>>
>>
>> This is the point I do care, because I don't want the boot loader too 
>> heavy, especially the SPL and the U-Boot proper before relocate, 
>> although we can enable all the feature in it in technically.
>>
>> Even for the rk3588 which is kind of powerful soc, still many project 
>> need it to boot fast, which require to remove all the redundant 
>> operation in the boot process.
>>
>
> It's a bit surprising to start caring about boot speed to justify not 
> binding some drivers on the fastest (to date) Rockchip SoC while all 
> much slower SoCs have this enabled :)
>
>>
>> For the feature record "spl-boot-device" in SPL and read in out in 
>> U-Boot proper,  and then Swap mmc0 and mmc1 in boot_targets if booted 
>> from SD-Card.
>>
>> It's OK for Theobroma-Systems's board to enable it, but seems not 
>> also required by other boards.
>>
>> Usually we consider the system in two stage: bootloader/BIOS 
>> stage(including all firmware before kernel) and OS stage(including 
>> kernel and Linux/Android OS),
>>
>> and for those boards(eg. PC like) do have two different storage 
>> medium, they put bootloader in SPI flash and put OS firmware in other 
>> storage like emmc/SSD/SDcard.
>>
>> In this case the U-Boot boot target does not need to know where it's 
>> from;
>>
>> in another case which supports firmware update from SD card, the 
>> U-Boot boot target needs to set SDCard as highest priority, also no 
>> need to know where the U-Boot from.
>>
>
> So... this means we need a different U-Boot if we're booting from SD 
> card so it can know which boot target to use by default? Or a 
> different environment for SD card? or requiring the user to stop the 
> boot process and manually change the priority? Or what are you 
> suggesting?

No, we don't need a different U-Boot, we can always set SD card boot 
first in boot target in all case, if SD card don't have an available 
firmware it will fall back to use eMMC, this works for the board I have.

Maybe I didn't understand correctly why you have to do "Swap mmc0 and 
mmc1 in boot_targets if booted from SD-Card"?

>
> It all boils down to sane defaults. If I understand correctly, you 
> want people to have systems which can boot really fast by default but 
> don't mind if people need to tinker to get things working properly. I 
> would prefer to have most things working by default and let people 
> tinker to make things faster.

:(

Then I would say you didin't understand correctly.

I agree to let people tinker to make things faster and most things work 
by default, but don't make too many troubles for tinker if possible.

>
> There are a couple of drivers that are selected when using Rockchip 
> boards that shouldn't be necessary, e.g. ADC support, SPI flash 
> controller (to name the few that we have on RK3588 that we don't need 
> for Jaguar now), there are also DT nodes that are enabled by default 
> in rk3588(s)-u-boot.dtsi that aren't necessary for my use case, this 
> also increases the size of the DTB. I don't really get where you want 
> the line between convenience and speed be right now. It'd be nice to 
> have some kind of consensus/guideline if you already have one in mind, 
> at least I'd know where we want to go with this :)

I never said we can't enable pre-reloc the emmc in rk3588 u-boot dt, 
that's not the key point.

You add this patch to make arch_env_get_location() work, I suggest that 
if we don't really access to emmc,

then update arch_env_get_location() might be better.

If it's not able to update arch_env_get_location because it doesn't 
work, then this patch is able to accept,

and I would suggest arch_env_get_location() to leave in 
board/theobroma-systems/common/common.c.


Thanks,
- Kever
>
> Reminder that if people want to make things faster, they can still 
> override this in their own -u-boot.dtsi by deleting bootph-all and 
> adding bootph-pre-ream instead.
>
> I can keep this in rk3588-jaguar-u-boot.dtsi sure, I'll have to do the 
> same for another RK3588 board soon as well.
>
> So, up to you. I gather you'd prefer we have this in 
> rk3588-jaguar-u-boot.dtsi so will do this for v2 except if you're 
> saying otherwise.
>
> Cheers,
> Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Quentin Schulz]

Hi Kever,

On 1/26/24 11:56, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/26 17:32, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 1/26/24 09:58, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/1/24 19:04, Quentin Schulz wrote:
>>>> Hi Kever,
>>>>
>>>> On 1/24/24 11:35, Kever Yang wrote:
>>>>> Hi Quentin,
>>>>>
>>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>>
>>>>>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram 
>>>>>> node as
>>>>>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot 
>>>>>> proper
>>>>>> bind the device before relocation.
>>>>>>
>>>>>> While this is usually not much of an issue, it is when there's a 
>>>>>> lookup
>>>>>> for devices by code running before the relocation. Such is the 
>>>>>> case of
>>>>>> env_init() which calls env_driver_lookup() which calls
>>>>>> env_get_location() which is a weak symbol and may call
>>>>>> arch_env_get_location() also a weak symbol. Those are two 
>>>>>> functions that
>>>>>> may traverse UCLASS to find some devices (e.g.
>>>>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>>>>
>>>>> This sounds like we need to update arch_env_get_location() instead 
>>>>> of enable mmc driver
>>>>>
>>>>> before relocate, because you we don't really need the mmc driver 
>>>>> works here, there is no
>>>>>
>>>>> access requirement to mmc at this point, right?
>>>>>
>>>>
>>>> All Rockchip SoCs except RK3588(S) and RK356x have it done this way, 
>>>> a little bit of consistency wouldn't hurt :)
>>>
>>> My point is not about you can not enabe the emmc before relocate, 
>>> maybe I'm not clear enough for the reason.
>>>
>>> All the driver bind/probed before the relocation will have to do the 
>>> init sequence again later after relocation.
>>>
>>> The emmc driver cost pretty much time at init, we should avoid to 
>>> duplicate the init process if possible.
>>>
>>> For this patch, you want to make it pre-relocate because you want to 
>>> make sure the emmc is available for ENVL_MMC,
>>>
>>> but there is no read or write requirement to the emmc at this point, 
>>> which means we don't have to init the emmc at this point,
>>>
>>> maybe we can check if the driver is enable if enough.
>>>
>>
>> Now I need to know which SoC we are booting at build time so I can 
>> check which drivers are supposed to be built, check those symbols are 
>> enabled, then traverse the Device Tree with hardcoded DT node to 
>> locations of MMC, SPI flash controllers, check if those are enabled 
>> and finger-cross that those drivers will actually bind/probe properly 
>> later on. That's A LOT of checks to be made.
> 
> This is not what I want to say.
> 
> What I mean is something  like this for arch_env_get_location() is 
> enough, you don't have to bind/probe the emmc for env.
> 
> 1623                 if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) && 
> IS_ENABLED(CONFIG_MMC))
> 1624                         return ENVL_MMC;
> 

I do need to know if the device we loaded U-Boot proper from is an MMC 
device or a SPI flash, so this is not enough for arch_env_get_location().

I could do it in a hack-ish way though and check if the U-Boot proper 
load medium DT node name starts with /mmc, or /spi and if neither, then 
return NOWHERE, but then we lose the ability of returning NOWHERE if the 
driver wasn't compiled in or the device didn't bind in pre-reloc, we're 
missing some failsafe mechanism I could have with this patch :)

[...]

>>> For the feature record "spl-boot-device" in SPL and read in out in 
>>> U-Boot proper,  and then Swap mmc0 and mmc1 in boot_targets if booted 
>>> from SD-Card.
>>>
>>> It's OK for Theobroma-Systems's board to enable it, but seems not 
>>> also required by other boards.
>>>
>>> Usually we consider the system in two stage: bootloader/BIOS 
>>> stage(including all firmware before kernel) and OS stage(including 
>>> kernel and Linux/Android OS),
>>>
>>> and for those boards(eg. PC like) do have two different storage 
>>> medium, they put bootloader in SPI flash and put OS firmware in other 
>>> storage like emmc/SSD/SDcard.
>>>
>>> In this case the U-Boot boot target does not need to know where it's 
>>> from;
>>>
>>> in another case which supports firmware update from SD card, the 
>>> U-Boot boot target needs to set SDCard as highest priority, also no 
>>> need to know where the U-Boot from.
>>>
>>
>> So... this means we need a different U-Boot if we're booting from SD 
>> card so it can know which boot target to use by default? Or a 
>> different environment for SD card? or requiring the user to stop the 
>> boot process and manually change the priority? Or what are you 
>> suggesting?
> 
> No, we don't need a different U-Boot, we can always set SD card boot 
> first in boot target in all case, if SD card don't have an available 
> firmware it will fall back to use eMMC, this works for the board I have.
> 
> Maybe I didn't understand correctly why you have to do "Swap mmc0 and 
> mmc1 in boot_targets if booted from SD-Card"?
> 

I think I got things mixed up and this was not a necessary discussion. 
But since we're here, I will try to explain what we want to do with the 
whole process on Theobroma's boards.

arch_env_get_location() is the only one impacted by this patch (as far 
as I could tell). setup_boottargets() from 
board/theobroma-systems/common/common.c is a vendor-specific 
implementation I do not see worthy of being merged to a code section 
used by all Rockchip boards, it's basically just a design/policy choice 
we made, but there's nothing interesting to make it the default (though 
it should be generic enough that one could simply call those functions 
from their board file and it should just work (tm)).

So the whole thing is basically about wanting a fallback mechanism.

Boot from TPL+SPL from SD card, if U-Boot proper available on SD card, 
load U-Boot proper from SD card, load environment from SD card (no 
fallback for the environment), **preferably** (if the default 
boot_target in default_environment is not different from the loaded 
environment, i.e. the user has NOT already modified it) load from the SD 
card the Image/dtb/fit and if not possible, then from eMMC, etc....

Boot from TPL+SPL from eMMC, if U-Boot proper available on eMMC, load 
U-Boot proper from eMMC, load environment from eMMC (no fallback for the 
environment), **preferably** (if the default boot_target in 
default_environment is not different from the loaded environment, i.e. 
the user has NOT already modified it) load from the eMMC the 
Image/dtb/fit and if not possible, then from SD card, etc....

Boot from TPL+SPL from SPI flash, if U-Boot proper available on SPI 
flash, load U-Boot proper from SPI flash, load environment from SPI 
flash (no fallback for the environment), use boot_targets from the 
environment (default or saved by user).

Boot from TPL+SPL from SPI flash, if U-Boot proper NOT available on SPI 
flash but eMMC, load U-Boot proper from eMMC, load environment from eMMC 
(no fallback for the environment), **preferably** (if the default 
boot_target in default_environment is not different from the loaded 
environment, i.e. the user has NOT already modified it) load from the 
eMMC the Image/dtb/fit and if not possible, then from SD card, etc....

Boot from TPL+SPL from SPI flash, if U-Boot proper NOT available on SPI 
flash but SD card, load U-Boot proper from SD card, load environment 
from SD card (no fallback for the environment), **preferably** (if the 
default boot_target in default_environment is not different from the 
loaded environment, i.e. the user has NOT already modified it) load from 
the SD card the Image/dtb/fit and if not possible, then from eMMC, etc....

Boot from TPL+SPL from eMMC, if U-Boot proper NOT available on eMMC but 
SPI flash, load U-Boot proper from SPI flash, load environment from SPI 
flash (no fallback for the environment), use boot_targets from the 
environment (default or saved by user).

Boot from TPL+SPL from eMMC, if U-Boot proper NOT available on eMMC but 
SD card, load U-Boot proper from SD card, load environment from SD card 
(no fallback for the environment), **preferably** (if the default 
boot_target in default_environment is not different from the loaded 
environment, i.e. the user has NOT already modified it) load from the SD 
card the Image/dtb/fit and if not possible, then from eMMC, etc....

Boot from TPL+SPL from SD card, if U-Boot proper NOT available on SD 
card but SPI flash, load U-Boot proper from SPI flash, load environment 
from SPI flash (no fallback for the environment), use boot_targets from 
the environment (default or saved by user).

Boot from TPL+SPL from SD card, if U-Boot proper NOT available on SD 
card but eMMC, load U-Boot proper from eMMC, load environment from eMMC 
(no fallback for the environment), **preferably** (if the default 
boot_target in default_environment is not different from the loaded 
environment, i.e. the user has NOT already modified it) load from the 
eMMC the Image/dtb/fit and if not possible, then from SD card, etc...


 > No, we don't need a different U-Boot, we can always set SD card boot
 > first in boot target in all case, if SD card don't have an available
 > firmware it will fall back to use eMMC, this works for the board I have.

If we do this, simply having an SD card with a partition with an 
Image/dtb/fit/extlinux.conf will be taken by default instead of the ones 
on the eMMC, even if we booted from the eMMC. I want to make sure that 
if I'm booting from the eMMC, I'm booting everything from the eMMC and 
not "if you have an SD card, maybe from the SD card". Why am I using 
U-Boot proper storage medium instead of the BootROM's? In case the 
customer didn't design the carrierboard for our System-on-Modules the 
same way we did for our devkit (Haikou) and forgot to add a bypass for 
the eMMC, AND their eMMC has TPL+SPL working but somehow got their 
U-Boot proper corrupted/not found. In which case, we can insert an SD 
card and load U-Boot proper from it for recovery. In which case, I want 
to boot stuff from the SD card and not the eMMC. We could also imagine 
some kind of "built-in" recovery mechanism for some admittedly very 
corner-case scenarios, where we would have an SD card with everything 
needed to reflash the board (e.g. swupdate/rauc/mender) that would only 
work if we cannot boot TPL+SPL from eMMC or U-Boot proper from eMMC.

>>
>> It all boils down to sane defaults. If I understand correctly, you 
>> want people to have systems which can boot really fast by default but 
>> don't mind if people need to tinker to get things working properly. I 
>> would prefer to have most things working by default and let people 
>> tinker to make things faster.
> 
> :(
> 
> Then I would say you didin't understand correctly.
> 
> I agree to let people tinker to make things faster and most things work 
> by default, but don't make too many troubles for tinker if possible.
> 

What is suggested here can be reverted with two lines in the appropriate 
-u-boot.dtsi, I would find this acceptable for tinkerers (but well... 
**I** would not need to do this with the current patch, so maybe I'm 
biased :) ).

>>
>> There are a couple of drivers that are selected when using Rockchip 
>> boards that shouldn't be necessary, e.g. ADC support, SPI flash 
>> controller (to name the few that we have on RK3588 that we don't need 
>> for Jaguar now), there are also DT nodes that are enabled by default 
>> in rk3588(s)-u-boot.dtsi that aren't necessary for my use case, this 
>> also increases the size of the DTB. I don't really get where you want 
>> the line between convenience and speed be right now. It'd be nice to 
>> have some kind of consensus/guideline if you already have one in mind, 
>> at least I'd know where we want to go with this :)
> 
> I never said we can't enable pre-reloc the emmc in rk3588 u-boot dt, 
> that's not the key point.
> 
> You add this patch to make arch_env_get_location() work, I suggest that 
> if we don't really access to emmc,
> 
> then update arch_env_get_location() might be better.
> 

I cannot do what was suggested (see beginning of the mail) sadly.

However, I started to look into having arch_env_get_location() behave 
differently before and after relocation (since it's called multiple 
times). I was able to have some proof-of-concept but I read more about 
env_init() and.... it makes me very anxious to do it this way.

1) I would expect there's some kind of expectations that what 
arch_env_get_location() doesn't change between calls with the same prio, 
which I would be breaking. Even if there's maybe no such expectation, 
this relies too much on the current state of env_init() and later 
updates to that function may break stuff. Not great.

2) I do not understand what this env_init() is supposed to do. It 
iterates over all possible env drivers and call their init callback, 
which sets the gd->env_addr/gd->env_valid global variable structure... 
but if the last env driver sets gd->env_addr to 0xbebe for example and 
the env driver that the first (and ONLY!) env driver that successfully 
can load (env_load()) should be using 0xcafe.... we may have some issue 
there :) Though that point isn't really related to the discussion we 
were having, rather what I found/didn't understand while trying to 
implement your suggestion. I've started to discuss this with Marek Vasut 
on IRC, maybe this will lead somewhere interesting :)

> If it's not able to update arch_env_get_location because it doesn't 
> work, then this patch is able to accept,
> 
> and I would suggest arch_env_get_location() to leave in 
> board/theobroma-systems/common/common.c.
> 

Yes, I agree. I do not think it is a good idea to have 
arch_env_get_location() currently in 
board/theobroma-systems/common/common.c for all Rockchip boards. It's 
just that I need this patch (or a version of it) so that 
arch_env_get_location() in board/theobroma-systems/common/common.c works.

Why I am advocating for having this in rk3588s-u-boot.dtsi is because:
- I think that anything that is done with the environment before 
relocation may need this? So if something calls e.g. env_load before 
relocation, it would need the mmc controllers to be available before 
relocation as well?
- being consistent between all Rockchip SoCs,

Lemme know if you have any question/remark.

Cheers,
Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Kever Yang]

Hi Quentin,

On 2024/1/27 00:18, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/26/24 11:56, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/26 17:32, Quentin Schulz wrote:
>>> Hi Kever,
>>>
>>> On 1/26/24 09:58, Kever Yang wrote:
>>>> Hi Quentin,
>>>>
>>>> On 2024/1/24 19:04, Quentin Schulz wrote:
>>>>> Hi Kever,
>>>>>
>>>>> On 1/24/24 11:35, Kever Yang wrote:
>>>>>> Hi Quentin,
>>>>>>
>>>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>>>
>>>>>>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram 
>>>>>>> node as
>>>>>>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot 
>>>>>>> proper
>>>>>>> bind the device before relocation.
>>>>>>>
>>>>>>> While this is usually not much of an issue, it is when there's a 
>>>>>>> lookup
>>>>>>> for devices by code running before the relocation. Such is the 
>>>>>>> case of
>>>>>>> env_init() which calls env_driver_lookup() which calls
>>>>>>> env_get_location() which is a weak symbol and may call
>>>>>>> arch_env_get_location() also a weak symbol. Those are two 
>>>>>>> functions that
>>>>>>> may traverse UCLASS to find some devices (e.g.
>>>>>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>>>>>
>>>>>> This sounds like we need to update arch_env_get_location() 
>>>>>> instead of enable mmc driver
>>>>>>
>>>>>> before relocate, because you we don't really need the mmc driver 
>>>>>> works here, there is no
>>>>>>
>>>>>> access requirement to mmc at this point, right?
>>>>>>
>>>>>
>>>>> All Rockchip SoCs except RK3588(S) and RK356x have it done this 
>>>>> way, a little bit of consistency wouldn't hurt :)
>>>>
>>>> My point is not about you can not enabe the emmc before relocate, 
>>>> maybe I'm not clear enough for the reason.
>>>>
>>>> All the driver bind/probed before the relocation will have to do 
>>>> the init sequence again later after relocation.
>>>>
>>>> The emmc driver cost pretty much time at init, we should avoid to 
>>>> duplicate the init process if possible.
>>>>
>>>> For this patch, you want to make it pre-relocate because you want 
>>>> to make sure the emmc is available for ENVL_MMC,
>>>>
>>>> but there is no read or write requirement to the emmc at this 
>>>> point, which means we don't have to init the emmc at this point,
>>>>
>>>> maybe we can check if the driver is enable if enough.
>>>>
>>>
>>> Now I need to know which SoC we are booting at build time so I can 
>>> check which drivers are supposed to be built, check those symbols 
>>> are enabled, then traverse the Device Tree with hardcoded DT node to 
>>> locations of MMC, SPI flash controllers, check if those are enabled 
>>> and finger-cross that those drivers will actually bind/probe 
>>> properly later on. That's A LOT of checks to be made.
>>
>> This is not what I want to say.
>>
>> What I mean is something  like this for arch_env_get_location() is 
>> enough, you don't have to bind/probe the emmc for env.
>>
>> 1623                 if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) && 
>> IS_ENABLED(CONFIG_MMC))
>> 1624                         return ENVL_MMC;
>>
>
> I do need to know if the device we loaded U-Boot proper from is an MMC 
> device or a SPI flash, so this is not enough for arch_env_get_location().
>
> I could do it in a hack-ish way though and check if the U-Boot proper 
> load medium DT node name starts with /mmc, or /spi and if neither, 
> then return NOWHERE, but then we lose the ability of returning NOWHERE 
> if the driver wasn't compiled in or the device didn't bind in 
> pre-reloc, we're missing some failsafe mechanism I could have with 
> this patch :)
>
> [...]
>
>>>> For the feature record "spl-boot-device" in SPL and read in out in 
>>>> U-Boot proper, and then Swap mmc0 and mmc1 in boot_targets if 
>>>> booted from SD-Card.
>>>>
>>>> It's OK for Theobroma-Systems's board to enable it, but seems not 
>>>> also required by other boards.
>>>>
>>>> Usually we consider the system in two stage: bootloader/BIOS 
>>>> stage(including all firmware before kernel) and OS stage(including 
>>>> kernel and Linux/Android OS),
>>>>
>>>> and for those boards(eg. PC like) do have two different storage 
>>>> medium, they put bootloader in SPI flash and put OS firmware in 
>>>> other storage like emmc/SSD/SDcard.
>>>>
>>>> In this case the U-Boot boot target does not need to know where 
>>>> it's from;
>>>>
>>>> in another case which supports firmware update from SD card, the 
>>>> U-Boot boot target needs to set SDCard as highest priority, also no 
>>>> need to know where the U-Boot from.
>>>>
>>>
>>> So... this means we need a different U-Boot if we're booting from SD 
>>> card so it can know which boot target to use by default? Or a 
>>> different environment for SD card? or requiring the user to stop the 
>>> boot process and manually change the priority? Or what are you 
>>> suggesting?
>>
>> No, we don't need a different U-Boot, we can always set SD card boot 
>> first in boot target in all case, if SD card don't have an available 
>> firmware it will fall back to use eMMC, this works for the board I have.
>>
>> Maybe I didn't understand correctly why you have to do "Swap mmc0 and 
>> mmc1 in boot_targets if booted from SD-Card"?
>>
>
> I think I got things mixed up and this was not a necessary discussion. 
> But since we're here, I will try to explain what we want to do with 
> the whole process on Theobroma's boards.
>
> arch_env_get_location() is the only one impacted by this patch (as far 
> as I could tell). setup_boottargets() from 
> board/theobroma-systems/common/common.c is a vendor-specific 
> implementation I do not see worthy of being merged to a code section 
> used by all Rockchip boards, it's basically just a design/policy 
> choice we made, but there's nothing interesting to make it the default 
> (though it should be generic enough that one could simply call those 
> functions from their board file and it should just work (tm)).
>
> So the whole thing is basically about wanting a fallback mechanism.

I can understand this purpose, but it seems you make it a little bit 
complicate, does your customers understand this? Or maybe you don't need 
customer to understand all these rules?

This rule is simple for rk3588 vendor SDK:

Bootrom default order is: SPI -> eMMC-> SDcard ->USB(can chose only one 
of it now for rk3588)

SPL default order is: SDcard ->SPI-> eMMC (SDcard is set to higher 
priority, only if there is a uboot partition and available firmware)

U-Boot default order is: SDcard -> eMMC (usually not using SPI for system)

If SDcard has no firmware, then it don't affect the boot flow; if the 
SDcard has available firmware, it means a firmware update need for 
eMMC/SPI. Since the SDcard is removal, we can make and replace it again 
which always fallback available if SPI/eMMC has something wring in 
U-Boot/System.

>
> Boot from TPL+SPL from SD card, if U-Boot proper available on SD card, 
> load U-Boot proper from SD card, load environment from SD card (no 
> fallback for the environment), **preferably** (if the default 
> boot_target in default_environment is not different from the loaded 
> environment, i.e. the user has NOT already modified it) load from the 
> SD card the Image/dtb/fit and if not possible, then from eMMC, etc....
>
> Boot from TPL+SPL from eMMC, if U-Boot proper available on eMMC, load 
> U-Boot proper from eMMC, load environment from eMMC (no fallback for 
> the environment), **preferably** (if the default boot_target in 
> default_environment is not different from the loaded environment, i.e. 
> the user has NOT already modified it) load from the eMMC the 
> Image/dtb/fit and if not possible, then from SD card, etc....
>
> Boot from TPL+SPL from SPI flash, if U-Boot proper available on SPI 
> flash, load U-Boot proper from SPI flash, load environment from SPI 
> flash (no fallback for the environment), use boot_targets from the 
> environment (default or saved by user).
>
> Boot from TPL+SPL from SPI flash, if U-Boot proper NOT available on 
> SPI flash but eMMC, load U-Boot proper from eMMC, load environment 
> from eMMC (no fallback for the environment), **preferably** (if the 
> default boot_target in default_environment is not different from the 
> loaded environment, i.e. the user has NOT already modified it) load 
> from the eMMC the Image/dtb/fit and if not possible, then from SD 
> card, etc....
>
> Boot from TPL+SPL from SPI flash, if U-Boot proper NOT available on 
> SPI flash but SD card, load U-Boot proper from SD card, load 
> environment from SD card (no fallback for the environment), 
> **preferably** (if the default boot_target in default_environment is 
> not different from the loaded environment, i.e. the user has NOT 
> already modified it) load from the SD card the Image/dtb/fit and if 
> not possible, then from eMMC, etc....
>
> Boot from TPL+SPL from eMMC, if U-Boot proper NOT available on eMMC 
> but SPI flash, load U-Boot proper from SPI flash, load environment 
> from SPI flash (no fallback for the environment), use boot_targets 
> from the environment (default or saved by user).
>
> Boot from TPL+SPL from eMMC, if U-Boot proper NOT available on eMMC 
> but SD card, load U-Boot proper from SD card, load environment from SD 
> card (no fallback for the environment), **preferably** (if the default 
> boot_target in default_environment is not different from the loaded 
> environment, i.e. the user has NOT already modified it) load from the 
> SD card the Image/dtb/fit and if not possible, then from eMMC, etc....
>
> Boot from TPL+SPL from SD card, if U-Boot proper NOT available on SD 
> card but SPI flash, load U-Boot proper from SPI flash, load 
> environment from SPI flash (no fallback for the environment), use 
> boot_targets from the environment (default or saved by user).
>
> Boot from TPL+SPL from SD card, if U-Boot proper NOT available on SD 
> card but eMMC, load U-Boot proper from eMMC, load environment from 
> eMMC (no fallback for the environment), **preferably** (if the default 
> boot_target in default_environment is not different from the loaded 
> environment, i.e. the user has NOT already modified it) load from the 
> eMMC the Image/dtb/fit and if not possible, then from SD card, etc...
>
>
> > No, we don't need a different U-Boot, we can always set SD card boot
> > first in boot target in all case, if SD card don't have an available
> > firmware it will fall back to use eMMC, this works for the board I 
> have.
>
> If we do this, simply having an SD card with a partition with an 
> Image/dtb/fit/extlinux.conf will be taken by default instead of the 
> ones on the eMMC, even if we booted from the eMMC. I want to make sure 
> that if I'm booting from the eMMC, I'm booting everything from the 
> eMMC and not "if you have an SD card, maybe from the SD card". 

In this case if U-Boot/kernel get panic in eMMC image, the system not 
able to recovery?

Anyway, you have your choice, since all these are stay in your board and 
not affect other boards, it's OK to be accept(the little addition 
-u-boot-dtsi  is fine).


Thanks,

- Kever

> Why am I using U-Boot proper storage medium instead of the BootROM's? 
> In case the customer didn't design the carrierboard for our 
> System-on-Modules the same way we did for our devkit (Haikou) and 
> forgot to add a bypass for the eMMC, AND their eMMC has TPL+SPL 
> working but somehow got their U-Boot proper corrupted/not found. In 
> which case, we can insert an SD card and load U-Boot proper from it 
> for recovery. In which case, I want to boot stuff from the SD card and 
> not the eMMC. We could also imagine some kind of "built-in" recovery 
> mechanism for some admittedly very corner-case scenarios, where we 
> would have an SD card with everything needed to reflash the board 
> (e.g. swupdate/rauc/mender) that would only work if we cannot boot 
> TPL+SPL from eMMC or U-Boot proper from eMMC.
>
>>>
>>> It all boils down to sane defaults. If I understand correctly, you 
>>> want people to have systems which can boot really fast by default 
>>> but don't mind if people need to tinker to get things working 
>>> properly. I would prefer to have most things working by default and 
>>> let people tinker to make things faster.
>>
>> :(
>>
>> Then I would say you didin't understand correctly.
>>
>> I agree to let people tinker to make things faster and most things 
>> work by default, but don't make too many troubles for tinker if 
>> possible.
>>
>
> What is suggested here can be reverted with two lines in the 
> appropriate -u-boot.dtsi, I would find this acceptable for tinkerers 
> (but well... **I** would not need to do this with the current patch, 
> so maybe I'm biased :) ).
>
>>>
>>> There are a couple of drivers that are selected when using Rockchip 
>>> boards that shouldn't be necessary, e.g. ADC support, SPI flash 
>>> controller (to name the few that we have on RK3588 that we don't 
>>> need for Jaguar now), there are also DT nodes that are enabled by 
>>> default in rk3588(s)-u-boot.dtsi that aren't necessary for my use 
>>> case, this also increases the size of the DTB. I don't really get 
>>> where you want the line between convenience and speed be right now. 
>>> It'd be nice to have some kind of consensus/guideline if you already 
>>> have one in mind, at least I'd know where we want to go with this :)
>>
>> I never said we can't enable pre-reloc the emmc in rk3588 u-boot dt, 
>> that's not the key point.
>>
>> You add this patch to make arch_env_get_location() work, I suggest 
>> that if we don't really access to emmc,
>>
>> then update arch_env_get_location() might be better.
>>
>
> I cannot do what was suggested (see beginning of the mail) sadly.
>
> However, I started to look into having arch_env_get_location() behave 
> differently before and after relocation (since it's called multiple 
> times). I was able to have some proof-of-concept but I read more about 
> env_init() and.... it makes me very anxious to do it this way.
>
> 1) I would expect there's some kind of expectations that what 
> arch_env_get_location() doesn't change between calls with the same 
> prio, which I would be breaking. Even if there's maybe no such 
> expectation, this relies too much on the current state of env_init() 
> and later updates to that function may break stuff. Not great.
>
> 2) I do not understand what this env_init() is supposed to do. It 
> iterates over all possible env drivers and call their init callback, 
> which sets the gd->env_addr/gd->env_valid global variable structure... 
> but if the last env driver sets gd->env_addr to 0xbebe for example and 
> the env driver that the first (and ONLY!) env driver that successfully 
> can load (env_load()) should be using 0xcafe.... we may have some 
> issue there :) Though that point isn't really related to the 
> discussion we were having, rather what I found/didn't understand while 
> trying to implement your suggestion. I've started to discuss this with 
> Marek Vasut on IRC, maybe this will lead somewhere interesting :)
>
>> If it's not able to update arch_env_get_location because it doesn't 
>> work, then this patch is able to accept,
>>
>> and I would suggest arch_env_get_location() to leave in 
>> board/theobroma-systems/common/common.c.
>>
>
> Yes, I agree. I do not think it is a good idea to have 
> arch_env_get_location() currently in 
> board/theobroma-systems/common/common.c for all Rockchip boards. It's 
> just that I need this patch (or a version of it) so that 
> arch_env_get_location() in board/theobroma-systems/common/common.c works.
>
> Why I am advocating for having this in rk3588s-u-boot.dtsi is because:
> - I think that anything that is done with the environment before 
> relocation may need this? So if something calls e.g. env_load before 
> relocation, it would need the mmc controllers to be available before 
> relocation as well?
> - being consistent between all Rockchip SoCs,
>
> Lemme know if you have any question/remark.
>
> Cheers,
> Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Quentin Schulz]

Hi Kever,

On 1/29/24 11:35, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/27 00:18, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 1/26/24 11:56, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/1/26 17:32, Quentin Schulz wrote:
>>>> Hi Kever,
>>>>
>>>> On 1/26/24 09:58, Kever Yang wrote:
>>>>> Hi Quentin,
>>>>>
>>>>> On 2024/1/24 19:04, Quentin Schulz wrote:
>>>>>> Hi Kever,
>>>>>>
>>>>>> On 1/24/24 11:35, Kever Yang wrote:
>>>>>>> Hi Quentin,
>>>>>>>
>>>>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>>>>
>>>>>>>> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram 
>>>>>>>> node as
>>>>>>>> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot 
>>>>>>>> proper
>>>>>>>> bind the device before relocation.
>>>>>>>>
>>>>>>>> While this is usually not much of an issue, it is when there's a 
>>>>>>>> lookup
>>>>>>>> for devices by code running before the relocation. Such is the 
>>>>>>>> case of
>>>>>>>> env_init() which calls env_driver_lookup() which calls
>>>>>>>> env_get_location() which is a weak symbol and may call
>>>>>>>> arch_env_get_location() also a weak symbol. Those are two 
>>>>>>>> functions that
>>>>>>>> may traverse UCLASS to find some devices (e.g.
>>>>>>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>>>>>>
>>>>>>> This sounds like we need to update arch_env_get_location() 
>>>>>>> instead of enable mmc driver
>>>>>>>
>>>>>>> before relocate, because you we don't really need the mmc driver 
>>>>>>> works here, there is no
>>>>>>>
>>>>>>> access requirement to mmc at this point, right?
>>>>>>>
>>>>>>
>>>>>> All Rockchip SoCs except RK3588(S) and RK356x have it done this 
>>>>>> way, a little bit of consistency wouldn't hurt :)
>>>>>
>>>>> My point is not about you can not enabe the emmc before relocate, 
>>>>> maybe I'm not clear enough for the reason.
>>>>>
>>>>> All the driver bind/probed before the relocation will have to do 
>>>>> the init sequence again later after relocation.
>>>>>
>>>>> The emmc driver cost pretty much time at init, we should avoid to 
>>>>> duplicate the init process if possible.
>>>>>
>>>>> For this patch, you want to make it pre-relocate because you want 
>>>>> to make sure the emmc is available for ENVL_MMC,
>>>>>
>>>>> but there is no read or write requirement to the emmc at this 
>>>>> point, which means we don't have to init the emmc at this point,
>>>>>
>>>>> maybe we can check if the driver is enable if enough.
>>>>>
>>>>
>>>> Now I need to know which SoC we are booting at build time so I can 
>>>> check which drivers are supposed to be built, check those symbols 
>>>> are enabled, then traverse the Device Tree with hardcoded DT node to 
>>>> locations of MMC, SPI flash controllers, check if those are enabled 
>>>> and finger-cross that those drivers will actually bind/probe 
>>>> properly later on. That's A LOT of checks to be made.
>>>
>>> This is not what I want to say.
>>>
>>> What I mean is something  like this for arch_env_get_location() is 
>>> enough, you don't have to bind/probe the emmc for env.
>>>
>>> 1623                 if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) && 
>>> IS_ENABLED(CONFIG_MMC))
>>> 1624                         return ENVL_MMC;
>>>
>>
>> I do need to know if the device we loaded U-Boot proper from is an MMC 
>> device or a SPI flash, so this is not enough for arch_env_get_location().
>>
>> I could do it in a hack-ish way though and check if the U-Boot proper 
>> load medium DT node name starts with /mmc, or /spi and if neither, 
>> then return NOWHERE, but then we lose the ability of returning NOWHERE 
>> if the driver wasn't compiled in or the device didn't bind in 
>> pre-reloc, we're missing some failsafe mechanism I could have with 
>> this patch :)
>>
>> [...]
>>
>>>>> For the feature record "spl-boot-device" in SPL and read in out in 
>>>>> U-Boot proper, and then Swap mmc0 and mmc1 in boot_targets if 
>>>>> booted from SD-Card.
>>>>>
>>>>> It's OK for Theobroma-Systems's board to enable it, but seems not 
>>>>> also required by other boards.
>>>>>
>>>>> Usually we consider the system in two stage: bootloader/BIOS 
>>>>> stage(including all firmware before kernel) and OS stage(including 
>>>>> kernel and Linux/Android OS),
>>>>>
>>>>> and for those boards(eg. PC like) do have two different storage 
>>>>> medium, they put bootloader in SPI flash and put OS firmware in 
>>>>> other storage like emmc/SSD/SDcard.
>>>>>
>>>>> In this case the U-Boot boot target does not need to know where 
>>>>> it's from;
>>>>>
>>>>> in another case which supports firmware update from SD card, the 
>>>>> U-Boot boot target needs to set SDCard as highest priority, also no 
>>>>> need to know where the U-Boot from.
>>>>>
>>>>
>>>> So... this means we need a different U-Boot if we're booting from SD 
>>>> card so it can know which boot target to use by default? Or a 
>>>> different environment for SD card? or requiring the user to stop the 
>>>> boot process and manually change the priority? Or what are you 
>>>> suggesting?
>>>
>>> No, we don't need a different U-Boot, we can always set SD card boot 
>>> first in boot target in all case, if SD card don't have an available 
>>> firmware it will fall back to use eMMC, this works for the board I have.
>>>
>>> Maybe I didn't understand correctly why you have to do "Swap mmc0 and 
>>> mmc1 in boot_targets if booted from SD-Card"?
>>>
>>
>> I think I got things mixed up and this was not a necessary discussion. 
>> But since we're here, I will try to explain what we want to do with 
>> the whole process on Theobroma's boards.
>>
>> arch_env_get_location() is the only one impacted by this patch (as far 
>> as I could tell). setup_boottargets() from 
>> board/theobroma-systems/common/common.c is a vendor-specific 
>> implementation I do not see worthy of being merged to a code section 
>> used by all Rockchip boards, it's basically just a design/policy 
>> choice we made, but there's nothing interesting to make it the default 
>> (though it should be generic enough that one could simply call those 
>> functions from their board file and it should just work (tm)).
>>
>> So the whole thing is basically about wanting a fallback mechanism.
> 
> I can understand this purpose, but it seems you make it a little bit 
> complicate, does your customers understand this? Or maybe you don't need 
> customer to understand all these rules?
> 

I haven't received any complaint so far.

If our customers want to do something differently, they can always 
change the code so that it works for them the way they want it to work, 
or even simply just change boot_targets in their environment if only the 
kernel+dtb image storage medium is what they care about. For our three 
SoMs, I see U-Boot as supported for our SoMs with our devkit, with other 
carrierboards a different U-Boot is likely required anyway.

> This rule is simple for rk3588 vendor SDK:
> 
> Bootrom default order is: SPI -> eMMC-> SDcard ->USB(can chose only one 
> of it now for rk3588)
> 
> SPL default order is: SDcard ->SPI-> eMMC (SDcard is set to higher 
> priority, only if there is a uboot partition and available firmware)
> 
> U-Boot default order is: SDcard -> eMMC (usually not using SPI for system)
> 
> If SDcard has no firmware, then it don't affect the boot flow; if the 
> SDcard has available firmware, it means a firmware update need for 
> eMMC/SPI. Since the SDcard is removal, we can make and replace it again 
> which always fallback available if SPI/eMMC has something wring in 
> U-Boot/System.
> 

I know, and I've received multiple complaints from colleagues about this 
already. There's a LOT of benefits from knowing that in the scenario in 
which everything is properly flashed, everything is loaded from the same 
medium. I myself have been surprised a few times as to why when I 
flashed the eMMC and have an old SD card connected it boots the U-Boot 
proper from the SD card and not from the eMMC.

I appreciate what we're doing is not everyone's cup of tea, but it works 
for us for now, so I don't see a need to revisit this logic.

[...]

>> > No, we don't need a different U-Boot, we can always set SD card boot
>> > first in boot target in all case, if SD card don't have an available
>> > firmware it will fall back to use eMMC, this works for the board I 
>> have.
>>
>> If we do this, simply having an SD card with a partition with an 
>> Image/dtb/fit/extlinux.conf will be taken by default instead of the 
>> ones on the eMMC, even if we booted from the eMMC. I want to make sure 
>> that if I'm booting from the eMMC, I'm booting everything from the 
>> eMMC and not "if you have an SD card, maybe from the SD card". 
> 
> In this case if U-Boot/kernel get panic in eMMC image, the system not 
> able to recovery?
> 

What happens if the SD card image is the one that panics? You also won't 
be able to recover... except if you remove the SD card entirely.

For us, if the eMMC U-Boot proper/kernel image is found but panics, you 
insert an SD card and you hold the BIOS button when booting, then 
everything will be booted from the SD card, otherwise it's booting from 
the eMMC.

In both cases a human is required to intervene, either to insert and 
remove the SD card to start a recovery, or to press the BIOS button. For 
Jaguar specifically, inserting and removing the SD card is not fun (it 
may also be hidden below an adapter (commonly called "hat" I think?) 
making its access even more difficult).

And again, this is the **default**, if a user changes it in the 
environment (to e.g. match the Rockchip SDK behavior), we will not 
change it automatically.

> Anyway, you have your choice, since all these are stay in your board and 
> not affect other boards, it's OK to be accept(the little addition 
> -u-boot-dtsi  is fine).
> 

I am a bit confused.

Where do you want the sdmmc/sdhci controllers bootph-all property be put:
1) rk3588s-u-boot.dtsi
2) rk3588-jaguar-u-boot.dtsi

?

Cheers,
Quentin

Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Kever Yang]

On 2024/2/1 01:55, Quentin Schulz wrote:
> Hi Kever,
>
> On 1/29/24 11:35, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/1/27 00:18, Quentin Schulz wrote:
>>> Hi Kever,
>>>
>>> On 1/26/24 11:56, Kever Yang wrote:
>>>> Hi Quentin,
>>>>
>>>> On 2024/1/26 17:32, Quentin Schulz wrote:
>>>>> Hi Kever,
>>>>>
>>>>> On 1/26/24 09:58, Kever Yang wrote:
>>>>>> Hi Quentin,
>>>>>>
>>>>>> On 2024/1/24 19:04, Quentin Schulz wrote:
>>>>>>> Hi Kever,
>>>>>>>
>>>>>>> On 1/24/24 11:35, Kever Yang wrote:
>>>>>>>> Hi Quentin,
>>>>>>>>
>>>>>>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>>>>>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>>>>>>>
>>>>>>>>> Since commit 9e644284ab81 ("dm: core: Report 
>>>>>>>>> bootph-pre-ram/sram node as
>>>>>>>>> pre-reloc after relocation"), bootph-pre-ram doesn't make 
>>>>>>>>> U-Boot proper
>>>>>>>>> bind the device before relocation.
>>>>>>>>>
>>>>>>>>> While this is usually not much of an issue, it is when there's 
>>>>>>>>> a lookup
>>>>>>>>> for devices by code running before the relocation. Such is the 
>>>>>>>>> case of
>>>>>>>>> env_init() which calls env_driver_lookup() which calls
>>>>>>>>> env_get_location() which is a weak symbol and may call
>>>>>>>>> arch_env_get_location() also a weak symbol. Those are two 
>>>>>>>>> functions that
>>>>>>>>> may traverse UCLASS to find some devices (e.g.
>>>>>>>>> board/theobroma-systems/common/common.c:arch_env_get_location()).
>>>>>>>>
>>>>>>>> This sounds like we need to update arch_env_get_location() 
>>>>>>>> instead of enable mmc driver
>>>>>>>>
>>>>>>>> before relocate, because you we don't really need the mmc 
>>>>>>>> driver works here, there is no
>>>>>>>>
>>>>>>>> access requirement to mmc at this point, right?
>>>>>>>>
>>>>>>>
>>>>>>> All Rockchip SoCs except RK3588(S) and RK356x have it done this 
>>>>>>> way, a little bit of consistency wouldn't hurt :)
>>>>>>
>>>>>> My point is not about you can not enabe the emmc before relocate, 
>>>>>> maybe I'm not clear enough for the reason.
>>>>>>
>>>>>> All the driver bind/probed before the relocation will have to do 
>>>>>> the init sequence again later after relocation.
>>>>>>
>>>>>> The emmc driver cost pretty much time at init, we should avoid to 
>>>>>> duplicate the init process if possible.
>>>>>>
>>>>>> For this patch, you want to make it pre-relocate because you want 
>>>>>> to make sure the emmc is available for ENVL_MMC,
>>>>>>
>>>>>> but there is no read or write requirement to the emmc at this 
>>>>>> point, which means we don't have to init the emmc at this point,
>>>>>>
>>>>>> maybe we can check if the driver is enable if enough.
>>>>>>
>>>>>
>>>>> Now I need to know which SoC we are booting at build time so I can 
>>>>> check which drivers are supposed to be built, check those symbols 
>>>>> are enabled, then traverse the Device Tree with hardcoded DT node 
>>>>> to locations of MMC, SPI flash controllers, check if those are 
>>>>> enabled and finger-cross that those drivers will actually 
>>>>> bind/probe properly later on. That's A LOT of checks to be made.
>>>>
>>>> This is not what I want to say.
>>>>
>>>> What I mean is something  like this for arch_env_get_location() is 
>>>> enough, you don't have to bind/probe the emmc for env.
>>>>
>>>> 1623                 if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) && 
>>>> IS_ENABLED(CONFIG_MMC))
>>>> 1624                         return ENVL_MMC;
>>>>
>>>
>>> I do need to know if the device we loaded U-Boot proper from is an 
>>> MMC device or a SPI flash, so this is not enough for 
>>> arch_env_get_location().
>>>
>>> I could do it in a hack-ish way though and check if the U-Boot 
>>> proper load medium DT node name starts with /mmc, or /spi and if 
>>> neither, then return NOWHERE, but then we lose the ability of 
>>> returning NOWHERE if the driver wasn't compiled in or the device 
>>> didn't bind in pre-reloc, we're missing some failsafe mechanism I 
>>> could have with this patch :)
>>>
>>> [...]
>>>
>>>>>> For the feature record "spl-boot-device" in SPL and read in out 
>>>>>> in U-Boot proper, and then Swap mmc0 and mmc1 in boot_targets if 
>>>>>> booted from SD-Card.
>>>>>>
>>>>>> It's OK for Theobroma-Systems's board to enable it, but seems not 
>>>>>> also required by other boards.
>>>>>>
>>>>>> Usually we consider the system in two stage: bootloader/BIOS 
>>>>>> stage(including all firmware before kernel) and OS 
>>>>>> stage(including kernel and Linux/Android OS),
>>>>>>
>>>>>> and for those boards(eg. PC like) do have two different storage 
>>>>>> medium, they put bootloader in SPI flash and put OS firmware in 
>>>>>> other storage like emmc/SSD/SDcard.
>>>>>>
>>>>>> In this case the U-Boot boot target does not need to know where 
>>>>>> it's from;
>>>>>>
>>>>>> in another case which supports firmware update from SD card, the 
>>>>>> U-Boot boot target needs to set SDCard as highest priority, also 
>>>>>> no need to know where the U-Boot from.
>>>>>>
>>>>>
>>>>> So... this means we need a different U-Boot if we're booting from 
>>>>> SD card so it can know which boot target to use by default? Or a 
>>>>> different environment for SD card? or requiring the user to stop 
>>>>> the boot process and manually change the priority? Or what are you 
>>>>> suggesting?
>>>>
>>>> No, we don't need a different U-Boot, we can always set SD card 
>>>> boot first in boot target in all case, if SD card don't have an 
>>>> available firmware it will fall back to use eMMC, this works for 
>>>> the board I have.
>>>>
>>>> Maybe I didn't understand correctly why you have to do "Swap mmc0 
>>>> and mmc1 in boot_targets if booted from SD-Card"?
>>>>
>>>
>>> I think I got things mixed up and this was not a necessary 
>>> discussion. But since we're here, I will try to explain what we want 
>>> to do with the whole process on Theobroma's boards.
>>>
>>> arch_env_get_location() is the only one impacted by this patch (as 
>>> far as I could tell). setup_boottargets() from 
>>> board/theobroma-systems/common/common.c is a vendor-specific 
>>> implementation I do not see worthy of being merged to a code section 
>>> used by all Rockchip boards, it's basically just a design/policy 
>>> choice we made, but there's nothing interesting to make it the 
>>> default (though it should be generic enough that one could simply 
>>> call those functions from their board file and it should just work 
>>> (tm)).
>>>
>>> So the whole thing is basically about wanting a fallback mechanism.
>>
>> I can understand this purpose, but it seems you make it a little bit 
>> complicate, does your customers understand this? Or maybe you don't 
>> need customer to understand all these rules?
>>
>
> I haven't received any complaint so far.
>
> If our customers want to do something differently, they can always 
> change the code so that it works for them the way they want it to 
> work, or even simply just change boot_targets in their environment if 
> only the kernel+dtb image storage medium is what they care about. For 
> our three SoMs, I see U-Boot as supported for our SoMs with our 
> devkit, with other carrierboards a different U-Boot is likely required 
> anyway.
>
>> This rule is simple for rk3588 vendor SDK:
>>
>> Bootrom default order is: SPI -> eMMC-> SDcard ->USB(can chose only 
>> one of it now for rk3588)
>>
>> SPL default order is: SDcard ->SPI-> eMMC (SDcard is set to higher 
>> priority, only if there is a uboot partition and available firmware)
>>
>> U-Boot default order is: SDcard -> eMMC (usually not using SPI for 
>> system)
>>
>> If SDcard has no firmware, then it don't affect the boot flow; if the 
>> SDcard has available firmware, it means a firmware update need for 
>> eMMC/SPI. Since the SDcard is removal, we can make and replace it 
>> again which always fallback available if SPI/eMMC has something wring 
>> in U-Boot/System.
>>
>
> I know, and I've received multiple complaints from colleagues about 
> this already. There's a LOT of benefits from knowing that in the 
> scenario in which everything is properly flashed, everything is loaded 
> from the same medium. I myself have been surprised a few times as to 
> why when I flashed the eMMC and have an old SD card connected it boots 
> the U-Boot proper from the SD card and not from the eMMC.
>
> I appreciate what we're doing is not everyone's cup of tea, but it 
> works for us for now, so I don't see a need to revisit this logic.
>
> [...]
>
>>> > No, we don't need a different U-Boot, we can always set SD card boot
>>> > first in boot target in all case, if SD card don't have an available
>>> > firmware it will fall back to use eMMC, this works for the board I 
>>> have.
>>>
>>> If we do this, simply having an SD card with a partition with an 
>>> Image/dtb/fit/extlinux.conf will be taken by default instead of the 
>>> ones on the eMMC, even if we booted from the eMMC. I want to make 
>>> sure that if I'm booting from the eMMC, I'm booting everything from 
>>> the eMMC and not "if you have an SD card, maybe from the SD card". 
>>
>> In this case if U-Boot/kernel get panic in eMMC image, the system not 
>> able to recovery?
>>
>
> What happens if the SD card image is the one that panics? You also 
> won't be able to recover... except if you remove the SD card entirely.

If SD card image get panic, we can easily remove and make it again.

I know why you do this now, because the removal of SD card is not so 
"easy" in your system, and you are not using SD card as external storage 
like tablet/SBCs.

>
> For us, if the eMMC U-Boot proper/kernel image is found but panics, 
> you insert an SD card and you hold the BIOS button when booting, then 
> everything will be booted from the SD card, otherwise it's booting 
> from the eMMC.
>
> In both cases a human is required to intervene, either to insert and 
> remove the SD card to start a recovery, or to press the BIOS button. 
> For Jaguar specifically, inserting and removing the SD card is not fun 
> (it may also be hidden below an adapter (commonly called "hat" I 
> think?) making its access even more difficult).
>
> And again, this is the **default**, if a user changes it in the 
> environment (to e.g. match the Rockchip SDK behavior), we will not 
> change it automatically.
>
>> Anyway, you have your choice, since all these are stay in your board 
>> and not affect other boards, it's OK to be accept(the little addition 
>> -u-boot-dtsi  is fine).
>>
>
> I am a bit confused.
>
> Where do you want the sdmmc/sdhci controllers bootph-all property be put:
> 1) rk3588s-u-boot.dtsi

It's OK to put it here.


Thanks,

- Kever

> 2) rk3588-jaguar-u-boot.dtsi
>
> ?
>
> Cheers,
> Quentin

[PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
is targeting Autonomous Mobile Robots (AMR).

It features:
 * LPDDR4X (up to 16GB)
 * 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
 * PCIe 3.0 4-lane on M.2 M-key connector
 * PCIe 2.1 1-lane on M.2 E-key
 * USB 2.0 on M.2 E-key
 * 2x USB3 OTG type-c ports with DP Alt-Mode
 * USB2 host port
 * HDMI output
 * 2x camera connectors, each exposing:
   * 2-lane MIPI-CSI
   * 1v2, 1v8, 2v8 power rails
   * I2C bus
   * GPIOs
 * PPS input
 * CAN
 * RS485 UART
 * FAN connector
 * SD card slot
 * eMMC (up to 256GB)
 * RTC backup battery
 * Companion microcontroller
   * ISL1208 RTC emulation
   * AMC6821 PWM emulation
   * On/off buzzer control
 * Secure Element
 * 80-pin Mezzanine connector for daughterboards:
   * GPIOs
   * 1Gbps Ethernet
   * PCIe 2.1 1-lane
   * 2x 2-lane MIPI-CSI
   * ADC channel
   * I2C bus
   * PWM
   * UART
   * SPI
   * SDIO
   * CAN
   * I2S
   * 1v8, 3v3, 5v0, dc-in (12-24V) power rails

The Device Tree comes from next-20240110 Linux kernel.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rk3588-jaguar-u-boot.dtsi             |  32 +
 arch/arm/dts/rk3588-jaguar.dts                     | 803 +++++++++++++++++++++
 arch/arm/mach-rockchip/rk3588/Kconfig              |  28 +
 board/theobroma-systems/jaguar_rk3588/Kconfig      |  16 +
 board/theobroma-systems/jaguar_rk3588/MAINTAINERS  |  12 +
 board/theobroma-systems/jaguar_rk3588/Makefile     |  10 +
 board/theobroma-systems/jaguar_rk3588/README       | 118 +++
 .../jaguar_rk3588/jaguar_rk3588.c                  |  52 ++
 configs/jaguar-rk3588_defconfig                    | 115 +++
 include/configs/jaguar_rk3588.h                    |  15 +
 10 files changed, 1201 insertions(+)

diff --git a/arch/arm/dts/rk3588-jaguar-u-boot.dtsi b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
new file mode 100644
index 00000000000..59a3f9b41a9
--- /dev/null
+++ b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include "rk3588-u-boot.dtsi"
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/usb/pd.h>
+
+/ {
+	chosen {
+		u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
+	};
+};
+
+&emmc_pwrseq {
+	bootph-all;
+};
+
+&emmc_reset {
+	bootph-all;
+};
+
+&gpio0 {
+	bootph-all;
+};
+
+&gpio2 {
+	bootph-all;
+};
diff --git a/arch/arm/dts/rk3588-jaguar.dts b/arch/arm/dts/rk3588-jaguar.dts
new file mode 100644
index 00000000000..4ce70fb75a3
--- /dev/null
+++ b/arch/arm/dts/rk3588-jaguar.dts
@@ -0,0 +1,803 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3588.dtsi"
+
+/ {
+	model = "Theobroma Systems RK3588-SBC Jaguar";
+	compatible = "tsd,rk3588-jaguar", "rockchip,rk3588";
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		/* Can be controlled through SW2 but also GPIO1 on CP2102 on P20 */
+		button-bios-disable {
+			label = "BIOS_DISABLE";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	aliases {
+		ethernet0 = &gmac0;
+		mmc0 = &sdhci;
+		mmc1 = &sdmmc;
+		rtc0 = &rtc_twi;
+	};
+
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	/* DCIN is 12-24V but standard is 12V */
+	dc_12v: dc-12v-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	emmc_pwrseq: emmc-pwrseq {
+		compatible = "mmc-pwrseq-emmc";
+		pinctrl-0 = <&emmc_reset>;
+		pinctrl-names = "default";
+		reset-gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led1_pin>;
+		status = "okay";
+
+		/* LED1 on PCB */
+		led-1 {
+			gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+			function = LED_FUNCTION_HEARTBEAT;
+			linux,default-trigger = "heartbeat";
+			color = <LED_COLOR_ID_AMBER>;
+		};
+	};
+
+	pps {
+		compatible = "pps-gpio";
+		gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v2_s3: vcc-1v2-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v2_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* Exposed on P14 and P15 */
+	vcc_2v8_s3: vcc-2v8-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_2v8_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_5v0_usb_a: vcc-5v0-usb-a-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_a_vcc";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+		gpio = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vcc_5v0_usb_c1: vcc-5v0-usb-c1-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "5v_usbc1";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+		gpio = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vcc_5v0_usb_c2: vcc-5v0-usb-c2-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "5v_usbc2";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+		gpio = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vcc3v3_mdot2: vcc3v3-mdot2-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_mdot2";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii";
+	phy-supply = <&vcc_1v2_s3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_rx_bus2
+		     &gmac0_tx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus
+		     &eth0_pins
+		     &eth_reset>;
+	tx_delay = <0x10>;
+	rx_delay = <0x10>;
+	snps,reset-gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 100000>;
+
+	status = "okay";
+};
+
+&gpio1 {
+	mdot2e-w-disable1-n-hog {
+		gpios = <RK_PB1 GPIO_ACTIVE_LOW>;
+		output-low;
+		line-name = "m.2 E-key W_DISABLE1#";
+		gpio-hog;
+	};
+};
+
+&gpio4 {
+	mdot2e-w-disable2-n-hog {
+		gpios = <RK_PC1 GPIO_ACTIVE_LOW>;
+		output-low;
+		line-name = "m.2 E-key W_DISABLE2#";
+		gpio-hog;
+	};
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	fan@18 {
+		compatible = "ti,amc6821";
+		reg = <0x18>;
+	};
+
+	vdd_npu_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator@43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rtc_twi: rtc@6f {
+		compatible = "isil,isl1208";
+		reg = <0x6f>;
+	};
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1m4_xfer>;
+};
+
+&i2c6 {
+	pinctrl-0 = <&i2c6m4_xfer>;
+};
+
+&i2c7 {
+	status = "okay";
+
+	/* SE050 Secure Element at 0x48; GPIO1_A4 for enable pin */
+
+	/* Also on 0x55 */
+	eeprom@54 {
+		compatible = "st,24c04", "atmel,24c04";
+		reg = <0x54>;
+		pagesize = <16>;
+		vcc-supply = <&vcc_3v3_s3>;
+	};
+};
+
+&i2c8 {
+	pinctrl-0 = <&i2c8m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&mdio0 {
+	rgmii_phy: ethernet-phy@6 {
+		/* KSZ9031 or KSZ9131 */
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x6>;
+		clocks = <&cru REFCLKO25M_ETH0_OUT>;
+	};
+};
+
+&pcie2x1l0 {
+	reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>; /* WIFI_PERST0# */
+	vpcie3v3-supply = <&vcc3v3_mdot2>;
+	status = "okay";
+};
+
+&pinctrl {
+	emmc {
+		emmc_reset: emmc-reset {
+			rockchip,pins = <2 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	ethernet {
+		eth_reset: eth-reset {
+			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		led1_pin: led1-pin {
+			rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	mmc-pwrseq = <&emmc_pwrseq>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_data_strobe>;
+	supports-cqe;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vcc_1v8_s3>;
+	status = "okay";
+};
+
+&sdmmc {
+	broken-cd;
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_cmd &sdmmc_clk>;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr50;
+	sd-uhs-ddr50;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic@0 {
+		compatible = "rockchip,rk806";
+		reg = <0x0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+		system-power-controller;
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-name = "vdd_log_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vdd_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcca_1v8_s0: pldo-reg1 {
+				regulator-name = "vcca_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdda_1v2_s0: pldo-reg3 {
+				regulator-name = "vdda_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_3v3_s0: pldo-reg4 {
+				regulator-name = "vcca_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-name = "pldo6_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdda_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdda_0v75_s0: nldo-reg3 {
+				regulator-name = "vdda_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v85_s0: nldo-reg4 {
+				regulator-name = "vdda_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-name = "vdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc_5v0_usb_a>;
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy3_host {
+	status = "okay";
+};
+
+/* Mule-ATtiny debug UART; typically baudrate 9600 */
+&uart0 {
+	pinctrl-0 = <&uart0m0_xfer>;
+	status = "okay";
+};
+
+/* Main debug interface on P20 micro-USB B port and P21 header */
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+/* RS485 on P19 */
+&uart3 {
+	pinctrl-0 = <&uart3m2_xfer &uart3_rtsn>;
+	linux,rs485-enabled-at-boot-time;
+	status = "okay";
+};
+
+/* Mule-ATtiny UPDI flashing UART */
+&uart7 {
+	pinctrl-0 = <&uart7m0_xfer>;
+	status = "okay";
+};
+
+/* host0 on P10 USB-A */
+&usb_host0_ehci {
+	status = "okay";
+};
+
+/* host0 on P10 USB-A */
+&usb_host0_ohci {
+	status = "okay";
+};
+
+/* host1 on M.2 E-key */
+&usb_host1_ehci {
+	status = "okay";
+};
+
+/* host1 on M.2 E-key */
+&usb_host1_ohci {
+	status = "okay";
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig b/arch/arm/mach-rockchip/rk3588/Kconfig
index a2193fbd41f..34adb91335c 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -6,6 +6,33 @@ config TARGET_EVB_RK3588
 	help
 	  RK3588 EVB is a evaluation board for Rockchp RK3588.
 
+config TARGET_JAGUAR_RK3588
+	bool "Theobroma Systems SBC-RK3588-AMR (Jaguar)"
+	select BOARD_LATE_INIT
+	help
+	  The SBC-RK3588-AMR is a Single Board Computer designed by
+	  Theobroma Systems for autonomous mobile robots.
+
+	  It provides the following features:
+	    * up to 32GB LDDR4
+	    * up to 128GB on-module eMMC (with 8-bit 1.8V interface)
+	    * SD card
+	    * Gigabit Ethernet
+	    * 1x USB-A 2.0 host
+	    * PCIe M.2 2230 Key M (Gen 2 1-lane) for WiFI+BT
+	    * PCIe M.2 2280 Key M (Gen 3 4-lane) for NVMe
+	    * CAN
+	    * RS485 UART
+	    * 2x USB Type-C 3.1 host/device
+	    * HDMI output
+	    * 2x camera connectors (MIPI-CSI 2-lane + I2C/SPI for IMUs + GPIOs)
+	    * EEPROM
+	    * Secure Element
+	    * ATtiny companion controller implementing:
+	      - low-power RTC functionality (ISL1208 emulation)
+	      - fan controller (AMC6821 emulation)
+	    * 80-pin Mezzanine connector
+
 config TARGET_NANOPCT6_RK3588
 	bool "FriendlyElec NanoPC-T6 RK3588 board"
 	select BOARD_LATE_INIT
@@ -174,5 +201,6 @@ source board/turing/turing-rk1-rk3588/Kconfig
 source board/rockchip/evb_rk3588/Kconfig
 source board/radxa/rock5a-rk3588s/Kconfig
 source board/radxa/rock5b-rk3588/Kconfig
+source board/theobroma-systems/jaguar_rk3588/Kconfig
 
 endif
diff --git a/board/theobroma-systems/jaguar_rk3588/Kconfig b/board/theobroma-systems/jaguar_rk3588/Kconfig
new file mode 100644
index 00000000000..0ff417af4dd
--- /dev/null
+++ b/board/theobroma-systems/jaguar_rk3588/Kconfig
@@ -0,0 +1,16 @@
+if TARGET_JAGUAR_RK3588
+
+config SYS_BOARD
+	default "jaguar_rk3588"
+
+config SYS_VENDOR
+	default "theobroma-systems"
+
+config SYS_CONFIG_NAME
+	default "jaguar_rk3588"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+	def_bool y
+	select ENV_IS_NOWHERE
+
+endif
diff --git a/board/theobroma-systems/jaguar_rk3588/MAINTAINERS b/board/theobroma-systems/jaguar_rk3588/MAINTAINERS
new file mode 100644
index 00000000000..9eb6effe5d4
--- /dev/null
+++ b/board/theobroma-systems/jaguar_rk3588/MAINTAINERS
@@ -0,0 +1,12 @@
+JAGUAR-RK3588 (SBC-RK3588-AMR Single Board Computer)
+M:	Klaus Goger <klaus.goger@theobroma-systems.com>
+M:	Quentin Schulz <quentin.schulz@theobroma-systems.com>
+M:	Heiko Stuebner <heiko.stuebner@cherry.de>
+S:	Maintained
+F:	board/theobroma-systems/jaguar_rk3588
+F:	board/theobroma-systems/common
+F:	include/configs/jaguar_rk3588.h
+F:	arch/arm/dts/rk3588-jaguar*
+F:	configs/jaguar-rk3588_defconfig
+W:	https://theobroma-systems.com/product/jaguar-sbc-rk3588/
+T:	git git://git.theobroma-systems.com/jaguar-u-boot.git
diff --git a/board/theobroma-systems/jaguar_rk3588/Makefile b/board/theobroma-systems/jaguar_rk3588/Makefile
new file mode 100644
index 00000000000..532aab01532
--- /dev/null
+++ b/board/theobroma-systems/jaguar_rk3588/Makefile
@@ -0,0 +1,10 @@
+#
+# Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y += jaguar_rk3588.o
+ifneq ($(CONFIG_SPL_BUILD),y)
+obj-y	+= ../common/common.o
+endif
diff --git a/board/theobroma-systems/jaguar_rk3588/README b/board/theobroma-systems/jaguar_rk3588/README
new file mode 100644
index 00000000000..bb0fd11ed8c
--- /dev/null
+++ b/board/theobroma-systems/jaguar_rk3588/README
@@ -0,0 +1,118 @@
+Here is the step-by-step to boot to U-Boot on SBC-RK3588-AMR
+
+Get the TF-A and DDR init (TPL) binaries
+========================================
+
+  > git clone https://github.com/rockchip-linux/rkbin
+  > cd rkbin
+  > export RKBIN=$(pwd)
+  > export BL31=$RKBIN/bin/rk35/rk3588_bl31_v1.38.elf
+  > export ROCKCHIP_TPL=$RKBIN/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.11.bin
+  > sed -i 's/uart baudrate=/uart baudrate=115200/' tools/ddrbin_param.txt
+  > ./tools/ddrbin_tool tools/ddrbin_param.txt "$ROCKCHIP_TPL"
+  > ./tools/boot_merger RKBOOT/RK3588MINIALL.ini
+  > export RKDB=$RKBIN/rk3588_spl_loader_v1.11.112.bin
+
+Configure U-Boot
+================
+
+  > cd ../u-boot
+  > make CROSS_COMPILE=aarch64-linux-gnu- jaguar-rk3588_defconfig all
+
+Flash the image
+===============
+
+Copy u-boot-rockchip.bin to offset 32k for SD/eMMC.
+
+SD-Card
+-------
+
+  > dd if=u-boot-rockchip.bin of=/dev/sdb seek=64
+
+eMMC
+----
+
+rkdeveloptool allows to flash the on-board eMMC via the USB OTG interface with
+help of the Rockchip loader binary.
+
+To enter the USB flashing mode, remove any SD card, insert a USB-C cable in the
+DOWNLOAD USB Type-C connector (P11) and then power cycle or reset the board
+while pressing the BIOS (SW2) button. A new USB device should have appeared on
+your PC (check with `lsusb -d 2207:350b`).
+
+To flash U-Boot on the eMMC with rkdeveloptool:
+
+  > git clone https://github.com/rockchip-linux/rkdeveloptool
+  > cd rkdeveloptool
+  > autoreconf -i && CPPFLAGS=-Wno-format-truncation ./configure && make
+  > ./rkdeveloptool db "$RKDB"
+  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
+
+
+If everything went according to plan, you should see the following
+output on P20 micro-USB port (baudrate 115200):
+
+DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
+LPDDR4X, 2112MHz
+channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
+channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
+channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
+channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
+Manufacturer ID:0x1
+CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
+CH1 RX Vref:30.5%, TX Vref:20.8%,0.0%
+CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
+CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
+change to F1: 528MHz
+change to F2: 1068MHz
+change to F3: 1560MHz
+change to F0: 2112MHz
+out
+
+U-Boot SPL 2024.01-00028-gbe8ef1601aa-dirty (Jan 17 2024 - 19:56:41 +0100)
+Trying to boot from MMC1
+## Checking hash(es) for config config-1 ... OK
+## Checking hash(es) for Image atf-1 ... sha256+ OK
+## Checking hash(es) for Image u-boot ... sha256+ OK
+## Checking hash(es) for Image fdt-1 ... sha256+ OK
+## Checking hash(es) for Image atf-2 ... sha256+ OK
+## Checking hash(es) for Image atf-3 ... sha256+ OK
+INFO:    Preloader serial: 2
+NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
+NOTICE:  BL31: Built : 10:14:29, May  9 2023
+INFO:    spec: 0x1
+INFO:    ext 32k is not valid
+INFO:    ddr: stride-en 4CH
+INFO:    GICv3 without legacy support detected.
+INFO:    ARM GICv3 driver initialized in EL3
+INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
+INFO:    system boots from cpu-hwid-0
+INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
+INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
+INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
+INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
+INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
+INFO:    BL31: Initialising Exception Handling Framework
+INFO:    BL31: Initializing runtime services
+WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
+ERROR:   Error initializing runtime service opteed_fast
+INFO:    BL31: Preparing for EL3 exit to normal world
+INFO:    Entry point address = 0xa00000
+INFO:    SPSR = 0x3c9
+
+
+U-Boot 2024.01-00028-gbe8ef1601aa-dirty (Jan 17 2024 - 19:56:41 +0100)
+
+Model: Theobroma Systems RK3588-SBC Jaguar
+DRAM:  4 GiB (effective 3.7 GiB)
+Core:  348 devices, 29 uclasses, devicetree: separate
+MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
+Loading Environment from MMC... *** Warning - bad CRC, using default environment
+
+In:    serial@feb50000
+Out:   serial@feb50000
+Err:   serial@feb50000
+Model: Theobroma Systems RK3588-SBC Jaguar
+Net:   eth0: ethernet@fe1b0000
+Hit any key to stop autoboot:  0
+=>
diff --git a/board/theobroma-systems/jaguar_rk3588/jaguar_rk3588.c b/board/theobroma-systems/jaguar_rk3588/jaguar_rk3588.c
new file mode 100644
index 00000000000..3f96c4c500f
--- /dev/null
+++ b/board/theobroma-systems/jaguar_rk3588/jaguar_rk3588.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include <asm/types.h>
+#include <asm-generic/u-boot.h>
+#include <phy.h>
+#include <eth_phy.h>
+#include <dm/uclass-id.h>
+#include <dm/device.h>
+#include <asm/arch-rockchip/cru_rk3588.h>
+#include <asm/arch-rockchip/ioc_rk3588.h>
+#include <asm/arch-rockchip/hardware.h>
+#include "../common/common.h"
+
+#define GPIO2C3_SEL_OFFSET		12
+#define GPIO2C3_SEL_MASK		GENMASK(15, GPIO2C3_SEL_OFFSET)
+#define GPIO2C3_ETH0_REFCLKO_25M	(0x1 << GPIO2C3_SEL_OFFSET)
+
+#define REFCLKO25M_ETH0_OUT_SEL_MASK	BIT(15)
+#define REFCLKO25M_ETH0_OUT_SEL_CPLL	BIT(15)
+#define REFCLKO25M_ETH0_OUT_DIV_OFFSET	8
+#define REFCLKO25M_ETH0_OUT_DIV_MASK	GENMASK(14, REFCLKO25M_ETH0_OUT_DIV_OFFSET)
+#define REFCLKO25M_ETH0_OUT_DIV(x)	((((x) - 1) << REFCLKO25M_ETH0_OUT_DIV_OFFSET) & REFCLKO25M_ETH0_OUT_DIV_MASK)
+
+#define REFCLKO25M_ETH0_OUT_EN		BIT(4)
+
+void setup_eth0refclko(void)
+{
+	/* Configure and enable ETH0_REFCLKO_25MHz */
+	static struct rk3588_bus_ioc * const bus_ioc = (void *)BUS_IOC_BASE;
+	static struct rk3588_cru * const cru = (void *)CRU_BASE;
+
+	/* 1. Pinmux */
+	rk_clrsetreg(&bus_ioc->gpio2c_iomux_sel_l, GPIO2C3_SEL_MASK, GPIO2C3_ETH0_REFCLKO_25M);
+	/* 2. Parent clock selection + divider => CPLL (1.5GHz) / 60 => 25MHz */
+	rk_clrsetreg(&cru->clksel_con[15],
+		     REFCLKO25M_ETH0_OUT_SEL_MASK | REFCLKO25M_ETH0_OUT_DIV_MASK,
+		     REFCLKO25M_ETH0_OUT_SEL_CPLL | REFCLKO25M_ETH0_OUT_DIV(60));
+	/* 3. Enable clock */
+	rk_clrreg(&cru->clkgate_con[5], REFCLKO25M_ETH0_OUT_EN);
+}
+
+int rockchip_early_misc_init_r(void)
+{
+	setup_boottargets();
+
+	setup_eth0refclko();
+
+	return 0;
+}
diff --git a/configs/jaguar-rk3588_defconfig b/configs/jaguar-rk3588_defconfig
new file mode 100644
index 00000000000..ab550f16263
--- /dev/null
+++ b/configs/jaguar-rk3588_defconfig
@@ -0,0 +1,115 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=24000000
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_TEXT_BASE=0x00a00000
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
+CONFIG_SF_DEFAULT_SPEED=24000000
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_ENV_SIZE=0x1f000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588-jaguar"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x600000
+CONFIG_TARGET_JAGUAR_RK3588=y
+CONFIG_SPL_STACK=0x400000
+CONFIG_DEBUG_UART_BASE=0xfeb50000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+# CONFIG_BOOTMETH_VBE is not set
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-jaguar.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_CYCLIC=y
+CONFIG_SPL_MAX_SIZE=0x40000
+CONFIG_SPL_PAD_TO=0x7f8000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x4000000
+CONFIG_SPL_BSS_MAX_SIZE=0x4000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_ATF=y
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_CMD_ELF is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+# CONFIG_CMD_SF is not set
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_CMD_MII is not set
+# CONFIG_CMD_BLOCK_CACHE is not set
+# CONFIG_CMD_EFICONFIG is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_EROFS=y
+CONFIG_CMD_SQUASHFS=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+# CONFIG_OF_TAG_MIGRATE is not set
+CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+# CONFIG_SARADC_ROCKCHIP is not set
+CONFIG_SPL_CLK=y
+CONFIG_CLK_GPIO=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_SPL_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS400_ES_SUPPORT=y
+CONFIG_SPL_MMC_HS400_ES_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=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_SPI_FLASH is not set
+CONFIG_SF_DEFAULT_BUS=5
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_SPL_RAM=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_GENERIC=y
+CONFIG_ERRNO_STR=y
diff --git a/include/configs/jaguar_rk3588.h b/include/configs/jaguar_rk3588.h
new file mode 100644
index 00000000000..843028c5385
--- /dev/null
+++ b/include/configs/jaguar_rk3588.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+#ifndef __JAGUAR_RK3588_H
+#define __JAGUAR_RK3588_H
+
+#define ROCKCHIP_DEVICE_SETTINGS \
+		"stdout=serial,vidconsole\0" \
+		"stderr=serial,vidconsole\0"
+
+#include <configs/rk3588_common.h>
+
+#endif /* __JAGUAR_RK3588_H */

-- 
2.43.0

Re: [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC

[Quentin Schulz]

Hi all,

On 1/23/24 15:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
> is targeting Autonomous Mobile Robots (AMR).
> 
> It features:
>   * LPDDR4X (up to 16GB)
>   * 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
>   * PCIe 3.0 4-lane on M.2 M-key connector
>   * PCIe 2.1 1-lane on M.2 E-key
>   * USB 2.0 on M.2 E-key
>   * 2x USB3 OTG type-c ports with DP Alt-Mode
>   * USB2 host port
>   * HDMI output
>   * 2x camera connectors, each exposing:
>     * 2-lane MIPI-CSI
>     * 1v2, 1v8, 2v8 power rails
>     * I2C bus
>     * GPIOs
>   * PPS input
>   * CAN
>   * RS485 UART
>   * FAN connector
>   * SD card slot
>   * eMMC (up to 256GB)
>   * RTC backup battery
>   * Companion microcontroller
>     * ISL1208 RTC emulation
>     * AMC6821 PWM emulation
>     * On/off buzzer control
>   * Secure Element
>   * 80-pin Mezzanine connector for daughterboards:
>     * GPIOs
>     * 1Gbps Ethernet
>     * PCIe 2.1 1-lane
>     * 2x 2-lane MIPI-CSI
>     * ADC channel
>     * I2C bus
>     * PWM
>     * UART
>     * SPI
>     * SDIO
>     * CAN
>     * I2S
>     * 1v8, 3v3, 5v0, dc-in (12-24V) power rails
> 
> The Device Tree comes from next-20240110 Linux kernel.
> 
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---

I forgot to add the dtb rule to arch/arm/dts/Makefile but it still 
compiles somehow... Will give a few days to people to review the rest 
before sending a v2 to avoid too much unnecessary noise on the list.

Cheers,
Quentin

Re: [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC

[Kever Yang]

On 2024/1/23 22:49, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
> is targeting Autonomous Mobile Robots (AMR).
>
> It features:
>   * LPDDR4X (up to 16GB)
>   * 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
>   * PCIe 3.0 4-lane on M.2 M-key connector
>   * PCIe 2.1 1-lane on M.2 E-key
>   * USB 2.0 on M.2 E-key
>   * 2x USB3 OTG type-c ports with DP Alt-Mode
>   * USB2 host port
>   * HDMI output
>   * 2x camera connectors, each exposing:
>     * 2-lane MIPI-CSI
>     * 1v2, 1v8, 2v8 power rails
>     * I2C bus
>     * GPIOs
>   * PPS input
>   * CAN
>   * RS485 UART
>   * FAN connector
>   * SD card slot
>   * eMMC (up to 256GB)
>   * RTC backup battery
>   * Companion microcontroller
>     * ISL1208 RTC emulation
>     * AMC6821 PWM emulation
>     * On/off buzzer control
>   * Secure Element
>   * 80-pin Mezzanine connector for daughterboards:
>     * GPIOs
>     * 1Gbps Ethernet
>     * PCIe 2.1 1-lane
>     * 2x 2-lane MIPI-CSI
>     * ADC channel
>     * I2C bus
>     * PWM
>     * UART
>     * SPI
>     * SDIO
>     * CAN
>     * I2S
>     * 1v8, 3v3, 5v0, dc-in (12-24V) power rails
>
> The Device Tree comes from next-20240110 Linux kernel.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>   arch/arm/dts/rk3588-jaguar-u-boot.dtsi             |  32 +
>   arch/arm/dts/rk3588-jaguar.dts                     | 803 +++++++++++++++++++++
>   arch/arm/mach-rockchip/rk3588/Kconfig              |  28 +
>   board/theobroma-systems/jaguar_rk3588/Kconfig      |  16 +
>   board/theobroma-systems/jaguar_rk3588/MAINTAINERS  |  12 +
>   board/theobroma-systems/jaguar_rk3588/Makefile     |  10 +
>   board/theobroma-systems/jaguar_rk3588/README       | 118 +++

One thing you need to update is that, Tom is asking the document to 
convert to RsT format,

so it would be better to move the board README to  doc/board/ in .rst 
format.


Thanks,
- Kever
>   .../jaguar_rk3588/jaguar_rk3588.c                  |  52 ++
>   configs/jaguar-rk3588_defconfig                    | 115 +++
>   include/configs/jaguar_rk3588.h                    |  15 +
>   10 files changed, 1201 insertions(+)
>
> diff --git a/arch/arm/dts/rk3588-jaguar-u-boot.dtsi b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
> new file mode 100644
> index 00000000000..59a3f9b41a9
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
> + */
> +
> +#include "rk3588-u-boot.dtsi"
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/usb/pd.h>
> +
> +/ {
> +	chosen {
> +		u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
> +	};
> +};
> +
> +&emmc_pwrseq {
> +	bootph-all;
> +};
> +
> +&emmc_reset {
> +	bootph-all;
> +};
> +
> +&gpio0 {
> +	bootph-all;
> +};
> +
> +&gpio2 {
> +	bootph-all;
> +};
> diff --git a/arch/arm/dts/rk3588-jaguar.dts b/arch/arm/dts/rk3588-jaguar.dts
> new file mode 100644
> index 00000000000..4ce70fb75a3
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-jaguar.dts
> @@ -0,0 +1,803 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/usb/pd.h>
> +#include "rk3588.dtsi"
> +
> +/ {
> +	model = "Theobroma Systems RK3588-SBC Jaguar";
> +	compatible = "tsd,rk3588-jaguar", "rockchip,rk3588";
> +
> +	adc-keys {
> +		compatible = "adc-keys";
> +		io-channels = <&saradc 0>;
> +		io-channel-names = "buttons";
> +		keyup-threshold-microvolt = <1800000>;
> +		poll-interval = <100>;
> +
> +		/* Can be controlled through SW2 but also GPIO1 on CP2102 on P20 */
> +		button-bios-disable {
> +			label = "BIOS_DISABLE";
> +			linux,code = <KEY_VENDOR>;
> +			press-threshold-microvolt = <0>;
> +		};
> +	};
> +
> +	aliases {
> +		ethernet0 = &gmac0;
> +		mmc0 = &sdhci;
> +		mmc1 = &sdmmc;
> +		rtc0 = &rtc_twi;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial2:115200n8";
> +	};
> +
> +	/* DCIN is 12-24V but standard is 12V */
> +	dc_12v: dc-12v-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "dc_12v";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +	};
> +
> +	emmc_pwrseq: emmc-pwrseq {
> +		compatible = "mmc-pwrseq-emmc";
> +		pinctrl-0 = <&emmc_reset>;
> +		pinctrl-names = "default";
> +		reset-gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&led1_pin>;
> +		status = "okay";
> +
> +		/* LED1 on PCB */
> +		led-1 {
> +			gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
> +			function = LED_FUNCTION_HEARTBEAT;
> +			linux,default-trigger = "heartbeat";
> +			color = <LED_COLOR_ID_AMBER>;
> +		};
> +	};
> +
> +	pps {
> +		compatible = "pps-gpio";
> +		gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_1v1_nldo_s3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1100000>;
> +		regulator-max-microvolt = <1100000>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +
> +	vcc_1v2_s3: vcc-1v2-s3-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_1v2_s3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1200000>;
> +		regulator-max-microvolt = <1200000>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +
> +	/* Exposed on P14 and P15 */
> +	vcc_2v8_s3: vcc-2v8-s3-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_2v8_s3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <2800000>;
> +		regulator-max-microvolt = <2800000>;
> +		vin-supply = <&vcc_3v3_s3>;
> +	};
> +
> +	vcc_5v0_usb_a: vcc-5v0-usb-a-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "usb_a_vcc";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_sys>;
> +		gpio = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
> +	vcc_5v0_usb_c1: vcc-5v0-usb-c1-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "5v_usbc1";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_usb>;
> +		gpio = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
> +	vcc_5v0_usb_c2: vcc-5v0-usb-c2-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "5v_usbc2";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_usb>;
> +		gpio = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
> +	vcc3v3_mdot2: vcc3v3-mdot2-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_mdot2";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&dc_12v>;
> +	};
> +
> +	vcc5v0_sys: vcc5v0-sys-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&dc_12v>;
> +	};
> +
> +	vcc5v0_usb: vcc5v0-usb-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_usb";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +};
> +
> +&combphy1_ps {
> +	status = "okay";
> +};
> +
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_big0_s0>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_big0_s0>;
> +};
> +
> +&cpu_b2 {
> +	cpu-supply = <&vdd_cpu_big1_s0>;
> +};
> +
> +&cpu_b3 {
> +	cpu-supply = <&vdd_cpu_big1_s0>;
> +};
> +
> +&cpu_l0 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&gmac0 {
> +	clock_in_out = "output";
> +	phy-handle = <&rgmii_phy>;
> +	phy-mode = "rgmii";
> +	phy-supply = <&vcc_1v2_s3>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&gmac0_miim
> +		     &gmac0_rx_bus2
> +		     &gmac0_tx_bus2
> +		     &gmac0_rgmii_clk
> +		     &gmac0_rgmii_bus
> +		     &eth0_pins
> +		     &eth_reset>;
> +	tx_delay = <0x10>;
> +	rx_delay = <0x10>;
> +	snps,reset-gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_LOW>;
> +	snps,reset-active-low;
> +	snps,reset-delays-us = <0 10000 100000>;
> +
> +	status = "okay";
> +};
> +
> +&gpio1 {
> +	mdot2e-w-disable1-n-hog {
> +		gpios = <RK_PB1 GPIO_ACTIVE_LOW>;
> +		output-low;
> +		line-name = "m.2 E-key W_DISABLE1#";
> +		gpio-hog;
> +	};
> +};
> +
> +&gpio4 {
> +	mdot2e-w-disable2-n-hog {
> +		gpios = <RK_PC1 GPIO_ACTIVE_LOW>;
> +		output-low;
> +		line-name = "m.2 E-key W_DISABLE2#";
> +		gpio-hog;
> +	};
> +};
> +
> +&i2c0 {
> +	pinctrl-0 = <&i2c0m2_xfer>;
> +	status = "okay";
> +
> +	fan@18 {
> +		compatible = "ti,amc6821";
> +		reg = <0x18>;
> +	};
> +
> +	vdd_npu_s0: regulator@42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_npu_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <950000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd_cpu_big1_s0: regulator@43 {
> +		compatible = "rockchip,rk8603", "rockchip,rk8602";
> +		reg = <0x43>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_big1_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <1050000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	rtc_twi: rtc@6f {
> +		compatible = "isil,isl1208";
> +		reg = <0x6f>;
> +	};
> +};
> +
> +&i2c1 {
> +	pinctrl-0 = <&i2c1m4_xfer>;
> +};
> +
> +&i2c6 {
> +	pinctrl-0 = <&i2c6m4_xfer>;
> +};
> +
> +&i2c7 {
> +	status = "okay";
> +
> +	/* SE050 Secure Element at 0x48; GPIO1_A4 for enable pin */
> +
> +	/* Also on 0x55 */
> +	eeprom@54 {
> +		compatible = "st,24c04", "atmel,24c04";
> +		reg = <0x54>;
> +		pagesize = <16>;
> +		vcc-supply = <&vcc_3v3_s3>;
> +	};
> +};
> +
> +&i2c8 {
> +	pinctrl-0 = <&i2c8m2_xfer>;
> +	status = "okay";
> +
> +	vdd_cpu_big0_s0: regulator@42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_big0_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <1050000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&mdio0 {
> +	rgmii_phy: ethernet-phy@6 {
> +		/* KSZ9031 or KSZ9131 */
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <0x6>;
> +		clocks = <&cru REFCLKO25M_ETH0_OUT>;
> +	};
> +};
> +
> +&pcie2x1l0 {
> +	reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>; /* WIFI_PERST0# */
> +	vpcie3v3-supply = <&vcc3v3_mdot2>;
> +	status = "okay";
> +};
> +
> +&pinctrl {
> +	emmc {
> +		emmc_reset: emmc-reset {
> +			rockchip,pins = <2 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	ethernet {
> +		eth_reset: eth-reset {
> +			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	leds {
> +		led1_pin: led1-pin {
> +			rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&saradc {
> +	vref-supply = <&vcc_1v8_s0>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	cap-mmc-highspeed;
> +	mmc-ddr-1_8v;
> +	mmc-hs200-1_8v;
> +	mmc-hs400-1_8v;
> +	mmc-hs400-enhanced-strobe;
> +	mmc-pwrseq = <&emmc_pwrseq>;
> +	no-sdio;
> +	no-sd;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_data_strobe>;
> +	supports-cqe;
> +	vmmc-supply = <&vcc_3v3_s3>;
> +	vqmmc-supply = <&vcc_1v8_s3>;
> +	status = "okay";
> +};
> +
> +&sdmmc {
> +	broken-cd;
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	disable-wp;
> +	max-frequency = <150000000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc_bus4 &sdmmc_cmd &sdmmc_clk>;
> +	sd-uhs-sdr12;
> +	sd-uhs-sdr25;
> +	sd-uhs-sdr50;
> +	sd-uhs-ddr50;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_3v3_s3>;
> +	vqmmc-supply = <&vccio_sd_s0>;
> +	status = "okay";
> +};
> +
> +&spi2 {
> +	assigned-clocks = <&cru CLK_SPI2>;
> +	assigned-clock-rates = <200000000>;
> +	num-cs = <1>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
> +	status = "okay";
> +
> +	pmic@0 {
> +		compatible = "rockchip,rk806";
> +		reg = <0x0>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
> +			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
> +		spi-max-frequency = <1000000>;
> +		system-power-controller;
> +		vcc1-supply = <&vcc5v0_sys>;
> +		vcc2-supply = <&vcc5v0_sys>;
> +		vcc3-supply = <&vcc5v0_sys>;
> +		vcc4-supply = <&vcc5v0_sys>;
> +		vcc5-supply = <&vcc5v0_sys>;
> +		vcc6-supply = <&vcc5v0_sys>;
> +		vcc7-supply = <&vcc5v0_sys>;
> +		vcc8-supply = <&vcc5v0_sys>;
> +		vcc9-supply = <&vcc5v0_sys>;
> +		vcc10-supply = <&vcc5v0_sys>;
> +		vcc11-supply = <&vcc_2v0_pldo_s3>;
> +		vcc12-supply = <&vcc5v0_sys>;
> +		vcc13-supply = <&vcc_1v1_nldo_s3>;
> +		vcc14-supply = <&vcc_1v1_nldo_s3>;
> +		vcca-supply = <&vcc5v0_sys>;
> +
> +		rk806_dvs1_null: dvs1-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};
> +
> +		rk806_dvs2_null: dvs2-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};
> +
> +		rk806_dvs3_null: dvs3-null-pins {
> +			pins = "gpio_pwrctrl3";
> +			function = "pin_fun0";
> +		};
> +
> +		regulators {
> +			vdd_gpu_s0: dcdc-reg1 {
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_gpu_s0";
> +				regulator-enable-ramp-delay = <400>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_cpu_lit_s0: dcdc-reg2 {
> +				regulator-name = "vdd_cpu_lit_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_log_s0: dcdc-reg3 {
> +				regulator-name = "vdd_log_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <675000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <750000>;
> +				};
> +			};
> +
> +			vdd_vdenc_s0: dcdc-reg4 {
> +				regulator-name = "vdd_vdenc_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_ddr_s0: dcdc-reg5 {
> +				regulator-name = "vdd_ddr_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <675000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <850000>;
> +				};
> +			};
> +
> +			vdd2_ddr_s3: dcdc-reg6 {
> +				regulator-name = "vdd2_ddr_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_2v0_pldo_s3: dcdc-reg7 {
> +				regulator-name = "vdd_2v0_pldo_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <2000000>;
> +				regulator-max-microvolt = <2000000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <2000000>;
> +				};
> +			};
> +
> +			vcc_3v3_s3: dcdc-reg8 {
> +				regulator-name = "vcc_3v3_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vddq_ddr_s0: dcdc-reg9 {
> +				regulator-name = "vddq_ddr_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8_s3: dcdc-reg10 {
> +				regulator-name = "vcc_1v8_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcca_1v8_s0: pldo-reg1 {
> +				regulator-name = "vcca_1v8_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8_s0: pldo-reg2 {
> +				regulator-name = "vcc_1v8_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vdda_1v2_s0: pldo-reg3 {
> +				regulator-name = "vdda_1v2_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1200000>;
> +				regulator-max-microvolt = <1200000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcca_3v3_s0: pldo-reg4 {
> +				regulator-name = "vcca_3v3_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vccio_sd_s0: pldo-reg5 {
> +				regulator-name = "vccio_sd_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-ramp-delay = <12500>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			pldo6_s3: pldo-reg6 {
> +				regulator-name = "pldo6_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vdd_0v75_s3: nldo-reg1 {
> +				regulator-name = "vdd_0v75_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <750000>;
> +				};
> +			};
> +
> +			vdda_ddr_pll_s0: nldo-reg2 {
> +				regulator-name = "vdda_ddr_pll_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <850000>;
> +				};
> +			};
> +
> +			vdda_0v75_s0: nldo-reg3 {
> +				regulator-name = "vdda_0v75_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdda_0v85_s0: nldo-reg4 {
> +				regulator-name = "vdda_0v85_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_0v75_s0: nldo-reg5 {
> +				regulator-name = "vdd_0v75_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&tsadc {
> +	status = "okay";
> +};
> +
> +&u2phy2 {
> +	status = "okay";
> +};
> +
> +&u2phy2_host {
> +	phy-supply = <&vcc_5v0_usb_a>;
> +	status = "okay";
> +};
> +
> +&u2phy3 {
> +	status = "okay";
> +};
> +
> +&u2phy3_host {
> +	status = "okay";
> +};
> +
> +/* Mule-ATtiny debug UART; typically baudrate 9600 */
> +&uart0 {
> +	pinctrl-0 = <&uart0m0_xfer>;
> +	status = "okay";
> +};
> +
> +/* Main debug interface on P20 micro-USB B port and P21 header */
> +&uart2 {
> +	pinctrl-0 = <&uart2m0_xfer>;
> +	status = "okay";
> +};
> +
> +/* RS485 on P19 */
> +&uart3 {
> +	pinctrl-0 = <&uart3m2_xfer &uart3_rtsn>;
> +	linux,rs485-enabled-at-boot-time;
> +	status = "okay";
> +};
> +
> +/* Mule-ATtiny UPDI flashing UART */
> +&uart7 {
> +	pinctrl-0 = <&uart7m0_xfer>;
> +	status = "okay";
> +};
> +
> +/* host0 on P10 USB-A */
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +/* host0 on P10 USB-A */
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +/* host1 on M.2 E-key */
> +&usb_host1_ehci {
> +	status = "okay";
> +};
> +
> +/* host1 on M.2 E-key */
> +&usb_host1_ohci {
> +	status = "okay";
> +};
> diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig b/arch/arm/mach-rockchip/rk3588/Kconfig
> index a2193fbd41f..34adb91335c 100644
> --- a/arch/arm/mach-rockchip/rk3588/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3588/Kconfig
> @@ -6,6 +6,33 @@ config TARGET_EVB_RK3588
>   	help
>   	  RK3588 EVB is a evaluation board for Rockchp RK3588.
>   
> +config TARGET_JAGUAR_RK3588
> +	bool "Theobroma Systems SBC-RK3588-AMR (Jaguar)"
> +	select BOARD_LATE_INIT
> +	help
> +	  The SBC-RK3588-AMR is a Single Board Computer designed by
> +	  Theobroma Systems for autonomous mobile robots.
> +
> +	  It provides the following features:
> +	    * up to 32GB LDDR4
> +	    * up to 128GB on-module eMMC (with 8-bit 1.8V interface)
> +	    * SD card
> +	    * Gigabit Ethernet
> +	    * 1x USB-A 2.0 host
> +	    * PCIe M.2 2230 Key M (Gen 2 1-lane) for WiFI+BT
> +	    * PCIe M.2 2280 Key M (Gen 3 4-lane) for NVMe
> +	    * CAN
> +	    * RS485 UART
> +	    * 2x USB Type-C 3.1 host/device
> +	    * HDMI output
> +	    * 2x camera connectors (MIPI-CSI 2-lane + I2C/SPI for IMUs + GPIOs)
> +	    * EEPROM
> +	    * Secure Element
> +	    * ATtiny companion controller implementing:
> +	      - low-power RTC functionality (ISL1208 emulation)
> +	      - fan controller (AMC6821 emulation)
> +	    * 80-pin Mezzanine connector
> +
>   config TARGET_NANOPCT6_RK3588
>   	bool "FriendlyElec NanoPC-T6 RK3588 board"
>   	select BOARD_LATE_INIT
> @@ -174,5 +201,6 @@ source board/turing/turing-rk1-rk3588/Kconfig
>   source board/rockchip/evb_rk3588/Kconfig
>   source board/radxa/rock5a-rk3588s/Kconfig
>   source board/radxa/rock5b-rk3588/Kconfig
> +source board/theobroma-systems/jaguar_rk3588/Kconfig
>   
>   endif
> diff --git a/board/theobroma-systems/jaguar_rk3588/Kconfig b/board/theobroma-systems/jaguar_rk3588/Kconfig
> new file mode 100644
> index 00000000000..0ff417af4dd
> --- /dev/null
> +++ b/board/theobroma-systems/jaguar_rk3588/Kconfig
> @@ -0,0 +1,16 @@
> +if TARGET_JAGUAR_RK3588
> +
> +config SYS_BOARD
> +	default "jaguar_rk3588"
> +
> +config SYS_VENDOR
> +	default "theobroma-systems"
> +
> +config SYS_CONFIG_NAME
> +	default "jaguar_rk3588"
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> +	def_bool y
> +	select ENV_IS_NOWHERE
> +
> +endif
> diff --git a/board/theobroma-systems/jaguar_rk3588/MAINTAINERS b/board/theobroma-systems/jaguar_rk3588/MAINTAINERS
> new file mode 100644
> index 00000000000..9eb6effe5d4
> --- /dev/null
> +++ b/board/theobroma-systems/jaguar_rk3588/MAINTAINERS
> @@ -0,0 +1,12 @@
> +JAGUAR-RK3588 (SBC-RK3588-AMR Single Board Computer)
> +M:	Klaus Goger <klaus.goger@theobroma-systems.com>
> +M:	Quentin Schulz <quentin.schulz@theobroma-systems.com>
> +M:	Heiko Stuebner <heiko.stuebner@cherry.de>
> +S:	Maintained
> +F:	board/theobroma-systems/jaguar_rk3588
> +F:	board/theobroma-systems/common
> +F:	include/configs/jaguar_rk3588.h
> +F:	arch/arm/dts/rk3588-jaguar*
> +F:	configs/jaguar-rk3588_defconfig
> +W:	https://theobroma-systems.com/product/jaguar-sbc-rk3588/
> +T:	git git://git.theobroma-systems.com/jaguar-u-boot.git
> diff --git a/board/theobroma-systems/jaguar_rk3588/Makefile b/board/theobroma-systems/jaguar_rk3588/Makefile
> new file mode 100644
> index 00000000000..532aab01532
> --- /dev/null
> +++ b/board/theobroma-systems/jaguar_rk3588/Makefile
> @@ -0,0 +1,10 @@
> +#
> +# Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
> +#
> +# SPDX-License-Identifier:	GPL-2.0+
> +#
> +
> +obj-y += jaguar_rk3588.o
> +ifneq ($(CONFIG_SPL_BUILD),y)
> +obj-y	+= ../common/common.o
> +endif
> diff --git a/board/theobroma-systems/jaguar_rk3588/README b/board/theobroma-systems/jaguar_rk3588/README
> new file mode 100644
> index 00000000000..bb0fd11ed8c
> --- /dev/null
> +++ b/board/theobroma-systems/jaguar_rk3588/README
> @@ -0,0 +1,118 @@
> +Here is the step-by-step to boot to U-Boot on SBC-RK3588-AMR
> +
> +Get the TF-A and DDR init (TPL) binaries
> +========================================
> +
> +  > git clone https://github.com/rockchip-linux/rkbin
> +  > cd rkbin
> +  > export RKBIN=$(pwd)
> +  > export BL31=$RKBIN/bin/rk35/rk3588_bl31_v1.38.elf
> +  > export ROCKCHIP_TPL=$RKBIN/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.11.bin
> +  > sed -i 's/uart baudrate=/uart baudrate=115200/' tools/ddrbin_param.txt
> +  > ./tools/ddrbin_tool tools/ddrbin_param.txt "$ROCKCHIP_TPL"
> +  > ./tools/boot_merger RKBOOT/RK3588MINIALL.ini
> +  > export RKDB=$RKBIN/rk3588_spl_loader_v1.11.112.bin
> +
> +Configure U-Boot
> +================
> +
> +  > cd ../u-boot
> +  > make CROSS_COMPILE=aarch64-linux-gnu- jaguar-rk3588_defconfig all
> +
> +Flash the image
> +===============
> +
> +Copy u-boot-rockchip.bin to offset 32k for SD/eMMC.
> +
> +SD-Card
> +-------
> +
> +  > dd if=u-boot-rockchip.bin of=/dev/sdb seek=64
> +
> +eMMC
> +----
> +
> +rkdeveloptool allows to flash the on-board eMMC via the USB OTG interface with
> +help of the Rockchip loader binary.
> +
> +To enter the USB flashing mode, remove any SD card, insert a USB-C cable in the
> +DOWNLOAD USB Type-C connector (P11) and then power cycle or reset the board
> +while pressing the BIOS (SW2) button. A new USB device should have appeared on
> +your PC (check with `lsusb -d 2207:350b`).
> +
> +To flash U-Boot on the eMMC with rkdeveloptool:
> +
> +  > git clone https://github.com/rockchip-linux/rkdeveloptool
> +  > cd rkdeveloptool
> +  > autoreconf -i && CPPFLAGS=-Wno-format-truncation ./configure && make
> +  > ./rkdeveloptool db "$RKDB"
> +  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
> +
> +
> +If everything went according to plan, you should see the following
> +output on P20 micro-USB port (baudrate 115200):
> +
> +DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
> +LPDDR4X, 2112MHz
> +channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> +channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> +channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> +channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
> +Manufacturer ID:0x1
> +CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
> +CH1 RX Vref:30.5%, TX Vref:20.8%,0.0%
> +CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
> +CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
> +change to F1: 528MHz
> +change to F2: 1068MHz
> +change to F3: 1560MHz
> +change to F0: 2112MHz
> +out
> +
> +U-Boot SPL 2024.01-00028-gbe8ef1601aa-dirty (Jan 17 2024 - 19:56:41 +0100)
> +Trying to boot from MMC1
> +## Checking hash(es) for config config-1 ... OK
> +## Checking hash(es) for Image atf-1 ... sha256+ OK
> +## Checking hash(es) for Image u-boot ... sha256+ OK
> +## Checking hash(es) for Image fdt-1 ... sha256+ OK
> +## Checking hash(es) for Image atf-2 ... sha256+ OK
> +## Checking hash(es) for Image atf-3 ... sha256+ OK
> +INFO:    Preloader serial: 2
> +NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
> +NOTICE:  BL31: Built : 10:14:29, May  9 2023
> +INFO:    spec: 0x1
> +INFO:    ext 32k is not valid
> +INFO:    ddr: stride-en 4CH
> +INFO:    GICv3 without legacy support detected.
> +INFO:    ARM GICv3 driver initialized in EL3
> +INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
> +INFO:    system boots from cpu-hwid-0
> +INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
> +INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
> +INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
> +INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
> +INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
> +INFO:    BL31: Initialising Exception Handling Framework
> +INFO:    BL31: Initializing runtime services
> +WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
> +ERROR:   Error initializing runtime service opteed_fast
> +INFO:    BL31: Preparing for EL3 exit to normal world
> +INFO:    Entry point address = 0xa00000
> +INFO:    SPSR = 0x3c9
> +
> +
> +U-Boot 2024.01-00028-gbe8ef1601aa-dirty (Jan 17 2024 - 19:56:41 +0100)
> +
> +Model: Theobroma Systems RK3588-SBC Jaguar
> +DRAM:  4 GiB (effective 3.7 GiB)
> +Core:  348 devices, 29 uclasses, devicetree: separate
> +MMC:   mmc@fe2c0000: 1, mmc@fe2e0000: 0
> +Loading Environment from MMC... *** Warning - bad CRC, using default environment
> +
> +In:    serial@feb50000
> +Out:   serial@feb50000
> +Err:   serial@feb50000
> +Model: Theobroma Systems RK3588-SBC Jaguar
> +Net:   eth0: ethernet@fe1b0000
> +Hit any key to stop autoboot:  0
> +=>
> diff --git a/board/theobroma-systems/jaguar_rk3588/jaguar_rk3588.c b/board/theobroma-systems/jaguar_rk3588/jaguar_rk3588.c
> new file mode 100644
> index 00000000000..3f96c4c500f
> --- /dev/null
> +++ b/board/theobroma-systems/jaguar_rk3588/jaguar_rk3588.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2023 Theobroma Systems Design und Consulting GmbH
> + */
> +
> +#include <asm/types.h>
> +#include <asm-generic/u-boot.h>
> +#include <phy.h>
> +#include <eth_phy.h>
> +#include <dm/uclass-id.h>
> +#include <dm/device.h>
> +#include <asm/arch-rockchip/cru_rk3588.h>
> +#include <asm/arch-rockchip/ioc_rk3588.h>
> +#include <asm/arch-rockchip/hardware.h>
> +#include "../common/common.h"
> +
> +#define GPIO2C3_SEL_OFFSET		12
> +#define GPIO2C3_SEL_MASK		GENMASK(15, GPIO2C3_SEL_OFFSET)
> +#define GPIO2C3_ETH0_REFCLKO_25M	(0x1 << GPIO2C3_SEL_OFFSET)
> +
> +#define REFCLKO25M_ETH0_OUT_SEL_MASK	BIT(15)
> +#define REFCLKO25M_ETH0_OUT_SEL_CPLL	BIT(15)
> +#define REFCLKO25M_ETH0_OUT_DIV_OFFSET	8
> +#define REFCLKO25M_ETH0_OUT_DIV_MASK	GENMASK(14, REFCLKO25M_ETH0_OUT_DIV_OFFSET)
> +#define REFCLKO25M_ETH0_OUT_DIV(x)	((((x) - 1) << REFCLKO25M_ETH0_OUT_DIV_OFFSET) & REFCLKO25M_ETH0_OUT_DIV_MASK)
> +
> +#define REFCLKO25M_ETH0_OUT_EN		BIT(4)
> +
> +void setup_eth0refclko(void)
> +{
> +	/* Configure and enable ETH0_REFCLKO_25MHz */
> +	static struct rk3588_bus_ioc * const bus_ioc = (void *)BUS_IOC_BASE;
> +	static struct rk3588_cru * const cru = (void *)CRU_BASE;
> +
> +	/* 1. Pinmux */
> +	rk_clrsetreg(&bus_ioc->gpio2c_iomux_sel_l, GPIO2C3_SEL_MASK, GPIO2C3_ETH0_REFCLKO_25M);
> +	/* 2. Parent clock selection + divider => CPLL (1.5GHz) / 60 => 25MHz */
> +	rk_clrsetreg(&cru->clksel_con[15],
> +		     REFCLKO25M_ETH0_OUT_SEL_MASK | REFCLKO25M_ETH0_OUT_DIV_MASK,
> +		     REFCLKO25M_ETH0_OUT_SEL_CPLL | REFCLKO25M_ETH0_OUT_DIV(60));
> +	/* 3. Enable clock */
> +	rk_clrreg(&cru->clkgate_con[5], REFCLKO25M_ETH0_OUT_EN);
> +}
> +
> +int rockchip_early_misc_init_r(void)
> +{
> +	setup_boottargets();
> +
> +	setup_eth0refclko();
> +
> +	return 0;
> +}
> diff --git a/configs/jaguar-rk3588_defconfig b/configs/jaguar-rk3588_defconfig
> new file mode 100644
> index 00000000000..ab550f16263
> --- /dev/null
> +++ b/configs/jaguar-rk3588_defconfig
> @@ -0,0 +1,115 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_COUNTER_FREQUENCY=24000000
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_TEXT_BASE=0x00a00000
> +CONFIG_SPL_GPIO=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_NR_DRAM_BANKS=2
> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
> +CONFIG_SF_DEFAULT_SPEED=24000000
> +CONFIG_SF_DEFAULT_MODE=0x2000
> +CONFIG_ENV_SIZE=0x1f000
> +CONFIG_DEFAULT_DEVICE_TREE="rk3588-jaguar"
> +CONFIG_ROCKCHIP_RK3588=y
> +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> +CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_STACK_R_ADDR=0x600000
> +CONFIG_TARGET_JAGUAR_RK3588=y
> +CONFIG_SPL_STACK=0x400000
> +CONFIG_DEBUG_UART_BASE=0xfeb50000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_SYS_LOAD_ADDR=0xc00800
> +CONFIG_DEBUG_UART=y
> +CONFIG_FIT=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
> +CONFIG_SPL_LOAD_FIT=y
> +# CONFIG_BOOTMETH_VBE is not set
> +CONFIG_LEGACY_IMAGE_FORMAT=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-jaguar.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_CYCLIC=y
> +CONFIG_SPL_MAX_SIZE=0x40000
> +CONFIG_SPL_PAD_TO=0x7f8000
> +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> +CONFIG_SPL_BSS_START_ADDR=0x4000000
> +CONFIG_SPL_BSS_MAX_SIZE=0x4000
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_ATF=y
> +# CONFIG_BOOTM_NETBSD is not set
> +# CONFIG_BOOTM_PLAN9 is not set
> +# CONFIG_BOOTM_RTEMS is not set
> +# CONFIG_BOOTM_VXWORKS is not set
> +# CONFIG_CMD_ELF is not set
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +# CONFIG_CMD_LOADB is not set
> +# CONFIG_CMD_LOADS is not set
> +CONFIG_CMD_MMC=y
> +# CONFIG_CMD_SF is not set
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +# CONFIG_CMD_MII is not set
> +# CONFIG_CMD_BLOCK_CACHE is not set
> +# CONFIG_CMD_EFICONFIG is not set
> +CONFIG_CMD_REGULATOR=y
> +CONFIG_CMD_EROFS=y
> +CONFIG_CMD_SQUASHFS=y
> +# CONFIG_SPL_DOS_PARTITION is not set
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_OF_LIVE=y
> +# CONFIG_OF_TAG_MIGRATE is not set
> +CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_OVERWRITE=y
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_SPL_REGMAP=y
> +CONFIG_SPL_SYSCON=y
> +# CONFIG_SARADC_ROCKCHIP is not set
> +CONFIG_SPL_CLK=y
> +CONFIG_CLK_GPIO=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MISC=y
> +CONFIG_SUPPORT_EMMC_RPMB=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_SPL_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_SPL_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_SUPPORT=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_SPI_FLASH is not set
> +CONFIG_SF_DEFAULT_BUS=5
> +CONFIG_PHY_MICREL=y
> +CONFIG_PHY_MICREL_KSZ90X1=y
> +CONFIG_DWC_ETH_QOS=y
> +CONFIG_DWC_ETH_QOS_ROCKCHIP=y
> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> +CONFIG_SPL_PINCTRL=y
> +CONFIG_SPL_RAM=y
> +CONFIG_SCSI=y
> +CONFIG_DM_SCSI=y
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYS_NS16550_MEM32=y
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_GENERIC=y
> +CONFIG_ERRNO_STR=y
> diff --git a/include/configs/jaguar_rk3588.h b/include/configs/jaguar_rk3588.h
> new file mode 100644
> index 00000000000..843028c5385
> --- /dev/null
> +++ b/include/configs/jaguar_rk3588.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
> + */
> +
> +#ifndef __JAGUAR_RK3588_H
> +#define __JAGUAR_RK3588_H
> +
> +#define ROCKCHIP_DEVICE_SETTINGS \
> +		"stdout=serial,vidconsole\0" \
> +		"stderr=serial,vidconsole\0"
> +
> +#include <configs/rk3588_common.h>
> +
> +#endif /* __JAGUAR_RK3588_H */
>