On 2/17/22 12:37, Pali Rohár wrote:
On Thursday 17 February 2022 01:08:48 Marek Behún wrote:
From: Marek Behún <marek.be...@nic.cz>
Some boards may occacionally fail DDR training. Currently we hang() in
this case. Add an option that makes the board do an immediate reset in
such a case, so that a new training is tried as soon as possible,
instead of hanging and possibly waiting for watchdog to reset the board.
Signed-off-by: Marek Behún <marek.be...@nic.cz>
Reviewed-by: Stefan Roese <s...@denx.de>
---
arch/arm/mach-mvebu/Kconfig | 9 +++++++++
arch/arm/mach-mvebu/spl.c | 6 +++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d23cc0c760..ed957be6e1 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -213,6 +213,15 @@ config DDR_LOG_LEVEL
At level 3, rovides the windows margin of each DQ as a results of
DQS centeralization.
+config DDR_RESET_ON_TRAINING_FAILURE
+ bool "Reset the board on DDR training failure instead of hanging"
+ depends on ARMADA_38X || ARMADA_XP
+ help
+ If DDR training fails in SPL, reset the board instead of hanging.
+ Some boards are known to fail DDR training occasionally and an
+ immediate reset may be preferable to waiting until the board is
+ reset by watchdog (if there even is one).
+
config SYS_BOARD
default "clearfog" if TARGET_CLEARFOG
default "helios4" if TARGET_HELIOS4
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 273ecb8bd6..d3c3bdc74d 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -4,6 +4,7 @@
*/
#include <common.h>
+#include <cpu_func.h>
#include <dm.h>
#include <fdtdec.h>
#include <hang.h>
@@ -330,7 +331,10 @@ void board_init_f(ulong dummy)
ret = ddr3_init();
if (ret) {
printf("ddr3_init() failed: %d\n", ret);
- hang();
+ if (IS_ENABLED(CONFIG_DDR_RESET_ON_TRAINING_FAILURE))
+ reset_cpu();
You should not call reset_cpu() from SPL loaded via UART. This will
confuse x-modem software. Either return failure to BootROM or hang()
like it was before.
I see that this might confuse the kwboot / x-modem use-case. But AFAIU,
this is more targeted to the normal use-case, that the board boots from
SPI NOR (etc). And here, a complete re-start could be helpful to at
least get the board up and running after a few retries.
Or am I missing something?
Thanks,
Stefan
