diff options
Diffstat (limited to 'package/boot/uboot-mvebu')
-rw-r--r-- | package/boot/uboot-mvebu/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch | 116 | ||||
-rw-r--r-- | package/boot/uboot-mvebu/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch | 98 |
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; + } + |