From: Josef Schlehofer Date: Thu, 17 Feb 2022 09:01:29 +0000 (+0100) Subject: uboot-mvebu: backport pending patches for Marvell A38x X-Git-Tag: v22.03.0-rc1~372 X-Git-Url: http://git.lede-project.org./?a=commitdiff_plain;h=696f0a1cb466d580a91a62717e474bb11e3d4a53;p=openwrt%2Fstaging%2Fhauke.git 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 --- 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?= +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 +Tested-by: Chris Packham +Reviewed-by: Stefan Roese +--- + 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?= +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 +Reviewed-by: Pali Rohár +Reviewed-by: Stefan Roese +--- + 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 ++#include + #include + #include + #include +@@ -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?= +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 +Reviewed-by: Stefan Roese +Reviewed-by: Pali Rohár +--- + 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