Skip to content
Snippets Groups Projects
Verified Commit 5fb28450 authored by Josef Schlehofer's avatar Josef Schlehofer
Browse files

omnia-uboot: update to version 2022.04 

Remove all backported patches, which are part of this release.
parent 0c059573
1 merge request!982Turris OS 6.0 (HBK) (turrispackages)
Hide whitespace changes
Inline Side-by-side
Showing
with 4 additions and 632 deletions
hardware/omnia/omnia-uboot/Makefile
+ 4
− 4
View file @ 5fb28450
......@@ -8,13 +8,13 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=omnia-uboot
PKG_VERSION:=2022.01
PKG_RELEASE:=7
PKG_VERSION:=2022.04
PKG_RELEASE:=1
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=https://source.denx.de/u-boot/u-boot.git
PKG_MIRROR_HASH:=14816a081d20b353253b053f271eaef2309c599975c18f4720f8dfea5a4b4986
PKG_SOURCE_DATE:=2022-01-10
PKG_MIRROR_HASH:=5a1ca6d5056822b7d1fd9c84ef65f5456278f5ac2eef74025fce66e056301fa8
PKG_SOURCE_DATE:=2022-04-04
PKG_SOURCE_VERSION:=v$(PKG_VERSION)
PKG_MAINTAINER:=CZ.NIC <packaging@turris.cz>
......
hardware/omnia/omnia-uboot/patches/010-ddr-marvell-a38x-fix-split-out-mix.patch deleted 100644 → 0
+ 0
− 121
View file @ 0c059573
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(+)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
index 648b37ef6f..42308b6965 100644
--- 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 dev_num, u32 mode)
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 dev_num, u32 mode)
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 dev_num, u32 mode)
[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] -
--
GitLab
hardware/omnia/omnia-uboot/patches/011-ddr-marvell-a38x-fix-synchronous-asynchronous-mode.patch deleted 100644 → 0
+ 0
− 103
View file @ 0c059573
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(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index faafc86ea2..7c7bce73a3 100644
--- 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_40_mhz[] = {
};
-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 dev_num, u32 if_id,
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 dev_num, u32 if_id,
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 if_id, u32 reg_addr,
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;
}
--
GitLab
hardware/omnia/omnia-uboot/patches/012-nvme-Do-not-allocate-8kB-buffer-on-stack.patch deleted 100644 → 0
+ 0
− 180
View file @ 0c059573
From patchwork Thu Dec 9 10:06:39 2021
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= <pali@kernel.org>
X-Patchwork-Id: 1565708
X-Patchwork-Delegate: trini@ti.com
Return-Path: <u-boot-bounces@lists.denx.de>
X-Original-To: incoming@patchwork.ozlabs.org
Delivered-To: patchwork-incoming@bilbo.ozlabs.org
Authentication-Results: bilbo.ozlabs.org;
dkim=pass (2048-bit key;
unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256
header.s=k20201202 header.b=owBTw6Y0;
dkim-atps=neutral
Authentication-Results: ozlabs.org;
spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de
(client-ip=85.214.62.61; helo=phobos.denx.de;
envelope-from=u-boot-bounces@lists.denx.de; receiver=<UNKNOWN>)
Received: from phobos.denx.de (phobos.denx.de [85.214.62.61])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits))
(No client certificate requested)
by bilbo.ozlabs.org (Postfix) with ESMTPS id 4J8qTM708Zz9s1l
for <incoming@patchwork.ozlabs.org>; Thu, 9 Dec 2021 21:07:19 +1100 (AEDT)
Received: from h2850616.stratoserver.net (localhost [IPv6:::1])
by phobos.denx.de (Postfix) with ESMTP id 3FB4F80F68;
Thu, 9 Dec 2021 11:07:13 +0100 (CET)
Authentication-Results: phobos.denx.de;
dmarc=pass (p=none dis=none) header.from=kernel.org
Authentication-Results: phobos.denx.de;
spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de
Authentication-Results: phobos.denx.de;
dkim=pass (2048-bit key;
unprotected) header.d=kernel.org header.i=@kernel.org header.b="owBTw6Y0";
dkim-atps=neutral
Received: by phobos.denx.de (Postfix, from userid 109)
id 322AF804C8; Thu, 9 Dec 2021 11:07:11 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de
X-Spam-Level:
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,
SPF_PASS autolearn=ham autolearn_force=no version=3.4.2
Received: from sin.source.kernel.org (sin.source.kernel.org
[IPv6:2604:1380:40e1:4800::1])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by phobos.denx.de (Postfix) with ESMTPS id 0C66F8141A
for <u-boot@lists.denx.de>; Thu, 9 Dec 2021 11:07:06 +0100 (CET)
Authentication-Results: phobos.denx.de;
dmarc=pass (p=none dis=none) header.from=kernel.org
Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sin.source.kernel.org (Postfix) with ESMTPS id F3CBCCE2558;
Thu, 9 Dec 2021 10:07:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08E4FC004DD;
Thu, 9 Dec 2021 10:07:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1639044421;
bh=I+fGxic7rMpZ1Zi/AiSsyXnETuTbDPyFD0r2i9AvE1U=;
h=From:To:Cc:Subject:Date:From;
b=owBTw6Y0CrNu6IANkBdCI137prowS2jox7v683lpE8Jl/tYuBGelQiAp3RFcDL93T
AZP4oj+NqytlNGcX5PVl0PYgxu2U+CvxSfQDlFftiOs14sQh0sktMZOskimGdNgPql
AjYkDRtwUwBqqyNmfECvNg1uQLppkjkwX3TFQ+9RQD4F56BR+kV0bykG42/+72RSjj
hMUYNhrC0yyCtHmUcg2X1LMMVHj90bCuk543sT3vHxMjsMxbZJofMVfb9EDmXtAwBW
EdNTDZxY7B2YDuKcl52hClMQF6JfqisZR5TPZtgReBdxJv1eQLLYl4+b4Z+s4Z+/bv
ViR8ipON4V6rA==
Received: by pali.im (Postfix)
id 2F6E3111E; Thu, 9 Dec 2021 11:06:58 +0100 (CET)
From: =?utf-8?q?Pali_Roh=C3=A1r?= <pali@kernel.org>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: =?utf-8?q?Marek_Beh=C3=BAn?= <marek.behun@nic.cz>,
Patrick Wildt <patrick@blueri.se>, u-boot@lists.denx.de
Subject: [PATCH] nvme: Do not allocate 8kB buffer on stack
Date: Thu, 9 Dec 2021 11:06:39 +0100
Message-Id: <20211209100639.21530-1-pali@kernel.org>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
X-BeenThere: u-boot@lists.denx.de
X-Mailman-Version: 2.1.38
Precedence: list
List-Id: U-Boot discussion <u-boot.lists.denx.de>
List-Unsubscribe: <https://lists.denx.de/options/u-boot>,
<mailto:u-boot-request@lists.denx.de?subject=unsubscribe>
List-Archive: <https://lists.denx.de/pipermail/u-boot/>
List-Post: <mailto:u-boot@lists.denx.de>
List-Help: <mailto:u-boot-request@lists.denx.de?subject=help>
List-Subscribe: <https://lists.denx.de/listinfo/u-boot>,
<mailto:u-boot-request@lists.denx.de?subject=subscribe>
Errors-To: u-boot-bounces@lists.denx.de
Sender: "U-Boot" <u-boot-bounces@lists.denx.de>
X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de
X-Virus-Status: Clean
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;
}
hardware/omnia/omnia-uboot/patches/100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch deleted 100644 → 0
+ 0
− 65
View file @ 0c059573
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/4] 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,
hardware/omnia/omnia-uboot/patches/101-arm-mvebu-Use-printf-for-printing-fatal-errors.patch deleted 100644 → 0
+ 0
− 42
View file @ 0c059573
From 8b78484d1c914489b68cbb9eb423df8845cb48e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
Date: Fri, 17 Dec 2021 18:31:14 +0100
Subject: [PATCH 2/4] arm: mvebu: Use printf for printing fatal errors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
There is no point to hide/disable fatal errors via debug() macro.
Print fatal errors loudly.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
---
arch/arm/mach-mvebu/spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 73c4b9af3e..216b9765ef 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -273,7 +273,7 @@ void board_init_f(ulong dummy)
ret = spl_init();
if (ret) {
- debug("spl_init() failed: %d\n", ret);
+ printf("spl_init() failed: %d\n", ret);
hang();
}
@@ -289,7 +289,7 @@ void board_init_f(ulong dummy)
/* Setup DDR */
ret = ddr3_init();
if (ret) {
- debug("ddr3_init() failed: %d\n", ret);
+ printf("ddr3_init() failed: %d\n", ret);
hang();
}
#endif
--
2.35.1
hardware/omnia/omnia-uboot/patches/102-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch deleted 100644 → 0
+ 0
− 79
View file @ 0c059573
From 7bb7f788743f4951b4d4c795f125b82132dd3205 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 3/4] 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/Kconfig | 13 +++++++++++++
arch/arm/mach-mvebu/spl.c | 7 ++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d23cc0c760..7d487f270b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -213,6 +213,19 @@ config DDR_LOG_LEVEL
At level 3, rovides the windows margin of each DQ as a results of
DQS centeralization.
+config DDR_RESET_ON_TRAINING_FAILURE
+ bool "Reset the board on DDR training failure instead of hanging"
+ depends on ARMADA_38X || ARMADA_XP
+ help
+ If DDR training fails in SPL, reset the board instead of hanging.
+ Some boards are known to fail DDR training occasionally and an
+ immediate reset may be preferable to waiting until the board is
+ reset by watchdog (if there even is one).
+
+ Note that if booting via UART and the DDR training fails, the
+ device will still hang - it doesn't make sense to reset the board
+ in such a case.
+
config SYS_BOARD
default "clearfog" if TARGET_CLEARFOG
default "helios4" if TARGET_HELIOS4
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 216b9765ef..479ee5d49e 100644
--- 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) {
printf("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
--
2.35.1
hardware/omnia/omnia-uboot/patches/103-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch deleted 100644 → 0
+ 0
− 38
View file @ 0c059573
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 4/4] 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
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment