* [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR
@ 2024-01-23 14:49 Quentin Schulz
2024-01-23 14:49 ` [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible Quentin Schulz
` (17 more replies)
0 siblings, 18 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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>
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:47 ` Kever Yang
2024-02-02 4:25 ` Weizhao Ouyang
2024-01-23 14:49 ` [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1 Quentin Schulz
` (16 subsequent siblings)
17 siblings, 2 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
2024-01-23 14:49 ` [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:47 ` Kever Yang
2024-01-23 14:49 ` [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid Quentin Schulz
` (15 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
2024-01-23 14:49 ` [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible Quentin Schulz
2024-01-23 14:49 ` [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1 Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-01-23 14:49 ` [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r Quentin Schulz
` (14 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (2 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-03 13:16 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r Quentin Schulz
` (13 subsequent siblings)
17 siblings, 2 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (3 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-01-23 14:49 ` [PATCH 06/18] rockchip: pine64: pinebook: " Quentin Schulz
` (12 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (4 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-01-23 14:49 ` [PATCH 07/18] rockchip: pine64: pinephone: " Quentin Schulz
` (11 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 07/18] rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (5 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 06/18] rockchip: pine64: pinebook: " Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-03 13:18 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 08/18] rockchip: pine64: rockpro64: " Quentin Schulz
` (10 subsequent siblings)
17 siblings, 2 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (6 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 07/18] rockchip: pine64: pinephone: " Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-03 13:19 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 09/18] rockchip: theobroma-systems: puma: " Quentin Schulz
` (9 subsequent siblings)
17 siblings, 2 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 09/18] rockchip: theobroma-systems: puma: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (7 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 08/18] rockchip: pine64: rockpro64: " Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 10/18] rockchip: theobroma-systems: ringneck: " Quentin Schulz
` (8 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 10/18] rockchip: theobroma-systems: ringneck: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (8 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 09/18] rockchip: theobroma-systems: puma: " Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 11/18] rockchip: merge misc.c into board.c Quentin Schulz
` (7 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 11/18] rockchip: merge misc.c into board.c
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (9 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 10/18] rockchip: theobroma-systems: ringneck: " Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol Quentin Schulz
` (6 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (10 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 11/18] rockchip: merge misc.c into board.c Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media Quentin Schulz
` (5 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (11 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-01-24 10:19 ` Kever Yang
2024-01-23 14:49 ` [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces Quentin Schulz
` (4 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (12 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:58 ` Kever Yang
2024-01-23 14:49 ` [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files Quentin Schulz
` (3 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (13 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-01-24 10:46 ` Kever Yang
2024-01-23 14:49 ` [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h Quentin Schulz
` (2 subsequent siblings)
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (14 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-02-01 2:59 ` Kever Yang
2024-01-23 14:49 ` [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc Quentin Schulz
2024-01-23 14:49 ` [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC Quentin Schulz
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (15 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-01-24 10:35 ` Kever Yang
2024-01-23 14:49 ` [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC Quentin Schulz
17 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
` (16 preceding siblings ...)
2024-01-23 14:49 ` [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc Quentin Schulz
@ 2024-01-23 14:49 ` Quentin Schulz
2024-01-23 18:04 ` Quentin Schulz
2024-02-01 2:46 ` Kever Yang
17 siblings, 2 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 14:49 UTC (permalink / raw)
To: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, Quentin Schulz, u-boot, 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
+ ð0_pins
+ ð_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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* Re: [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC
2024-01-23 14:49 ` [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC Quentin Schulz
@ 2024-01-23 18:04 ` Quentin Schulz
2024-02-01 2:46 ` Kever Yang
1 sibling, 0 replies; 77+ messages in thread
From: Quentin Schulz @ 2024-01-23 18:04 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Kever Yang,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-23 14:49 ` [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media Quentin Schulz
@ 2024-01-24 10:19 ` Kever Yang
2024-01-24 10:50 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-24 10:19 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin,
洪慧斌
Cc: heiko, u-boot, Quentin Schulz
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;
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-23 14:49 ` [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc Quentin Schulz
@ 2024-01-24 10:35 ` Kever Yang
2024-01-24 11:04 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-24 10:35 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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;
> };
>
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files
2024-01-23 14:49 ` [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files Quentin Schulz
@ 2024-01-24 10:46 ` Kever Yang
2024-01-24 11:12 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-24 10:46 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-24 10:19 ` Kever Yang
@ 2024-01-24 10:50 ` Quentin Schulz
2024-01-25 10:29 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-24 10:50 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, 洪慧斌
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-24 10:35 ` Kever Yang
@ 2024-01-24 11:04 ` Quentin Schulz
2024-01-26 8:58 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-24 11:04 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files
2024-01-24 10:46 ` Kever Yang
@ 2024-01-24 11:12 ` Quentin Schulz
2024-01-29 9:55 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-24 11:12 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-24 10:50 ` Quentin Schulz
@ 2024-01-25 10:29 ` Kever Yang
2024-01-25 11:02 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-25 10:29 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-25 10:29 ` Kever Yang
@ 2024-01-25 11:02 ` Quentin Schulz
2024-01-26 2:57 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-25 11:02 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-25 11:02 ` Quentin Schulz
@ 2024-01-26 2:57 ` Kever Yang
2024-01-26 10:37 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-26 2:57 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-24 11:04 ` Quentin Schulz
@ 2024-01-26 8:58 ` Kever Yang
2024-01-26 9:32 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-26 8:58 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-26 8:58 ` Kever Yang
@ 2024-01-26 9:32 ` Quentin Schulz
2024-01-26 10:56 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-26 9:32 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 2:57 ` Kever Yang
@ 2024-01-26 10:37 ` Quentin Schulz
2024-01-26 11:04 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-26 10:37 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-26 9:32 ` Quentin Schulz
@ 2024-01-26 10:56 ` Kever Yang
2024-01-26 16:18 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-26 10:56 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 10:37 ` Quentin Schulz
@ 2024-01-26 11:04 ` Dragan Simic
2024-01-26 11:09 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-01-26 11:04 UTC (permalink / raw)
To: Quentin Schulz
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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."
> :)
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 11:04 ` Dragan Simic
@ 2024-01-26 11:09 ` Quentin Schulz
2024-01-26 11:24 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-26 11:09 UTC (permalink / raw)
To: Dragan Simic
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 11:09 ` Quentin Schulz
@ 2024-01-26 11:24 ` Dragan Simic
2024-01-26 11:29 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-01-26 11:24 UTC (permalink / raw)
To: Quentin Schulz
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 11:24 ` Dragan Simic
@ 2024-01-26 11:29 ` Quentin Schulz
2024-01-26 11:33 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-26 11:29 UTC (permalink / raw)
To: Dragan Simic
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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).
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 11:29 ` Quentin Schulz
@ 2024-01-26 11:33 ` Dragan Simic
2024-01-26 13:46 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-01-26 11:33 UTC (permalink / raw)
To: Quentin Schulz
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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?
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 11:33 ` Dragan Simic
@ 2024-01-26 13:46 ` Quentin Schulz
2024-01-26 19:42 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-26 13:46 UTC (permalink / raw)
To: Dragan Simic
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-26 10:56 ` Kever Yang
@ 2024-01-26 16:18 ` Quentin Schulz
2024-01-29 10:35 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-26 16:18 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
2024-01-26 13:46 ` Quentin Schulz
@ 2024-01-26 19:42 ` Dragan Simic
0 siblings, 0 replies; 77+ messages in thread
From: Dragan Simic @ 2024-01-26 19:42 UTC (permalink / raw)
To: Quentin Schulz
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Jagan Teki, Klaus Goger, Heiko Stuebner,
洪慧斌,
heiko, u-boot
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!
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files
2024-01-24 11:12 ` Quentin Schulz
@ 2024-01-29 9:55 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-01-29 9:55 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-26 16:18 ` Quentin Schulz
@ 2024-01-29 10:35 ` Kever Yang
2024-01-31 17:55 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-01-29 10:35 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-29 10:35 ` Kever Yang
@ 2024-01-31 17:55 ` Quentin Schulz
2024-02-01 2:43 ` Kever Yang
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-01-31 17:55 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
2024-01-31 17:55 ` Quentin Schulz
@ 2024-02-01 2:43 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:43 UTC (permalink / raw)
To: Quentin Schulz, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin
Cc: heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC
2024-01-23 14:49 ` [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC Quentin Schulz
2024-01-23 18:04 ` Quentin Schulz
@ 2024-02-01 2:46 ` Kever Yang
1 sibling, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:46 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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
> + ð0_pins
> + ð_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 */
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible
2024-01-23 14:49 ` [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible Quentin Schulz
@ 2024-02-01 2:47 ` Kever Yang
2024-02-02 4:25 ` Weizhao Ouyang
1 sibling, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:47 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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 },
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1
2024-01-23 14:49 ` [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1 Quentin Schulz
@ 2024-02-01 2:47 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:47 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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>;
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid
2024-01-23 14:49 ` [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid Quentin Schulz
@ 2024-02-01 2:48 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:48 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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#");
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r
2024-01-23 14:49 ` [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r Quentin Schulz
@ 2024-02-01 2:48 ` Kever Yang
2024-02-03 13:16 ` Dragan Simic
1 sibling, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:48 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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;
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r Quentin Schulz
@ 2024-02-01 2:48 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:48 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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;
> }
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 06/18] rockchip: pine64: pinebook: " Quentin Schulz
@ 2024-02-01 2:48 ` Kever Yang
2024-02-01 4:02 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:48 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 07/18] rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 07/18] rockchip: pine64: pinephone: " Quentin Schulz
@ 2024-02-01 2:48 ` Kever Yang
2024-02-03 13:18 ` Dragan Simic
1 sibling, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:48 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 08/18] rockchip: pine64: rockpro64: " Quentin Schulz
@ 2024-02-01 2:48 ` Kever Yang
2024-02-03 13:19 ` Dragan Simic
1 sibling, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:48 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 09/18] rockchip: theobroma-systems: puma: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 09/18] rockchip: theobroma-systems: puma: " Quentin Schulz
@ 2024-02-01 2:49 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:49 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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();
>
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 10/18] rockchip: theobroma-systems: ringneck: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 10/18] rockchip: theobroma-systems: ringneck: " Quentin Schulz
@ 2024-02-01 2:49 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:49 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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;
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 11/18] rockchip: merge misc.c into board.c
2024-01-23 14:49 ` [PATCH 11/18] rockchip: merge misc.c into board.c Quentin Schulz
@ 2024-02-01 2:49 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:49 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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;
> -}
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol
2024-01-23 14:49 ` [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol Quentin Schulz
@ 2024-02-01 2:49 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:49 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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;
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces
2024-01-23 14:49 ` [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces Quentin Schulz
@ 2024-02-01 2:58 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:58 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h
2024-01-23 14:49 ` [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h Quentin Schulz
@ 2024-02-01 2:59 ` Kever Yang
0 siblings, 0 replies; 77+ messages in thread
From: Kever Yang @ 2024-02-01 2:59 UTC (permalink / raw)
To: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin
Cc: heiko, u-boot, Quentin Schulz
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>
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
2024-02-01 2:48 ` Kever Yang
@ 2024-02-01 4:02 ` Dragan Simic
2024-02-01 17:46 ` Quentin Schulz
2024-02-03 13:18 ` Dragan Simic
0 siblings, 2 replies; 77+ messages in thread
From: Dragan Simic @ 2024-02-01 4:02 UTC (permalink / raw)
To: Kever Yang
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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
>>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
2024-02-01 4:02 ` Dragan Simic
@ 2024-02-01 17:46 ` Quentin Schulz
2024-02-01 17:56 ` Dragan Simic
2024-02-03 13:18 ` Dragan Simic
1 sibling, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-02-01 17:46 UTC (permalink / raw)
To: Dragan Simic, Kever Yang
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
2024-02-01 17:46 ` Quentin Schulz
@ 2024-02-01 17:56 ` Dragan Simic
0 siblings, 0 replies; 77+ messages in thread
From: Dragan Simic @ 2024-02-01 17:56 UTC (permalink / raw)
To: Quentin Schulz
Cc: Kever Yang, Quentin Schulz, Simon Glass, Philipp Tomsich,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot
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.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible
2024-01-23 14:49 ` [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible Quentin Schulz
2024-02-01 2:47 ` Kever Yang
@ 2024-02-02 4:25 ` Weizhao Ouyang
1 sibling, 0 replies; 77+ messages in thread
From: Weizhao Ouyang @ 2024-02-02 4:25 UTC (permalink / raw)
To: Quentin Schulz
Cc: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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
>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r
2024-01-23 14:49 ` [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r Quentin Schulz
2024-02-01 2:48 ` Kever Yang
@ 2024-02-03 13:16 ` Dragan Simic
1 sibling, 0 replies; 77+ messages in thread
From: Dragan Simic @ 2024-02-03 13:16 UTC (permalink / raw)
To: Quentin Schulz
Cc: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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;
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
2024-02-01 4:02 ` Dragan Simic
2024-02-01 17:46 ` Quentin Schulz
@ 2024-02-03 13:18 ` Dragan Simic
1 sibling, 0 replies; 77+ messages in thread
From: Dragan Simic @ 2024-02-03 13:18 UTC (permalink / raw)
To: Kever Yang, Quentin Schulz
Cc: Simon Glass, Philipp Tomsich, Tom Rini, Alper Nebi Yasak,
Peter Robinson, Jagan Teki, Klaus Goger, Heiko Stuebner,
Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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
>>>
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 07/18] rockchip: pine64: pinephone: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 07/18] rockchip: pine64: pinephone: " Quentin Schulz
2024-02-01 2:48 ` Kever Yang
@ 2024-02-03 13:18 ` Dragan Simic
1 sibling, 0 replies; 77+ messages in thread
From: Dragan Simic @ 2024-02-03 13:18 UTC (permalink / raw)
To: Quentin Schulz
Cc: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-01-23 14:49 ` [PATCH 08/18] rockchip: pine64: rockpro64: " Quentin Schulz
2024-02-01 2:48 ` Kever Yang
@ 2024-02-03 13:19 ` Dragan Simic
2024-02-03 14:18 ` Jonas Karlman
1 sibling, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-02-03 13:19 UTC (permalink / raw)
To: Quentin Schulz
Cc: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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
^ permalink raw reply related [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-03 13:19 ` Dragan Simic
@ 2024-02-03 14:18 ` Jonas Karlman
2024-02-03 15:18 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Jonas Karlman @ 2024-02-03 14:18 UTC (permalink / raw)
To: Dragan Simic, Quentin Schulz
Cc: Simon Glass, Philipp Tomsich, Kever Yang, Tom Rini,
Alper Nebi Yasak, Peter Robinson, Jagan Teki, Klaus Goger,
Heiko Stuebner, Otavio Salvador, Andy Yan, Manivannan Sadhasivam,
Lukasz Majewski, Sean Anderson, Joe Hershberger, Ramon Fried,
Sughosh Ganu, Heinrich Schuchardt, Anatolij Gustschin, heiko,
u-boot, Quentin Schulz
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-03 14:18 ` Jonas Karlman
@ 2024-02-03 15:18 ` Dragan Simic
2024-02-04 4:21 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-02-03 15:18 UTC (permalink / raw)
To: Jonas Karlman
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Kever Yang,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot, Quentin Schulz
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-03 15:18 ` Dragan Simic
@ 2024-02-04 4:21 ` Dragan Simic
2024-02-04 9:46 ` Jonas Karlman
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-02-04 4:21 UTC (permalink / raw)
To: Jonas Karlman
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Kever Yang,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot, Quentin Schulz
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-04 4:21 ` Dragan Simic
@ 2024-02-04 9:46 ` Jonas Karlman
2024-02-04 10:39 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Jonas Karlman @ 2024-02-04 9:46 UTC (permalink / raw)
To: Dragan Simic
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Kever Yang,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot, Quentin Schulz
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-04 9:46 ` Jonas Karlman
@ 2024-02-04 10:39 ` Dragan Simic
2024-02-06 12:26 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-02-04 10:39 UTC (permalink / raw)
To: Jonas Karlman
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Kever Yang,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot, Quentin Schulz
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-04 10:39 ` Dragan Simic
@ 2024-02-06 12:26 ` Quentin Schulz
2024-02-06 12:33 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-02-06 12:26 UTC (permalink / raw)
To: Dragan Simic, Jonas Karlman
Cc: Quentin Schulz, Simon Glass, Philipp Tomsich, Kever Yang,
Tom Rini, Alper Nebi Yasak, Peter Robinson, Jagan Teki,
Klaus Goger, Heiko Stuebner, Otavio Salvador, Andy Yan,
Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-06 12:26 ` Quentin Schulz
@ 2024-02-06 12:33 ` Dragan Simic
2024-02-06 12:37 ` Quentin Schulz
0 siblings, 1 reply; 77+ messages in thread
From: Dragan Simic @ 2024-02-06 12:33 UTC (permalink / raw)
To: Quentin Schulz
Cc: Jonas Karlman, Quentin Schulz, Simon Glass, Philipp Tomsich,
Kever Yang, Tom Rini, Alper Nebi Yasak, Peter Robinson,
Jagan Teki, Klaus Goger, Heiko Stuebner, Otavio Salvador,
Andy Yan, Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot
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.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-06 12:33 ` Dragan Simic
@ 2024-02-06 12:37 ` Quentin Schulz
2024-02-06 12:42 ` Dragan Simic
0 siblings, 1 reply; 77+ messages in thread
From: Quentin Schulz @ 2024-02-06 12:37 UTC (permalink / raw)
To: Dragan Simic
Cc: Jonas Karlman, Quentin Schulz, Simon Glass, Philipp Tomsich,
Kever Yang, Tom Rini, Alper Nebi Yasak, Peter Robinson,
Jagan Teki, Klaus Goger, Heiko Stuebner, Otavio Salvador,
Andy Yan, Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot
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
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: [PATCH 08/18] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
2024-02-06 12:37 ` Quentin Schulz
@ 2024-02-06 12:42 ` Dragan Simic
0 siblings, 0 replies; 77+ messages in thread
From: Dragan Simic @ 2024-02-06 12:42 UTC (permalink / raw)
To: Quentin Schulz
Cc: Jonas Karlman, Quentin Schulz, Simon Glass, Philipp Tomsich,
Kever Yang, Tom Rini, Alper Nebi Yasak, Peter Robinson,
Jagan Teki, Klaus Goger, Heiko Stuebner, Otavio Salvador,
Andy Yan, Manivannan Sadhasivam, Lukasz Majewski, Sean Anderson,
Joe Hershberger, Ramon Fried, Sughosh Ganu, Heinrich Schuchardt,
Anatolij Gustschin, heiko, u-boot
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.
^ permalink raw reply [flat|nested] 77+ messages in thread
end of thread, other threads:[~2024-02-06 12:42 UTC | newest]
Thread overview: 77+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-23 14:49 [PATCH 00/18] rockchip: add support for Theobroma JAGUAR SBC-RK3588-AMR Quentin Schulz
2024-01-23 14:49 ` [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible Quentin Schulz
2024-02-01 2:47 ` Kever Yang
2024-02-02 4:25 ` Weizhao Ouyang
2024-01-23 14:49 ` [PATCH 02/18] rockchip: rk3588: sync rk3588s dtsi from v6.8-rc1 Quentin Schulz
2024-02-01 2:47 ` Kever Yang
2024-01-23 14:49 ` [PATCH 03/18] rockchip: avoid out-of-bounds when computing cpuid Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-01-23 14:49 ` [PATCH 04/18] rockchip: add weak function symbol called at the beginning of misc_init_r Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-03 13:16 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 05/18] rockchip: google: gru: migrate to rockchip_early_misc_init_r Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-01-23 14:49 ` [PATCH 06/18] rockchip: pine64: pinebook: " Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-01 4:02 ` Dragan Simic
2024-02-01 17:46 ` Quentin Schulz
2024-02-01 17:56 ` Dragan Simic
2024-02-03 13:18 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 07/18] rockchip: pine64: pinephone: " Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-03 13:18 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 08/18] rockchip: pine64: rockpro64: " Quentin Schulz
2024-02-01 2:48 ` Kever Yang
2024-02-03 13:19 ` Dragan Simic
2024-02-03 14:18 ` Jonas Karlman
2024-02-03 15:18 ` Dragan Simic
2024-02-04 4:21 ` Dragan Simic
2024-02-04 9:46 ` Jonas Karlman
2024-02-04 10:39 ` Dragan Simic
2024-02-06 12:26 ` Quentin Schulz
2024-02-06 12:33 ` Dragan Simic
2024-02-06 12:37 ` Quentin Schulz
2024-02-06 12:42 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 09/18] rockchip: theobroma-systems: puma: " Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 10/18] rockchip: theobroma-systems: ringneck: " Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 11/18] rockchip: merge misc.c into board.c Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 12/18] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol Quentin Schulz
2024-02-01 2:49 ` Kever Yang
2024-01-23 14:49 ` [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media Quentin Schulz
2024-01-24 10:19 ` Kever Yang
2024-01-24 10:50 ` Quentin Schulz
2024-01-25 10:29 ` Kever Yang
2024-01-25 11:02 ` Quentin Schulz
2024-01-26 2:57 ` Kever Yang
2024-01-26 10:37 ` Quentin Schulz
2024-01-26 11:04 ` Dragan Simic
2024-01-26 11:09 ` Quentin Schulz
2024-01-26 11:24 ` Dragan Simic
2024-01-26 11:29 ` Quentin Schulz
2024-01-26 11:33 ` Dragan Simic
2024-01-26 13:46 ` Quentin Schulz
2024-01-26 19:42 ` Dragan Simic
2024-01-23 14:49 ` [PATCH 14/18] rockchip: rk3588: add constants for some register address spaces Quentin Schulz
2024-02-01 2:58 ` Kever Yang
2024-01-23 14:49 ` [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files Quentin Schulz
2024-01-24 10:46 ` Kever Yang
2024-01-24 11:12 ` Quentin Schulz
2024-01-29 9:55 ` Kever Yang
2024-01-23 14:49 ` [PATCH 16/18] rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.h Quentin Schulz
2024-02-01 2:59 ` Kever Yang
2024-01-23 14:49 ` [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc Quentin Schulz
2024-01-24 10:35 ` Kever Yang
2024-01-24 11:04 ` Quentin Schulz
2024-01-26 8:58 ` Kever Yang
2024-01-26 9:32 ` Quentin Schulz
2024-01-26 10:56 ` Kever Yang
2024-01-26 16:18 ` Quentin Schulz
2024-01-29 10:35 ` Kever Yang
2024-01-31 17:55 ` Quentin Schulz
2024-02-01 2:43 ` Kever Yang
2024-01-23 14:49 ` [PATCH 18/18] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC Quentin Schulz
2024-01-23 18:04 ` Quentin Schulz
2024-02-01 2:46 ` Kever Yang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.