aboutsummaryrefslogtreecommitdiffstats
path: root/package/boot
diff options
context:
space:
mode:
authorJosef Schlehofer <pepe.schlehofer@gmail.com>2022-01-28 13:39:45 +0100
committerHauke Mehrtens <hauke@hauke-m.de>2022-02-03 21:24:26 +0100
commitd16bd89c71da6bad5f4d37008217ced3bac4e5d6 (patch)
treeecb2e6ee8185b4d35faee3eb6cc2a534283110b2 /package/boot
parent5c804bc199e43e7d41af3242cba950f88bb29807 (diff)
downloadupstream-d16bd89c71da6bad5f4d37008217ced3bac4e5d6.tar.gz
upstream-d16bd89c71da6bad5f4d37008217ced3bac4e5d6.tar.bz2
upstream-d16bd89c71da6bad5f4d37008217ced3bac4e5d6.zip
uboot-mvebu: backport two patches for Marvell A38x
This solves issue with DDR training on Turris Omnia. Log: ******** DRAM initialization Failed (res 0x1) ******** DDR3 Training Sequence - FAILED ERROR ### Please RESET the board ### Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Diffstat (limited to 'package/boot')
-rw-r--r--package/boot/uboot-mvebu/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch116
-rw-r--r--package/boot/uboot-mvebu/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch98
2 files changed, 214 insertions, 0 deletions
diff --git a/package/boot/uboot-mvebu/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch b/package/boot/uboot-mvebu/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch
new file mode 100644
index 0000000000..17ff86223c
--- /dev/null
+++ b/package/boot/uboot-mvebu/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch
@@ -0,0 +1,116 @@
+From 3fc92a215b69ad448c151489228eb340df9a8703 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
+Date: Wed, 12 Jan 2022 17:06:59 +0100
+Subject: [PATCH] ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is a cleaned up and fixed version of a patch
+ mv_ddr: a380: fix SPLIT_OUT_MIX state decision
+
+ in each pattern cycle the bus state can be changed
+ in order to avoide it, need to back to the same bus state on each
+ pattern cycle
+by
+ Moti Boskula <motib@marvell.com>
+
+The original patch is not in Marvell's mv-ddr-marvell repository. It was
+gives to us by Marvell to fix an issues with DDR training on some
+boards, but it cannot be applied as is to mv-ddr-marvell, because it is
+a very dirty draft patch that would certainly break other things, mainly
+DDR4 training code in mv-ddr-marvell, since it changes common functions.
+
+I have cleaned up the patch and removed stuff that seemed unnecessary
+(when removed, it still fixed things). Note that I don't understand
+completely what the code does exactly, since I haven't studied the DDR
+training code extensively (and I suspect that no one besides some few
+people in Marvell understand the code completely).
+
+Anyway after the cleanup the patch still fixes isssues with DDR training
+on the failing boards.
+
+There was also a problem with the original patch on some of the Allied
+Telesis' x530 boards, reported by Chris Packham. I have asked Chris to
+send me some logs, and managed to fix it:
+- if you look at the change, you'll notice that it introduces
+ subtraction of cur_start_win[] and cur_end_win[] members, depending on
+ a bit set in the current_byte_status variable
+- the original patch subtracted cur_start_win[] if either
+ BYTE_SPLIT_OUT_MIX or BYTE_HOMOGENEOUS_SPLIT_OUT bits were set, but
+ subtracted cur_end_win[] only if the first one (BYTE_SPLIT_OUT_MIX)
+ was set
+- from Chris Packham logs I discovered that the x530 board where the
+ original patch introduced DDR training failure, only the
+ BYTE_HOMOGENEOUS_SPLIT_OUT bit was set, and on our boards where the
+ patch is needed only the BYTE_SPLIT_OUT_MIX is set in the
+ current_byte_status variable
+- this led me to the hypothesis that both cur_start_win[] and
+ cur_end_win[] should be subtracted only if BYTE_SPLIT_OUT_MIX bit is
+ set, the BYTE_HOMOGENEOUS_SPLIT_OUT bit shouldn't be considered at all
+- this hypothesis also gains credibility when considering the commit
+ title ("fix SPLIT_OUT_MIX state decision")
+
+Hopefully this will fix things without breaking anything else.
+
+Signed-off-by: Marek BehĂșn <marek.behun@nic.cz>
+Reviewed-by: Stefan Roese <sr@denx.de>
+Tested-by: Chris Packham <judge.packham@gmail.com>
+---
+ .../a38x/ddr3_training_centralization.c | 26 +++++++++++++++++++
+ 1 file changed, 26 insertions(+)
+
+--- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
++++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
+@@ -55,6 +55,7 @@ static int ddr3_tip_centralization(u32 d
+ enum hws_training_ip_stat training_result[MAX_INTERFACE_NUM];
+ u32 if_id, pattern_id, bit_id;
+ u8 bus_id;
++ u8 current_byte_status;
+ u8 cur_start_win[BUS_WIDTH_IN_BITS];
+ u8 centralization_result[MAX_INTERFACE_NUM][BUS_WIDTH_IN_BITS];
+ u8 cur_end_win[BUS_WIDTH_IN_BITS];
+@@ -166,6 +167,10 @@ static int ddr3_tip_centralization(u32 d
+ result[search_dir_id][7]));
+ }
+
++ current_byte_status =
++ mv_ddr_tip_sub_phy_byte_status_get(if_id,
++ bus_id);
++
+ for (bit_id = 0; bit_id < BUS_WIDTH_IN_BITS;
+ bit_id++) {
+ /* check if this code is valid for 2 edge, probably not :( */
+@@ -174,11 +179,32 @@ static int ddr3_tip_centralization(u32 d
+ [HWS_LOW2HIGH]
+ [bit_id],
+ EDGE_1);
++ if (current_byte_status &
++ BYTE_SPLIT_OUT_MIX) {
++ if (cur_start_win[bit_id] >= 64)
++ cur_start_win[bit_id] -= 64;
++ else
++ cur_start_win[bit_id] = 0;
++ DEBUG_CENTRALIZATION_ENGINE
++ (DEBUG_LEVEL_INFO,
++ ("pattern %d IF %d pup %d bit %d subtract 64 adll from start\n",
++ pattern_id, if_id, bus_id, bit_id));
++ }
+ cur_end_win[bit_id] =
+ GET_TAP_RESULT(result
+ [HWS_HIGH2LOW]
+ [bit_id],
+ EDGE_1);
++ if (cur_end_win[bit_id] >= 64 &&
++ (current_byte_status &
++ BYTE_SPLIT_OUT_MIX)) {
++ cur_end_win[bit_id] -= 64;
++ DEBUG_CENTRALIZATION_ENGINE
++ (DEBUG_LEVEL_INFO,
++ ("pattern %d IF %d pup %d bit %d subtract 64 adll from end\n",
++ pattern_id, if_id, bus_id, bit_id));
++ }
++
+ /* window length */
+ current_window[bit_id] =
+ cur_end_win[bit_id] -
diff --git a/package/boot/uboot-mvebu/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch b/package/boot/uboot-mvebu/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch
new file mode 100644
index 0000000000..9da1459a7d
--- /dev/null
+++ b/package/boot/uboot-mvebu/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch
@@ -0,0 +1,98 @@
+From eadc4f512fb43bba2fa4e842c982da919da664be Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
+Date: Tue, 4 Jan 2022 15:57:49 +0100
+Subject: [PATCH] ddr: marvell: a38x: Fix Synchronous vs Asynchronous mode
+ determination
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
+mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
+Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
+2 GHz and DDR at 933 MHz.
+
+Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
+mode") added support for Asynchornous Modes with frequencies other than
+933 MHz (but at least 467 MHz), but the code it added to check for
+whether Asynchornous Mode should be used is wrong: it checks whether the
+frequency setting in board DDR topology map is set to value other than
+MV_DDR_FREQ_SAR.
+
+Thus boards which define a specific value, greater than 400 MHz, for DDR
+frequency in their board topology (e.g. Turris Omnia defines
+MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
+commit.
+
+The A38x Functional Specification, section 10.12 DRAM Clocking, says:
+ In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
+ in 1:2 or 1:3 CPU to DRAM frequency ratios.
+
+Change the check for whether Asynchornous Mode should be used according
+to this explanation in Functional Specification.
+
+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/mv_ddr_plat.c | 19 ++++++++-----------
+ 1 file changed, 8 insertions(+), 11 deletions(-)
+
+--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
++++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+@@ -167,8 +167,6 @@ static u16 a38x_vco_freq_per_sar_ref_clk
+ };
+
+
+-static u32 async_mode_at_tf;
+-
+ static u32 dq_bit_map_2_phy_pin[] = {
+ 1, 0, 2, 6, 9, 8, 3, 7, /* 0 */
+ 8, 9, 1, 7, 2, 6, 3, 0, /* 1 */
+@@ -734,7 +732,8 @@ static int ddr3_tip_a38x_set_divider(u8
+ u32 divider = 0;
+ u32 sar_val, ref_clk_satr;
+ u32 async_val;
+- u32 freq = mv_ddr_freq_get(frequency);
++ u32 cpu_freq;
++ u32 ddr_freq = mv_ddr_freq_get(frequency);
+
+ if (if_id != 0) {
+ DEBUG_TRAINING_ACCESS(DEBUG_LEVEL_ERROR,
+@@ -751,11 +750,14 @@ static int ddr3_tip_a38x_set_divider(u8
+ ref_clk_satr = reg_read(DEVICE_SAMPLE_AT_RESET2_REG);
+ if (((ref_clk_satr >> DEVICE_SAMPLE_AT_RESET2_REG_REFCLK_OFFSET) & 0x1) ==
+ DEVICE_SAMPLE_AT_RESET2_REG_REFCLK_25MHZ)
+- divider = a38x_vco_freq_per_sar_ref_clk_25_mhz[sar_val] / freq;
++ cpu_freq = a38x_vco_freq_per_sar_ref_clk_25_mhz[sar_val];
+ else
+- divider = a38x_vco_freq_per_sar_ref_clk_40_mhz[sar_val] / freq;
++ cpu_freq = a38x_vco_freq_per_sar_ref_clk_40_mhz[sar_val];
++
++ divider = cpu_freq / ddr_freq;
+
+- if ((async_mode_at_tf == 1) && (freq > 400)) {
++ if (((cpu_freq % ddr_freq != 0) || (divider != 2 && divider != 3)) &&
++ (ddr_freq > 400)) {
+ /* Set async mode */
+ dunit_write(0x20220, 0x1000, 0x1000);
+ dunit_write(0xe42f4, 0x200, 0x200);
+@@ -869,8 +871,6 @@ int ddr3_tip_ext_write(u32 dev_num, u32
+
+ int mv_ddr_early_init(void)
+ {
+- struct mv_ddr_topology_map *tm = mv_ddr_topology_map_get();
+-
+ /* FIXME: change this configuration per ddr type
+ * configure a380 and a390 to work with receiver odt timing
+ * the odt_config is defined:
+@@ -882,9 +882,6 @@ int mv_ddr_early_init(void)
+
+ mv_ddr_sw_db_init(0, 0);
+
+- if (tm->interface_params[0].memory_freq != MV_DDR_FREQ_SAR)
+- async_mode_at_tf = 1;
+-
+ return MV_OK;
+ }
+