[PATCH] mx7ulp: soc: s_init should only be executed once
On SPL enabled systems, the current s_init code (wdog, clock and ldo init) is executed twice (by SPL and u-boot). This is not necessary and might lead to boot issues (ie, starting PMC1 when it is already running).
Signed-off-by: Jorge Ramirez-Ortiz jorge@foundries.io --- arch/arm/mach-imx/mx7ulp/soc.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c index 8345b01398..316262f71b 100644 --- a/arch/arm/mach-imx/mx7ulp/soc.c +++ b/arch/arm/mach-imx/mx7ulp/soc.c @@ -117,6 +117,7 @@ void init_wdog(void) disable_wdog(WDG2_RBASE); }
+#if !defined(CONFIG_SPL) || (defined(CONFIG_SPL) && defined(CONFIG_SPL_BUILD)) #if defined(CONFIG_LDO_ENABLED_MODE) static void init_ldo_mode(void) { @@ -174,6 +175,7 @@ void s_init(void) #endif return; } +#endif
#ifndef CONFIG_ULP_WATCHDOG void reset_cpu(ulong addr)
Hi Jorge,
On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz jorge@foundries.io wrote:
On SPL enabled systems, the current s_init code (wdog, clock and ldo init) is executed twice (by SPL and u-boot). This is not necessary and might lead to boot issues (ie, starting PMC1 when it is already running).
Signed-off-by: Jorge Ramirez-Ortiz jorge@foundries.io
The target I use to test LDO-enabled mode does not use SPL, so that's why I did not notice the problem.
Thanks for the fix:
Reviewed-by: Fabio Estevam festevam@gmail.com
On 17/01/20 08:53:03, Fabio Estevam wrote:
Hi Jorge,
On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz jorge@foundries.io wrote:
On SPL enabled systems, the current s_init code (wdog, clock and ldo init) is executed twice (by SPL and u-boot). This is not necessary and might lead to boot issues (ie, starting PMC1 when it is already running).
Signed-off-by: Jorge Ramirez-Ortiz jorge@foundries.io
The target I use to test LDO-enabled mode does not use SPL, so that's why I did not notice the problem.
Thanks for the fix:
Hi Favio,
sorry I forgot to mention: this does not fix the issue I see when executing the LDO init code - that still locks when run from SPL or U-Boot. This commit is just because I noticed that s_init was being called twice (for SPL and U-Boot) and I dont think it makes sense.
Reviewed-by: Fabio Estevam festevam@gmail.com
On 17/01/20 13:08:44, Jorge Ramirez-Ortiz, Gmail wrote:
On 17/01/20 08:53:03, Fabio Estevam wrote:
Hi Jorge,
On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz jorge@foundries.io wrote:
On SPL enabled systems, the current s_init code (wdog, clock and ldo init) is executed twice (by SPL and u-boot). This is not necessary and might lead to boot issues (ie, starting PMC1 when it is already running).
Signed-off-by: Jorge Ramirez-Ortiz jorge@foundries.io
The target I use to test LDO-enabled mode does not use SPL, so that's why I did not notice the problem.
Thanks for the fix:
Hi Favio,
sorry I forgot to mention: this does not fix the issue I see when executing the LDO init code - that still locks when run from SPL or U-Boot. This commit is just because I noticed that s_init was being called twice (for SPL and U-Boot) and I dont think it makes sense.
Reviewed-by: Fabio Estevam festevam@gmail.com
hi Favio/all
plese could you confirm if this patch will be merged (just so we dont have to carry it separately in our product branches)
thanks! Jorge
Hi Jorge,
On Sun, Jan 19, 2020 at 3:52 PM Jorge Ramirez-Ortiz, Foundries jorge@foundries.io wrote:
hi Favio/all
plese could you confirm if this patch will be merged (just so we dont have to carry it separately in our product branches)
Yes, I think it makes sense to apply it. I have already given my Reviewed-by tag.
On SPL enabled systems, the current s_init code (wdog, clock and ldo init) is executed twice (by SPL and u-boot). This is not necessary and might lead to boot issues (ie, starting PMC1 when it is already running). Signed-off-by: Jorge Ramirez-Ortiz jorge@foundries.io Reviewed-by: Fabio Estevam festevam@gmail.com
Applied to u-boot-imx, master, thanks !
Best regards, Stefano Babic
participants (5)
-
Fabio Estevam -
Jorge Ramirez-Ortiz -
Jorge Ramirez-Ortiz, Foundries
-
Jorge Ramirez-Ortiz, Gmail -
sbabic＠denx.de