diff options
Diffstat (limited to 'package/boot')
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 |