uboot-mvebu: backport pending patches for Marvell A38x

100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch [1]:
SoC Marvell A38x is used in Turris Omnia, and we thought that with recent
fiddling around DDR training to fix it once for all, there were
reproduced the issue in the upcoming new revision Turris Omnia boards.

101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch [2]:
This is useful when some board may occasionally fail with DDR training,
and it adds the option to reset the board on the DDR training failure

102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch [3]:
This enables the option CONFIG_DDR_RESET_ON_TRAINING_FAILURE (added by
101 patch), so the Turris Omnia board is restarted immediately, and it
does not require to reset the board manually or wait 120s for MCU to
reset the board

[1] https://patchwork.ozlabs.org/project/uboot/patch/20220217000837.13003-1-kabel@kernel.org/
[2] https://patchwork.ozlabs.org/project/uboot/patch/20220217000849.13028-1-kabel@kernel.org/
[3] https://patchwork.ozlabs.org/project/uboot/patch/20220217000849.13028-2-kabel@kernel.org/

Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
This commit is contained in:
Josef Schlehofer 2022-02-17 10:01:29 +01:00 committed by Christian Lamparter
parent 82da1dfd69
commit 696f0a1cb4
3 changed files with 152 additions and 0 deletions

View File

@ -0,0 +1,65 @@
From c11428c7def52671f57089701efe878f7071b696 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
Date: Thu, 17 Feb 2022 01:08:37 +0100
Subject: [PATCH 1/3] ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT
decision
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In commit 3fc92a215b69 ("ddr: marvell: a38x: fix SPLIT_OUT_MIX state
decision") I ported a cleaned up and changed version of patch
mv_ddr: a380: fix SPLIT_OUT_MIX state decision
In the port we removed checking for BYTE_HOMOGENEOUS_SPLIT_OUT bit,
because:
- the fix seemed to work without it
- the bit was checked for only at one place out of two, while the second
bit, BYTE_SPLIT_OUT_MIX, was checked for in both cases
- without the removal it didn't work on Allied Telesis' x530 board
We recently had a chance to test on more boards, and it seems that the
change needs to be opposite: instead of removing the check for
BYTE_HOMOGENEOUS_SPLIT_OUT from the first if() statement, the check
needs to be added also to the second one - it needs to be at both
places.
With this change all the Turris Omnia boards I have had available to
test seem to work, I didn't encounter not even one failed DDR training.
As last time, I am noting that I do not understand what this code is
actually doing, I haven't studied the DDR training algorithm and
I suspect that no one will be able to explain it to U-Boot contributors,
so we are left with this blind poking in the code with testing whether
it works on several boards and hoping it doesn't break anything for
anyone :-(.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
---
drivers/ddr/marvell/a38x/ddr3_training_centralization.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
@@ -180,7 +180,8 @@ static int ddr3_tip_centralization(u32 d
[bit_id],
EDGE_1);
if (current_byte_status &
- BYTE_SPLIT_OUT_MIX) {
+ (BYTE_SPLIT_OUT_MIX |
+ BYTE_HOMOGENEOUS_SPLIT_OUT)) {
if (cur_start_win[bit_id] >= 64)
cur_start_win[bit_id] -= 64;
else
@@ -197,7 +198,8 @@ static int ddr3_tip_centralization(u32 d
EDGE_1);
if (cur_end_win[bit_id] >= 64 &&
(current_byte_status &
- BYTE_SPLIT_OUT_MIX)) {
+ (BYTE_SPLIT_OUT_MIX |
+ BYTE_HOMOGENEOUS_SPLIT_OUT))) {
cur_end_win[bit_id] -= 64;
DEBUG_CENTRALIZATION_ENGINE
(DEBUG_LEVEL_INFO,

View File

@ -0,0 +1,49 @@
From 74767a3875c99b1a3d2818456a5fdc02ec1e4f93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
Date: Thu, 17 Feb 2022 13:54:42 +0100
Subject: [PATCH 2/3] arm: mvebu: spl: Add option to reset the board on DDR
training failure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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.
(If the DDR training fails while booting the image via UART, we will
still hang - it doesn't make sense to reset in such a case, because
after reset the board will try booting from another medium, and the
UART booting utility does not expect that.)
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
---
arch/arm/mach-mvebu/spl.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- 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 <debug_uart.h>
#include <fdtdec.h>
@@ -290,7 +291,11 @@ void board_init_f(ulong dummy)
ret = ddr3_init();
if (ret) {
debug("ddr3_init() failed: %d\n", ret);
- hang();
+ if (IS_ENABLED(CONFIG_DDR_RESET_ON_TRAINING_FAILURE) &&
+ get_boot_device() != BOOT_DEVICE_UART)
+ reset_cpu();
+ else
+ hang();
}
#endif

View File

@ -0,0 +1,38 @@
From 930c46e86123aeea1c73ae55d70ff3dcfc077992 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
Date: Thu, 17 Feb 2022 13:54:43 +0100
Subject: [PATCH 3/3] arm: mvebu: turris_omnia: Reset the board immediately on
DDR training failure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The state of the current DDR training code for Armada 38x is such that
we cannot be sure it will always train successfully - although after the
last change we were yet unable to find a board that failed DDR training,
from experience in the last 2 years we know that it is possible.
The experience also tells us that in many cases the board fails training
only sometimes, and after a reset the training is successful.
Enable the new option that makes the board reset itself on DDR training
failure immediately. Until now we called hang() in such a case, which
meant that the board was reset by the MCU after 120 seconds.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
---
configs/turris_omnia_defconfig | 1 +
1 file changed, 1 insertion(+)
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -11,6 +11,7 @@ CONFIG_NR_DRAM_BANKS=2
CONFIG_SYS_MEMTEST_START=0x00800000
CONFIG_SYS_MEMTEST_END=0x00ffffff
CONFIG_TARGET_TURRIS_OMNIA=y
+CONFIG_DDR_RESET_ON_TRAINING_FAILURE=y
CONFIG_ENV_SIZE=0x10000
CONFIG_ENV_OFFSET=0xF0000
CONFIG_ENV_SECT_SIZE=0x10000