[PATCH next v2 0/4] rockchip: rk3399: trigger sysreset in TPL
A sysreset-gpio can be provided in an RK3399 platform's Device Tree and if U-Boot detects a "warm" boot was done, it'll toggle that GPIO to perform a reset of the PMIC, essentially forcing a cold boot to make sure there are no non-default values in SoC registers.
For now, this was only supported in SPL, probably because when this was implemented RK3399 (and specifically Puma) didn't have TPL support so SPL was the earliest stage. Now that most RK3399 boards (and specifically Puma) have TPL enabled, it makes sense to move this logic triggering this sysreset from it. It brings the following advantages: - faster boot time as we don't need to reach SPL to be able to reset the system on a condition we know is already met in TPL, - have less code to be impacted by the issue this system reset works around (that is, "unclean" SoC registers after a reboot), - less confusion around the reason for restarting. Indeed when done from SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
possibly hinting at an issue within the SPL when loading the fitImage from MMC2 instead of the normal course of events (a system reset).
For this to be possible, a weak callback is added in the TPL main C code so that we can hook this sysreset function within the TPL code path.
@Cc Paul since he's trying to add support for this sysreset to the Firefly ROC-RK3399-PC[1] and Pine64 ROCKPro64[2]. You'll want to have gpio1 with boopth-pre-sram though so it makes it to the TPL DTB.
[1] https://lore.kernel.org/u-boot/20240926183111.1324284-1-paulk@sys-base.io/ [2] https://lore.kernel.org/u-boot/20240926183111.1324284-2-paulk@sys-base.io/
Signed-off-by: Quentin Schulz quentin.schulz@cherry.de --- Changes in v2: - added Paul's Rb tags - fixed "an TPL" typos - removed SPL support (merging patches 4 and 5 from v1 for bisectability) - removed indentation in # if defined and their trailing comments
- Link to v1: https://lore.kernel.org/r/20241105-rk3399-sysreset-gpio-tpl-v1-0-12caff07a4e...
--- Quentin Schulz (4): pinctrl: rockchip: allow to build for TPL rockchip: rk3399: merge CRU check within rk3399_force_power_on_reset rockchip: tpl: allow to call board/SoC-specific code before DRAM init rockchip: rk3399: move sysreset-gpio logic to TPL
arch/arm/mach-rockchip/rk3399/rk3399.c | 56 ++++++++++++++++++---------------- arch/arm/mach-rockchip/tpl.c | 6 ++++ configs/puma-rk3399_defconfig | 3 ++ drivers/pinctrl/Kconfig | 8 +++++ drivers/pinctrl/rockchip/Kconfig | 7 +++++ 5 files changed, 54 insertions(+), 26 deletions(-) --- base-commit: 56accc56b9aab87ef4809ccc588e1257969cd271 change-id: 20241105-rk3399-sysreset-gpio-tpl-50620781cdd9
Best regards,
From: Quentin Schulz quentin.schulz@cherry.de
A later commit will make use of the pinctrl driver in TPL so let's add the ability to build the Rockchip pinctrl driver in TPL.
Reviewed-by: Paul Kocialkowski paulk@sys-base.io Signed-off-by: Quentin Schulz quentin.schulz@cherry.de --- drivers/pinctrl/Kconfig | 8 ++++++++ drivers/pinctrl/rockchip/Kconfig | 7 +++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index a1d53cfbdbed5ef1030fff04715e1436f167554b..6ee7dc1cce8da08e13b898c541d047bad9e3c89b 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -127,6 +127,14 @@ config SPL_PINCTRL_GENERIC This option is an SPL-variant of the PINCTRL_GENERIC option. See the help of PINCTRL_GENERIC for details.
+config TPL_PINCTRL_GENERIC + bool "Support generic pin controllers in TPL" + depends on TPL_PINCTRL_FULL + default y + help + This option is a TPL-variant of the PINCTRL_GENERIC option. + See the help of PINCTRL_GENERIC for details. + config SPL_PINMUX bool "Support pin multiplexing controllers in SPL" depends on SPL_PINCTRL_GENERIC diff --git a/drivers/pinctrl/rockchip/Kconfig b/drivers/pinctrl/rockchip/Kconfig index dc4ba34ae5d581be76786fd05d679d26397fd467..8aa9dcac35873d99f9dd28ed18232b52a9f4343a 100644 --- a/drivers/pinctrl/rockchip/Kconfig +++ b/drivers/pinctrl/rockchip/Kconfig @@ -14,4 +14,11 @@ config SPL_PINCTRL_ROCKCHIP help This option is an SPL-variant of the PINCTRL_ROCKCHIP option.
+config TPL_PINCTRL_ROCKCHIP + bool "Support Rockchip pin controllers in TPL" + depends on ARCH_ROCKCHIP && TPL_PINCTRL_GENERIC + default y + help + This option is a TPL-variant of the PINCTRL_ROCKCHIP option. + endif
On 2024/11/6 19:29, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@cherry.de
A later commit will make use of the pinctrl driver in TPL so let's add the ability to build the Rockchip pinctrl driver in TPL.
Reviewed-by: Paul Kocialkowski paulk@sys-base.io Signed-off-by: Quentin Schulz quentin.schulz@cherry.de
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
drivers/pinctrl/Kconfig | 8 ++++++++ drivers/pinctrl/rockchip/Kconfig | 7 +++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index a1d53cfbdbed5ef1030fff04715e1436f167554b..6ee7dc1cce8da08e13b898c541d047bad9e3c89b 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -127,6 +127,14 @@ config SPL_PINCTRL_GENERIC This option is an SPL-variant of the PINCTRL_GENERIC option. See the help of PINCTRL_GENERIC for details.
+config TPL_PINCTRL_GENERIC
- bool "Support generic pin controllers in TPL"
- depends on TPL_PINCTRL_FULL
- default y
- help
This option is a TPL-variant of the PINCTRL_GENERIC option.See the help of PINCTRL_GENERIC for details.- config SPL_PINMUX bool "Support pin multiplexing controllers in SPL" depends on SPL_PINCTRL_GENERIC
diff --git a/drivers/pinctrl/rockchip/Kconfig b/drivers/pinctrl/rockchip/Kconfig index dc4ba34ae5d581be76786fd05d679d26397fd467..8aa9dcac35873d99f9dd28ed18232b52a9f4343a 100644 --- a/drivers/pinctrl/rockchip/Kconfig +++ b/drivers/pinctrl/rockchip/Kconfig @@ -14,4 +14,11 @@ config SPL_PINCTRL_ROCKCHIP help This option is an SPL-variant of the PINCTRL_ROCKCHIP option.
+config TPL_PINCTRL_ROCKCHIP
- bool "Support Rockchip pin controllers in TPL"
- depends on ARCH_ROCKCHIP && TPL_PINCTRL_GENERIC
- default y
- help
This option is a TPL-variant of the PINCTRL_ROCKCHIP option.- endif
From: Quentin Schulz quentin.schulz@cherry.de
To prepare to support forcing power on reset from TPL which would have the exact same logic, just in an earlier stage, let's merge the CRU check that triggers the power on reset with the rest of the logic.
Reviewed-by: Paul Kocialkowski paulk@sys-base.io Signed-off-by: Quentin Schulz quentin.schulz@cherry.de --- arch/arm/mach-rockchip/rk3399/rk3399.c | 43 +++++++++++++++++----------------- 1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index edccb2a3980d0e3921aa4073b67aea6a00f18b8d..7b6a822ed04b8151a5da147056dbf73ffdafd149 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -172,9 +172,29 @@ void board_debug_uart_init(void) #if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD) static void rk3399_force_power_on_reset(void) { + const struct rockchip_cru *cru = rockchip_get_cru(); ofnode node; struct gpio_desc sysreset_gpio;
+ /* + * The RK3399 resets only 'almost all logic' (see also in the + * TRM "3.9.4 Global software reset"), when issuing a software + * reset. This may cause issues during boot-up for some + * configurations of the application software stack. + * + * To work around this, we test whether the last reset reason + * was a power-on reset and (if not) issue an overtemp-reset to + * reset the entire module. + * + * While this was previously fixed by modifying the various + * places that could generate a software reset (e.g. U-Boot's + * sysreset driver, the ATF or Linux), we now have it here to + * ensure that we no longer have to track this through the + * various components. + */ + if (cru->glb_rst_st == 0) + return; + if (!IS_ENABLED(CONFIG_SPL_GPIO)) { debug("%s: trying to force a power-on reset but no GPIO " "support in SPL!\n", __func__); @@ -206,27 +226,6 @@ void spl_board_init(void) { led_setup();
- if (IS_ENABLED(CONFIG_SPL_GPIO)) { - struct rockchip_cru *cru = rockchip_get_cru(); - - /* - * The RK3399 resets only 'almost all logic' (see also in the - * TRM "3.9.4 Global software reset"), when issuing a software - * reset. This may cause issues during boot-up for some - * configurations of the application software stack. - * - * To work around this, we test whether the last reset reason - * was a power-on reset and (if not) issue an overtemp-reset to - * reset the entire module. - * - * While this was previously fixed by modifying the various - * places that could generate a software reset (e.g. U-Boot's - * sysreset driver, the ATF or Linux), we now have it here to - * ensure that we no longer have to track this through the - * various components. - */ - if (cru->glb_rst_st != 0) - rk3399_force_power_on_reset(); - } + rk3399_force_power_on_reset(); } #endif
On 2024/11/6 19:29, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@cherry.de
To prepare to support forcing power on reset from TPL which would have the exact same logic, just in an earlier stage, let's merge the CRU check that triggers the power on reset with the rest of the logic.
Reviewed-by: Paul Kocialkowski paulk@sys-base.io Signed-off-by: Quentin Schulz quentin.schulz@cherry.de
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
arch/arm/mach-rockchip/rk3399/rk3399.c | 43 +++++++++++++++++----------------- 1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index edccb2a3980d0e3921aa4073b67aea6a00f18b8d..7b6a822ed04b8151a5da147056dbf73ffdafd149 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -172,9 +172,29 @@ void board_debug_uart_init(void) #if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD) static void rk3399_force_power_on_reset(void) {
const struct rockchip_cru *cru = rockchip_get_cru(); ofnode node; struct gpio_desc sysreset_gpio;
/*
* The RK3399 resets only 'almost all logic' (see also in the* TRM "3.9.4 Global software reset"), when issuing a software* reset. This may cause issues during boot-up for some* configurations of the application software stack.** To work around this, we test whether the last reset reason* was a power-on reset and (if not) issue an overtemp-reset to* reset the entire module.** While this was previously fixed by modifying the various* places that could generate a software reset (e.g. U-Boot's* sysreset driver, the ATF or Linux), we now have it here to* ensure that we no longer have to track this through the* various components.*/if (cru->glb_rst_st == 0)
return;if (!IS_ENABLED(CONFIG_SPL_GPIO)) { debug("%s: trying to force a power-on reset but no GPIO " "support in SPL!\n", __func__);
@@ -206,27 +226,6 @@ void spl_board_init(void) { led_setup();
- if (IS_ENABLED(CONFIG_SPL_GPIO)) {
struct rockchip_cru *cru = rockchip_get_cru();/** The RK3399 resets only 'almost all logic' (see also in the* TRM "3.9.4 Global software reset"), when issuing a software* reset. This may cause issues during boot-up for some* configurations of the application software stack.** To work around this, we test whether the last reset reason* was a power-on reset and (if not) issue an overtemp-reset to* reset the entire module.** While this was previously fixed by modifying the various* places that could generate a software reset (e.g. U-Boot's* sysreset driver, the ATF or Linux), we now have it here to* ensure that we no longer have to track this through the* various components.*/if (cru->glb_rst_st != 0)rk3399_force_power_on_reset();- }
- rk3399_force_power_on_reset(); } #endif
From: Quentin Schulz quentin.schulz@cherry.de
This defines a weak tpl_board_init function that can be used for running board/SoC-specific code before the DRAM init happens, similarly to spl_board_init() for SPL.
Reviewed-by: Paul Kocialkowski paulk@sys-base.io Signed-off-by: Quentin Schulz quentin.schulz@cherry.de --- arch/arm/mach-rockchip/tpl.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-rockchip/tpl.c b/arch/arm/mach-rockchip/tpl.c index bbb9329e725af79ea4c4049aa7890a4a143e7df5..6b880f19f84e57e7bc0c93b16b188bc56267827e 100644 --- a/arch/arm/mach-rockchip/tpl.c +++ b/arch/arm/mach-rockchip/tpl.c @@ -21,6 +21,10 @@ #include <timestamp.h> #endif
+__weak void tpl_board_init(void) +{ +} + void board_init_f(ulong dummy) { struct udevice *dev; @@ -54,6 +58,8 @@ void board_init_f(ulong dummy) if (IS_ENABLED(CONFIG_SYS_ARCH_TIMER)) timer_init();
+ tpl_board_init(); + ret = uclass_get_device(UCLASS_RAM, 0, &dev); if (ret) { printf("DRAM init failed: %d\n", ret);
On 2024/11/6 19:29, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@cherry.de
This defines a weak tpl_board_init function that can be used for running board/SoC-specific code before the DRAM init happens, similarly to spl_board_init() for SPL.
Reviewed-by: Paul Kocialkowski paulk@sys-base.io Signed-off-by: Quentin Schulz quentin.schulz@cherry.de
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
arch/arm/mach-rockchip/tpl.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-rockchip/tpl.c b/arch/arm/mach-rockchip/tpl.c index bbb9329e725af79ea4c4049aa7890a4a143e7df5..6b880f19f84e57e7bc0c93b16b188bc56267827e 100644 --- a/arch/arm/mach-rockchip/tpl.c +++ b/arch/arm/mach-rockchip/tpl.c @@ -21,6 +21,10 @@ #include <timestamp.h> #endif
+__weak void tpl_board_init(void) +{ +}
- void board_init_f(ulong dummy) { struct udevice *dev;
@@ -54,6 +58,8 @@ void board_init_f(ulong dummy) if (IS_ENABLED(CONFIG_SYS_ARCH_TIMER)) timer_init();
- tpl_board_init();
- ret = uclass_get_device(UCLASS_RAM, 0, &dev); if (ret) { printf("DRAM init failed: %d\n", ret);
From: Quentin Schulz quentin.schulz@cherry.de
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is provided in the TPL Device Tree, this will trigger a system reset similar to what's currently been done in SPL whenever the RK3399 "warm" boots. Because there's currently only one user of sysreset-gpio logic, and TPL is enabled on that board, so let's migrate the logic and that board to do it in TPL.
There are three reasons for moving this earlier: - faster boot time as we don't need to reach SPL to be able to reset the system on a condition we know is already met in TPL, - have less code to be impacted by the issue this system reset works around (that is, "unclean" SoC registers after a reboot), - less confusion around the reason for restarting. Indeed when done from SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
possibly hinting at an issue within the SPL when loading the fitImage from MMC2 instead of the normal course of events (a system reset).
Signed-off-by: Quentin Schulz quentin.schulz@cherry.de --- arch/arm/mach-rockchip/rk3399/rk3399.c | 15 ++++++++++----- configs/puma-rk3399_defconfig | 3 +++ 2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 7b6a822ed04b8151a5da147056dbf73ffdafd149..0c28241c603e343c5140322f2778678e95fa84fd 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -169,7 +169,8 @@ void board_debug_uart_init(void) } #endif
-#if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD) +#if defined(CONFIG_XPL_BUILD) +#if defined(CONFIG_TPL_BUILD) static void rk3399_force_power_on_reset(void) { const struct rockchip_cru *cru = rockchip_get_cru(); @@ -195,9 +196,9 @@ static void rk3399_force_power_on_reset(void) if (cru->glb_rst_st == 0) return;
- if (!IS_ENABLED(CONFIG_SPL_GPIO)) { + if (!IS_ENABLED(CONFIG_TPL_GPIO)) { debug("%s: trying to force a power-on reset but no GPIO " - "support in SPL!\n", __func__); + "support in TPL!\n", __func__); return; }
@@ -218,6 +219,11 @@ static void rk3399_force_power_on_reset(void) dm_gpio_set_value(&sysreset_gpio, 1); }
+void tpl_board_init(void) +{ + rk3399_force_power_on_reset(); +} +# else void __weak led_setup(void) { } @@ -225,7 +231,6 @@ void __weak led_setup(void) void spl_board_init(void) { led_setup(); - - rk3399_force_power_on_reset(); } #endif +#endif diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 67c0ee72c925cdd49066980b0fde4131c86a99a8..7a180b1413036234d834773778f6c0f0a7e85380 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_POWER=y CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y +CONFIG_TPL_GPIO=y # CONFIG_BOOTM_NETBSD is not set # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set @@ -78,6 +79,8 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_TPL_PINCTRL=y +CONFIG_TPL_PINCTRL_FULL=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_SPL_PMIC_RK8XX=y
Hi Quentin,
On 2024/11/6 19:29, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@cherry.de
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is provided in the TPL Device Tree, this will trigger a system reset similar to what's currently been done in SPL whenever the RK3399 "warm" boots. Because there's currently only one user of sysreset-gpio logic, and TPL is enabled on that board, so let's migrate the logic and that board to do it in TPL.
There are three reasons for moving this earlier:
Yes, this movement is reasonable and needed for this workaround, although still not
understand why puma board need this.
- faster boot time as we don't need to reach SPL to be able to reset the system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
So with this patch set, we can see the TPL banner twice ?
PS: We are able to merge to master instead of next before next branch is open, because we still have
enough time to debug before next release.
Thanks, - Kever
possibly hinting at an issue within the SPL when loading the fitImage from MMC2 instead of the normal course of events (a system reset).
Signed-off-by: Quentin Schulz quentin.schulz@cherry.de
arch/arm/mach-rockchip/rk3399/rk3399.c | 15 ++++++++++----- configs/puma-rk3399_defconfig | 3 +++ 2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 7b6a822ed04b8151a5da147056dbf73ffdafd149..0c28241c603e343c5140322f2778678e95fa84fd 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -169,7 +169,8 @@ void board_debug_uart_init(void) } #endif
-#if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD) +#if defined(CONFIG_XPL_BUILD) +#if defined(CONFIG_TPL_BUILD) static void rk3399_force_power_on_reset(void) { const struct rockchip_cru *cru = rockchip_get_cru(); @@ -195,9 +196,9 @@ static void rk3399_force_power_on_reset(void) if (cru->glb_rst_st == 0) return;
- if (!IS_ENABLED(CONFIG_SPL_GPIO)) {
- if (!IS_ENABLED(CONFIG_TPL_GPIO)) { debug("%s: trying to force a power-on reset but no GPIO "
"support in SPL!\n", __func__);
"support in TPL!\n", __func__);@@ -218,6 +219,11 @@ static void rk3399_force_power_on_reset(void) dm_gpio_set_value(&sysreset_gpio, 1); }
+void tpl_board_init(void) +{
- rk3399_force_power_on_reset();
+} +# else void __weak led_setup(void) { } @@ -225,7 +231,6 @@ void __weak led_setup(void) void spl_board_init(void) { led_setup();
- rk3399_force_power_on_reset(); } #endif
+#endif diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 67c0ee72c925cdd49066980b0fde4131c86a99a8..7a180b1413036234d834773778f6c0f0a7e85380 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_POWER=y CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y +CONFIG_TPL_GPIO=y # CONFIG_BOOTM_NETBSD is not set # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set @@ -78,6 +79,8 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_TPL_PINCTRL=y +CONFIG_TPL_PINCTRL_FULL=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_SPL_PMIC_RK8XX=y
Hi Kever,
On 11/7/24 8:14 AM, Kever Yang wrote:
Hi Quentin,
On 2024/11/6 19:29, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@cherry.de
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is provided in the TPL Device Tree, this will trigger a system reset similar to what's currently been done in SPL whenever the RK3399 "warm" boots. Because there's currently only one user of sysreset-gpio logic, and TPL is enabled on that board, so let's migrate the logic and that board to do it in TPL.
There are three reasons for moving this earlier:
Yes, this movement is reasonable and needed for this workaround, although still not
understand why puma board need this.
Me neither, this predates me joining the company, c.f.: https://source.denx.de/u-boot/u-boot/-/commit/ae0d33a7291a164a11ae034bcf4f71... https://source.denx.de/u-boot/u-boot/-/commit/5f104178bf713615dc404fdfcf0fb5... https://source.denx.de/u-boot/u-boot/-/commit/07586ee4322abca01db52624b925e5...
What I can tell you is that it seems this is required as Paul (in Cc) is trying to add support for it for the Firefly ROC-RK3399-PC[1] and the ROCKPro64[2], so it seems it's useful for **some** purpose.
[1] https://lore.kernel.org/u-boot/20240926183111.1324284-1-paulk@sys-base.io/ [2] https://lore.kernel.org/u-boot/20240926183111.1324284-2-paulk@sys-base.io/
- faster boot time as we don't need to reach SPL to be able to reset the
system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works
around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from
SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
So with this patch set, we can see the TPL banner twice ?
PS: We are able to merge to master instead of next before next branch is open, because we still have
enough time to debug before next release.
My understanding is that once -rc1 is out, we should only do bug fixing in master. BUT at the same time, next branch isn't actually open until -rc2.
Up to you! It's not really urgent, Puma was migrated to TPL only in v2023.01 and we've lived without sysreset-gpio in TPL since then :)
Cheers, Quentin
Hi,
Le Thu 07 Nov 24, 12:04, Quentin Schulz a écrit :
On 11/7/24 8:14 AM, Kever Yang wrote:
Yes, this movement is reasonable and needed for this workaround, although still not
understand why puma board need this.
Me neither, this predates me joining the company, c.f.: https://source.denx.de/u-boot/u-boot/-/commit/ae0d33a7291a164a11ae034bcf4f71... https://source.denx.de/u-boot/u-boot/-/commit/5f104178bf713615dc404fdfcf0fb5... https://source.denx.de/u-boot/u-boot/-/commit/07586ee4322abca01db52624b925e5...
What I can tell you is that it seems this is required as Paul (in Cc) is trying to add support for it for the Firefly ROC-RK3399-PC[1] and the ROCKPro64[2], so it seems it's useful for **some** purpose.
The initial issue I was seeing was that one of the MMC controllers showed some errors and failed to read data after reboot, while it always worked on cold boot. With this feature enabled, it worked reliably after reboot.
I didn't investigate exactly which component (maybe clocks, maybe regulators) caused the problem, but it clearly wasn't correctly reset.
Cheers,
Paul
[1] https://lore.kernel.org/u-boot/20240926183111.1324284-1-paulk@sys-base.io/ [2] https://lore.kernel.org/u-boot/20240926183111.1324284-2-paulk@sys-base.io/
- faster boot time as we don't need to reach SPL to be able to reset the
system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works
around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from
SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
So with this patch set, we can see the TPL banner twice ?
PS: We are able to merge to master instead of next before next branch is open, because we still have
enough time to debug before next release.
My understanding is that once -rc1 is out, we should only do bug fixing in master. BUT at the same time, next branch isn't actually open until -rc2.
Up to you! It's not really urgent, Puma was migrated to TPL only in v2023.01 and we've lived without sysreset-gpio in TPL since then :)
Cheers, Quentin
Hi Paul,
On 2024/11/7 20:27, Paul Kocialkowski wrote:
Hi,
Le Thu 07 Nov 24, 12:04, Quentin Schulz a écrit :
On 11/7/24 8:14 AM, Kever Yang wrote:
Yes, this movement is reasonable and needed for this workaround, although still not
understand why puma board need this.
Me neither, this predates me joining the company, c.f.: https://source.denx.de/u-boot/u-boot/-/commit/ae0d33a7291a164a11ae034bcf4f71... https://source.denx.de/u-boot/u-boot/-/commit/5f104178bf713615dc404fdfcf0fb5... https://source.denx.de/u-boot/u-boot/-/commit/07586ee4322abca01db52624b925e5...
What I can tell you is that it seems this is required as Paul (in Cc) is trying to add support for it for the Firefly ROC-RK3399-PC[1] and the ROCKPro64[2], so it seems it's useful for **some** purpose.
The initial issue I was seeing was that one of the MMC controllers showed some errors and failed to read data after reboot, while it always worked on cold boot. With this feature enabled, it worked reliably after reboot.
I didn't investigate exactly which component (maybe clocks, maybe regulators) caused the problem, but it clearly wasn't correctly reset.
Are you able to check, how is the 'reboot' happen, does it use the system_reset API from the ATF?
Because there are some operations for clock and PD before trigger the global reset in ATF driver
and the code is very stable and used for millions of devices.
Thanks, - Kever
Cheers,
Paul
[1] https://lore.kernel.org/u-boot/20240926183111.1324284-1-paulk@sys-base.io/ [2] https://lore.kernel.org/u-boot/20240926183111.1324284-2-paulk@sys-base.io/
- faster boot time as we don't need to reach SPL to be able to reset the
system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works
around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from
SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
So with this patch set, we can see the TPL banner twice ?
PS: We are able to merge to master instead of next before next branch is open, because we still have
enough time to debug before next release.
My understanding is that once -rc1 is out, we should only do bug fixing in master. BUT at the same time, next branch isn't actually open until -rc2.
Up to you! It's not really urgent, Puma was migrated to TPL only in v2023.01 and we've lived without sysreset-gpio in TPL since then :)
Cheers, Quentin
Hello Kever,
On 2024-11-08 01:50, Kever Yang wrote:
On 2024/11/7 20:27, Paul Kocialkowski wrote:
Le Thu 07 Nov 24, 12:04, Quentin Schulz a écrit :
On 11/7/24 8:14 AM, Kever Yang wrote:
Yes, this movement is reasonable and needed for this workaround, although still not
understand why puma board need this.
Me neither, this predates me joining the company, c.f.: https://source.denx.de/u-boot/u-boot/-/commit/ae0d33a7291a164a11ae034bcf4f71... https://source.denx.de/u-boot/u-boot/-/commit/5f104178bf713615dc404fdfcf0fb5... https://source.denx.de/u-boot/u-boot/-/commit/07586ee4322abca01db52624b925e5...
What I can tell you is that it seems this is required as Paul (in Cc) is trying to add support for it for the Firefly ROC-RK3399-PC[1] and the ROCKPro64[2], so it seems it's useful for **some** purpose.
The initial issue I was seeing was that one of the MMC controllers showed some errors and failed to read data after reboot, while it always worked on cold boot. With this feature enabled, it worked reliably after reboot.
I didn't investigate exactly which component (maybe clocks, maybe regulators) caused the problem, but it clearly wasn't correctly reset.
Are you able to check, how is the 'reboot' happen, does it use the system_reset API from the ATF?
Because there are some operations for clock and PD before trigger the global reset in ATF driver and the code is very stable and used for millions of devices.
The Linux kernel performs resets using PSCI_0_2_FN_SYSTEM_RESET made available by TF-A, which ends up using GLB_SRST_FST_CFG_VAL, also known as the RK3390's global software reset 1, which I'll describe a bit further later in my response.
In this particular case and to the best of my knowledge, it isn't up to the way the SoC reset is initiated and performed, but up to the way RK3399 (mis)performs the global software reset 1.
Here's a quotation from arch/arm/mach-rockchip/rk3399/rk3399.c that explains this issue a bit further:
/* * The RK3399 resets only 'almost all logic' (see also in the * TRM "3.9.4 Global software reset"), when issuing a software * reset. This may cause issues during boot-up for some * configurations of the application software stack. * * To work around this, we test whether the last reset reason * was a power-on reset and (if not) issue an overtemp-reset to * reset the entire module. * * While this was previously fixed by modifying the various * places that could generate a software reset (e.g. U-Boot's * sysreset driver, the ATF or Linux), we now have it here to * ensure that we no longer have to track this through the * various components. */
The logic associated with this comment, currently residing in arch/arm/mach-rockchip/rk3399/rk3399.c, was actually introduced in the commit ae0d33a7291a (rockchip: rk3399-puma: add code to allow forcing a power-on reset, 2017-11-28).
As described in section 3.4 of the RK3399 TRM, part 1 of the version 1.1, the RK3399 provides two global software reset types, out of which TF-A, as already described, properly performs the global software reset 1. Alas, section 3.9.4 of the RK3399 TRM specifies that "almost all logic" gets reset, which is the source of all troubles, resulting in the need to perform hardware resets using (or better said, abusing a bit) the PMIC's overtemperature protection (OTP) interface/pin.
I hope all this makes sense.
[1] https://lore.kernel.org/u-boot/20240926183111.1324284-1-paulk@sys-base.io/ [2] https://lore.kernel.org/u-boot/20240926183111.1324284-2-paulk@sys-base.io/
- faster boot time as we don't need to reach SPL to be able to
reset the system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset
works around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done
from SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
So with this patch set, we can see the TPL banner twice ?
PS: We are able to merge to master instead of next before next branch is open, because we still have
enough time to debug before next release.
My understanding is that once -rc1 is out, we should only do bug fixing in master. BUT at the same time, next branch isn't actually open until -rc2.
Up to you! It's not really urgent, Puma was migrated to TPL only in v2023.01 and we've lived without sysreset-gpio in TPL since then :)
Hi,
Le Wed 06 Nov 24, 12:29, Quentin Schulz a écrit :
From: Quentin Schulz quentin.schulz@cherry.de
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is provided in the TPL Device Tree, this will trigger a system reset similar to what's currently been done in SPL whenever the RK3399 "warm" boots. Because there's currently only one user of sysreset-gpio logic, and TPL is enabled on that board, so let's migrate the logic and that board to do it in TPL.
There are three reasons for moving this earlier:
- faster boot time as we don't need to reach SPL to be able to reset the system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
possibly hinting at an issue within the SPL when loading the fitImage from MMC2 instead of the normal course of events (a system reset).
Signed-off-by: Quentin Schulz quentin.schulz@cherry.de
Thanks for keeping it only in TPL!
Reviewed-by: Paul Kocialkowski paulk@sys-base.io
With just one small nit below:
arch/arm/mach-rockchip/rk3399/rk3399.c | 15 ++++++++++----- configs/puma-rk3399_defconfig | 3 +++ 2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 7b6a822ed04b8151a5da147056dbf73ffdafd149..0c28241c603e343c5140322f2778678e95fa84fd 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -169,7 +169,8 @@ void board_debug_uart_init(void) } #endif
-#if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD) +#if defined(CONFIG_XPL_BUILD) +#if defined(CONFIG_TPL_BUILD) static void rk3399_force_power_on_reset(void) { const struct rockchip_cru *cru = rockchip_get_cru(); @@ -195,9 +196,9 @@ static void rk3399_force_power_on_reset(void) if (cru->glb_rst_st == 0) return;
- if (!IS_ENABLED(CONFIG_SPL_GPIO)) {
- if (!IS_ENABLED(CONFIG_TPL_GPIO)) { debug("%s: trying to force a power-on reset but no GPIO "
"support in SPL!\n", __func__);
"support in TPL!\n", __func__);@@ -218,6 +219,11 @@ static void rk3399_force_power_on_reset(void) dm_gpio_set_value(&sysreset_gpio, 1); }
+void tpl_board_init(void) +{
- rk3399_force_power_on_reset();
+} +# else
No whitespace before "else" here.
void __weak led_setup(void) { } @@ -225,7 +231,6 @@ void __weak led_setup(void) void spl_board_init(void) { led_setup();
- rk3399_force_power_on_reset();
} #endif +#endif diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 67c0ee72c925cdd49066980b0fde4131c86a99a8..7a180b1413036234d834773778f6c0f0a7e85380 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_POWER=y CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y +CONFIG_TPL_GPIO=y # CONFIG_BOOTM_NETBSD is not set # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set @@ -78,6 +79,8 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_TPL_PINCTRL=y +CONFIG_TPL_PINCTRL_FULL=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_SPL_PMIC_RK8XX=y
-- 2.47.0
On 2024/11/6 19:29, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@cherry.de
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is provided in the TPL Device Tree, this will trigger a system reset similar to what's currently been done in SPL whenever the RK3399 "warm" boots. Because there's currently only one user of sysreset-gpio logic, and TPL is enabled on that board, so let's migrate the logic and that board to do it in TPL.
There are three reasons for moving this earlier:
- faster boot time as we don't need to reach SPL to be able to reset the system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from SPL, the following log can be observed:
""" U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) Channel 0: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: DDR3, 666MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """
possibly hinting at an issue within the SPL when loading the fitImage from MMC2 instead of the normal course of events (a system reset).
Signed-off-by: Quentin Schulz quentin.schulz@cherry.de
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
arch/arm/mach-rockchip/rk3399/rk3399.c | 15 ++++++++++----- configs/puma-rk3399_defconfig | 3 +++ 2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 7b6a822ed04b8151a5da147056dbf73ffdafd149..0c28241c603e343c5140322f2778678e95fa84fd 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -169,7 +169,8 @@ void board_debug_uart_init(void) } #endif
-#if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD) +#if defined(CONFIG_XPL_BUILD) +#if defined(CONFIG_TPL_BUILD) static void rk3399_force_power_on_reset(void) { const struct rockchip_cru *cru = rockchip_get_cru(); @@ -195,9 +196,9 @@ static void rk3399_force_power_on_reset(void) if (cru->glb_rst_st == 0) return;
- if (!IS_ENABLED(CONFIG_SPL_GPIO)) {
- if (!IS_ENABLED(CONFIG_TPL_GPIO)) { debug("%s: trying to force a power-on reset but no GPIO "
"support in SPL!\n", __func__);
"support in TPL!\n", __func__);@@ -218,6 +219,11 @@ static void rk3399_force_power_on_reset(void) dm_gpio_set_value(&sysreset_gpio, 1); }
+void tpl_board_init(void) +{
- rk3399_force_power_on_reset();
+} +# else void __weak led_setup(void) { } @@ -225,7 +231,6 @@ void __weak led_setup(void) void spl_board_init(void) { led_setup();
- rk3399_force_power_on_reset(); } #endif
+#endif diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 67c0ee72c925cdd49066980b0fde4131c86a99a8..7a180b1413036234d834773778f6c0f0a7e85380 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_POWER=y CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y +CONFIG_TPL_GPIO=y # CONFIG_BOOTM_NETBSD is not set # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set @@ -78,6 +79,8 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_TPL_PINCTRL=y +CONFIG_TPL_PINCTRL_FULL=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_SPL_PMIC_RK8XX=y
participants (5)
-
Dragan Simic -
Kever Yang -
Paul Kocialkowski -
Quentin Schulz -
Quentin Schulz