diff options
Diffstat (limited to 'package/boot/uboot-mvebu')
3 files changed, 152 insertions, 0 deletions
diff --git a/package/boot/uboot-mvebu/patches/100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch b/package/boot/uboot-mvebu/patches/100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch new file mode 100644 index 0000000000..4b8706e56f --- /dev/null +++ b/package/boot/uboot-mvebu/patches/100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch @@ -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, diff --git a/package/boot/uboot-mvebu/patches/101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch b/package/boot/uboot-mvebu/patches/101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch new file mode 100644 index 0000000000..d7ba3ec68f --- /dev/null +++ b/package/boot/uboot-mvebu/patches/101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch @@ -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 + diff --git a/package/boot/uboot-mvebu/patches/102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch b/package/boot/uboot-mvebu/patches/102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch new file mode 100644 index 0000000000..30215aa4e2 --- /dev/null +++ b/package/boot/uboot-mvebu/patches/102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch @@ -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 |