uboot-mvebu: update to version v2022.04

Release announcement:
https://lore.kernel.org/u-boot/20220404143253.GQ14476@bill-the-cat/

Release notes between tags:
https://source.denx.de/u-boot/u-boot/-/compare/v2022.01...v2022.04?from_project_id=531

All patches were removed, since they are included in this release.

Run tested: Turris Omnia, mvebu/cortex-a9, OpenWrt daily snapshots

Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit 4f51f1fc9b3597d24de442cfff253fddce478d17)

8 files changed, 2 insertions, 524 deletions

diff --git a/package/boot/uboot-mvebu/Makefile b/package/boot/uboot-mvebu/Makefile
index a154d15dc1..25abcbeb4f 100644
--- a/package/boot/uboot-mvebu/Makefile
+++ b/package/boot/uboot-mvebu/Makefile
@@ -8,10 +8,10 @@
 include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/kernel.mk
 
-PKG_VERSION:=2022.01
+PKG_VERSION:=2022.04
 PKG_RELEASE:=$(AUTORELEASE)
 
-PKG_HASH:=81b4543227db228c03f8a1bf5ddbc813b0bb8f6555ce46064ef721a6fc680413
+PKG_HASH:=68e065413926778e276ec3abd28bb32fa82abaa4a6898d570c1f48fbdb08bcd0
 
 include $(INCLUDE_DIR)/u-boot.mk
 include $(INCLUDE_DIR)/package.mk
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
deleted file mode 100644
index 17ff86223c..0000000000
--- a/package/boot/uboot-mvebu/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch
+++ /dev/null
@@ -1,116 +0,0 @@
-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
deleted file mode 100644
index 9da1459a7d..0000000000
--- a/package/boot/uboot-mvebu/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch
+++ /dev/null
@@ -1,98 +0,0 @@
-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;
- }
- 
diff --git a/package/boot/uboot-mvebu/patches/012-nvme-Do-not-allocate-8kB-buffer-on-stack.patch b/package/boot/uboot-mvebu/patches/012-nvme-Do-not-allocate-8kB-buffer-on-stack.patch
deleted file mode 100644
index 20046c67b6..0000000000
--- a/package/boot/uboot-mvebu/patches/012-nvme-Do-not-allocate-8kB-buffer-on-stack.patch
+++ /dev/null
@@ -1,92 +0,0 @@
-From d17ab6e1289b1d705c75de8a2351218962fb7352 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
-Date: Thu, 9 Dec 2021 11:06:39 +0100
-Subject: [PATCH] nvme: Do not allocate 8kB buffer on stack
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Calling 'nvme scan' followed by 'nvme detail' crashes U-Boot on Turris
-Omnia with the following error:
-
-  undefined instruction
-  pc : [<0a000000>]          lr : [<7ff80bfc>]
-  reloc pc : [<8a8c0000>]    lr : [<00840bfc>]
-  sp : 7fb2b908  ip : 0000002a     fp : 02000000
-  r10: 04000000  r9 : 7fb2fed0     r8 : e1000000
-  r7 : 0c000000  r6 : 03000000     r5 : 06000000  r4 : 01000000
-  r3 : 7fb30928  r2 : 7fb30928     r1 : 00000000  r0 : 00000000
-  Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
-  Code: 0f0fb4f0 0f0fb4f0 0f0fb4f0 0f0fb4f0 (f0f04b0f)
-  Resetting CPU ...
-
-This happens when nvme_print_info() tries to return to the caller. It
-looks like this error is caused by trying to allocate 8 KiB of memory
-on the stack by the two uses of ALLOC_CACHE_ALIGN_BUFFER().
-
-Use malloc_cache_aligned() to allocate this memory dynamically instead.
-
-This fixes 'nvme detail' on Turris Omnia.
-
-Note that similar change was applied to file drivers/nvme/nvme.c in past by
-commit 2f83481dff9c ("nvme: use page-aligned buffer for identify command").
-
-Signed-off-by: Pali Rohár <pali@kernel.org>
-Signed-off-by: Marek Behún <marek.behun@nic.cz>
----
- drivers/nvme/nvme_show.c | 35 ++++++++++++++++++++++++++---------
- 1 file changed, 26 insertions(+), 9 deletions(-)
-
---- a/drivers/nvme/nvme_show.c
-+++ b/drivers/nvme/nvme_show.c
-@@ -106,24 +106,41 @@ int nvme_print_info(struct udevice *udev
- {
- 	struct nvme_ns *ns = dev_get_priv(udev);
- 	struct nvme_dev *dev = ns->dev;
--	ALLOC_CACHE_ALIGN_BUFFER(char, buf_ns, sizeof(struct nvme_id_ns));
--	struct nvme_id_ns *id = (struct nvme_id_ns *)buf_ns;
--	ALLOC_CACHE_ALIGN_BUFFER(char, buf_ctrl, sizeof(struct nvme_id_ctrl));
--	struct nvme_id_ctrl *ctrl = (struct nvme_id_ctrl *)buf_ctrl;
-+	struct nvme_id_ctrl *ctrl;
-+	struct nvme_id_ns *id;
-+	int ret = 0;
- 
--	if (nvme_identify(dev, 0, 1, (dma_addr_t)(long)ctrl))
--		return -EIO;
-+	ctrl = memalign(dev->page_size, sizeof(struct nvme_id_ctrl));
-+	if (!ctrl)
-+		return -ENOMEM;
-+
-+	if (nvme_identify(dev, 0, 1, (dma_addr_t)(long)ctrl)) {
-+		ret = -EIO;
-+		goto free_ctrl;
-+	}
- 
- 	print_optional_admin_cmd(le16_to_cpu(ctrl->oacs), ns->devnum);
- 	print_optional_nvm_cmd(le16_to_cpu(ctrl->oncs), ns->devnum);
- 	print_format_nvme_attributes(ctrl->fna, ns->devnum);
- 
--	if (nvme_identify(dev, ns->ns_id, 0, (dma_addr_t)(long)id))
--		return -EIO;
-+	id = memalign(dev->page_size, sizeof(struct nvme_id_ns));
-+	if (!id) {
-+		ret = -ENOMEM;
-+		goto free_ctrl;
-+	}
-+
-+	if (nvme_identify(dev, ns->ns_id, 0, (dma_addr_t)(long)id)) {
-+		ret = -EIO;
-+		goto free_id;
-+	}
- 
- 	print_formats(id, ns);
- 	print_data_protect_cap(id->dpc, ns->devnum);
- 	print_metadata_cap(id->mc, ns->devnum);
- 
--	return 0;
-+free_id:
-+	free(id);
-+free_ctrl:
-+	free(ctrl);
-+	return ret;
- }
diff --git a/package/boot/uboot-mvebu/patches/013-mmc-xenon_sdhci-remove-wait_dat0-SDHCI-OP.patch b/package/boot/uboot-mvebu/patches/013-mmc-xenon_sdhci-remove-wait_dat0-SDHCI-OP.patch
deleted file mode 100644
index 3277638784..0000000000
--- a/package/boot/uboot-mvebu/patches/013-mmc-xenon_sdhci-remove-wait_dat0-SDHCI-OP.patch
+++ /dev/null
@@ -1,64 +0,0 @@
-From 0f3466f52fbacce67e147b9234e6323edff26a6d Mon Sep 17 00:00:00 2001
-From: Robert Marko <robert.marko@sartura.hr>
-Date: Fri, 11 Mar 2022 19:14:07 +0100
-Subject: [PATCH] mmc: xenon_sdhci: remove wait_dat0 SDHCI OP
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Generic SDHCI driver received support for checking the busy status by
-polling the DAT[0] level instead of waiting for the worst MMC switch time.
-
-Unfortunately, it appears that this does not work for Xenon controllers
-despite being a part of the standard SDHCI registers and the Armada 3720
-datasheet itself telling that BIT(20) is useful for detecting the DAT[0]
-busy signal.
-
-I have tried increasing the timeout value, but I have newer managed to
-catch DAT_LEVEL bits change from 0 at all.
-
-This issue appears to hit most if not all SoC-s supported by Xenon driver,
-at least A3720, A8040 and CN9130 have non working eMMC currently.
-
-So, until a better solution is found drop the wait_dat0 OP for Xenon.
-I was able to only test it on A3720, but it should work for others as well.
-
-Fixes: 40e6f52454fc ("drivers: mmc: Add wait_dat0 support for sdhci driver")
-Signed-off-by: Robert Marko <robert.marko@sartura.hr>
-Reviewed-by: Marek Behún <marek.behun@nic.cz>
-Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
-Reviewed-by: Stefan Roese <sr@denx.de>
----
- drivers/mmc/xenon_sdhci.c | 7 ++++++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
-
---- a/drivers/mmc/xenon_sdhci.c
-+++ b/drivers/mmc/xenon_sdhci.c
-@@ -439,6 +439,8 @@ static const struct sdhci_ops xenon_sdhc
- 	.set_ios_post = xenon_sdhci_set_ios_post
- };
- 
-+static struct dm_mmc_ops xenon_mmc_ops;
-+
- static int xenon_sdhci_probe(struct udevice *dev)
- {
- 	struct xenon_sdhci_plat *plat = dev_get_plat(dev);
-@@ -452,6 +454,9 @@ static int xenon_sdhci_probe(struct udev
- 	host->mmc->dev = dev;
- 	upriv->mmc = host->mmc;
- 
-+	xenon_mmc_ops = sdhci_ops;
-+	xenon_mmc_ops.wait_dat0 = NULL;
-+
- 	/* Set quirks */
- 	host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_32BIT_DMA_ADDR;
- 
-@@ -568,7 +573,7 @@ U_BOOT_DRIVER(xenon_sdhci_drv) = {
- 	.id		= UCLASS_MMC,
- 	.of_match	= xenon_sdhci_ids,
- 	.of_to_plat = xenon_sdhci_of_to_plat,
--	.ops		= &sdhci_ops,
-+	.ops		= &xenon_mmc_ops,
- 	.bind		= xenon_sdhci_bind,
- 	.probe		= xenon_sdhci_probe,
- 	.remove		= xenon_sdhci_remove,
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
deleted file mode 100644
index 4b8706e56f..0000000000
--- a/package/boot/uboot-mvebu/patches/100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch
+++ /dev/null
@@ -1,65 +0,0 @@
-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
deleted file mode 100644
index d7ba3ec68f..0000000000
--- a/package/boot/uboot-mvebu/patches/101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-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
deleted file mode 100644
index 30215aa4e2..0000000000
--- a/package/boot/uboot-mvebu/patches/102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-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