February 2022 - U-Boot

[PATCH v2] binman: Include also subnodes in generator nodes
by Jan Kiszka 18 Feb '22

18 Feb '22

From: Jan Kiszka <jan.kiszka(a)siemens.com> This allows to prefill fdt and config nodes with hash and signature subnodes. It's just important to place the child nodes last so that hashes do not come before the data - would be disliked by mkimage. Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> --- Changes in v2: - local var renamed - added test case tools/binman/etype/fit.py | 4 ++++ tools/binman/ftest.py | 1 + tools/binman/test/170_fit_fdt.dts | 3 +++ 3 files changed, 8 insertions(+) diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py index a56b0564f9a..981fac7f086 100644 --- a/tools/binman/etype/fit.py +++ b/tools/binman/etype/fit.py @@ -214,6 +214,10 @@ class Entry_fit(Entry_section): if depth == 1 and in_images: fsw.property('data', tools.read_file(fname)) + + for subsubnode in subnode.subnodes: + with fsw.add_node(subsubnode.name): + _AddNode(subnode, depth + 1, subsubnode) else: if self._fdts is None: if self._fit_list_prop: diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py index 59b6d52fbe4..9de78272463 100644 --- a/tools/binman/ftest.py +++ b/tools/binman/ftest.py @@ -3915,6 +3915,7 @@ class TestFunctional(unittest.TestCase): self.assertEqual(expected_data, fnode.props['data'].bytes) self.assertEqual('fdt-test-fdt%d.dtb' % seq, fnode.props['description'].value) + self.assertEqual(fnode.subnodes[0].name, 'hash') def _CheckConfig(seq, expected_data): """Check the configuration nodes diff --git a/tools/binman/test/170_fit_fdt.dts b/tools/binman/test/170_fit_fdt.dts index 99d710c57e9..0197ffd1597 100644 --- a/tools/binman/test/170_fit_fdt.dts +++ b/tools/binman/test/170_fit_fdt.dts @@ -36,6 +36,9 @@ description = "fdt-NAME.dtb"; type = "flat_dt"; compression = "none"; + hash { + algo = "sha256"; + }; }; }; -- 2.34.1

1 0

[PATCH 1/4] imx: imx8mp: detect i.MX8MP UltraLite when get cpu rev
by Peng Fan (OSS) 18 Feb '22

18 Feb '22

From: Peng Fan <peng.fan(a)nxp.com> Detect i.MX8MP UltraLite in get_cpu_variant_type Signed-off-by: Peng Fan <peng.fan(a)nxp.com> --- arch/arm/mach-imx/imx8m/soc.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index da106769b1..e2d21bf6b8 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -407,13 +407,27 @@ static u32 get_cpu_variant_type(u32 type) /* npu disabled*/ if ((value & 0x8) == 0x8) - flag |= (1 << 1); + flag |= BIT(1); /* isp disabled */ if ((value & 0x3) == 0x3) - flag |= (1 << 2); + flag |= BIT(2); + + /* gpu disabled */ + if ((value & 0xc0) == 0xc0) + flag |= BIT(3); + + /* lvds disabled */ + if ((value & 0x180000) == 0x180000) + flag |= BIT(4); + + /* mipi dsi disabled */ + if ((value & 0x60000) == 0x60000) + flag |= BIT(5); switch (flag) { + case 0x3f: + return MXC_CPU_IMX8MPUL; case 7: return MXC_CPU_IMX8MPL; case 2: -- 2.30.0

2 4

[RFC PATCH] mtd: spi-nor-core: Set dummy buswidth equal to data buswidth
by Ashok Reddy Soma 18 Feb '22

18 Feb '22

In current implementation dummy buswidth is set equal to address buswidth. In case of quad spi (mode 1-1-4), where address width is 1 the dummy bytes will be calculated to 1(8 dummy cycles) and dummy buswidth is set to 1. Due to this, the controller driver will introduce 8 dummy cycles on data line(D0) during read operation. But since we are using 4 data lines in case of qspi, we need to change this dummy bus width to 4. This will make dummy bytes to 4 inplace of 1. This will be taken care in controller driver by dividing with dummy buswidth again as in below code, which makes dummy cycles to 8 as earlier. dummy_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth; https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/spi/zynqmp_gqspi… So with this change dummy cycles will be on all data lines(D0-D3) and it is taken care for all the configurations(single, dual, quad and octal). SPI experts, please advice if this change is good. What is the reason we are using dummy bus width as address bus width so far ? I have tested this change on all xilinx platforms with single, quad and octal configurations. It works perfectly fine. I would appreciate if anyone can test on your board and give feedback. Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma(a)xilinx.com> --- drivers/mtd/spi/spi-nor-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index a70fbda4bb..6849da9113 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -251,7 +251,7 @@ static void spi_nor_setup_op(const struct spi_nor *nor, op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto); if (op->dummy.nbytes) - op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto); + op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto); if (op->data.nbytes) op->data.buswidth = spi_nor_get_protocol_data_nbits(proto); -- 2.17.1

1 0

bzImage under x86_64 UEFI app mode.
by Christian Melki 18 Feb '22

18 Feb '22

Hi. I'm trying the new UEFI-app mode where I rely on EFI services to give me access to things like block devices etc. I'm currently using 2022.04-rc1. So far so good. I can start U-boot and the efi block device works just fine. But I'm not succeeding in booting a regular bzImage. This kernel (5.16.4) configuration works on both the physical hardware and an UEFI x86_64 VBox instance using Barebox 2021.08, so kernel configuration should in theory be ok. It's a bzImage with a efistub. I can load a kernel or kernel+initrd baked in, verify the data and use zboot on the loadaddr. zboot does not complain afaics. The kernel however, does not seem to make it very far. Valid Boot Flag Setup Size = 0x00003a00 Magic signature found Using boot protocol version 2.0f Linux kernel version 5.16.4 (ptxdist@ptxdist) #4 SMP PREEMPT 2022-02-01T00:00:00+00:00 Building boot_params at 0x00090000 Loading bzImage at address 100000 (69330784 bytes) Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Setup E820 entries Setup cmdline Kernel command line:console=$(console) rdinit=/sbin/init quiet rw secpboot=factoryimage Kernel command line: "console=tty0 rdinit=/sbin/init quiet rw secpboot=factoryimage" Setup devicetree Kernel loaded at 00100000, setup_base=0000000000090000 Starting kernel ... tsc-timer: When removing: flags=600, drv->flags=0, err=-129 serial: When removing: flags=600, drv->flags=0, err=-129 efi-fb.vidconsole0: When removing: flags=600, drv->flags=0, err=-129 efi-fb: When removing: flags=600, drv->flags=0, err=-129 efi_media.blk: When removing: flags=600, drv->flags=0, err=-129 efi_media_0: When removing: flags=600, drv->flags=0, err=-129 root_driver: When removing: flags=600, drv->flags=0, err=-129 !!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000000 RIP - 000000000010001A, CS - 0000000000000038, RFLAGS - 0000000000010006 RAX - 000000000431E490, RCX - 0000000000000000, RDX - 00000000FFFFFFFB RBX - 0000000000000000, RSP - 00000000000901E8, RBP - 0000000000100000 RSI - 0000000000090000, RDI - 0000000000000000 R8 - 0000000000000020, R9 - 000000000000000A, R10 - 000000000000000D R11 - 0000000000000008, R12 - 0000000000090000, R13 - 00000000DB2372C8 R14 - 00000000D9D0D9D8, R15 - 00000000FFFFFFFF DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 00000000C0010033, CR2 - 0000000000000000, CR3 - 00000000DB001000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 00000000DAFF2018 0000000000000047, LDTR - 0000000000000000 IDTR - 00000000DAC04018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000000008FE40 !!!! Can't find image information. !!!! Hints?

1 0

[PATCH RFC *RFC*] dt-bindings: add U-Boot chosen for environment data phandle
by Rafał Miłecki 17 Feb '22

17 Feb '22

From: Rafał Miłecki <rafal(a)milecki.pl> This is RFC and request for a help & discussion. While reviewing patch for U-Boot env binding it has been mentioned that: 1. /Processing/ whole DT in U-Boot may be too much work Handling flash devices, partitions, their formats & NVMEM may require too many U-Boot drivers involved. 2. It'd be nice to have env data storage devices pointed in chosen I wrote this hacky PATCH to give a rough idea how it could look like. Please review this and let me know: 1. If solution with chosen + phandles is acceptable 2. How to properly name .yaml file 3. Where it put it Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> --- .../devicetree/bindings/u-boot,chosen.yaml | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/u-boot,chosen.yaml diff --git a/Documentation/devicetree/bindings/u-boot,chosen.yaml b/Documentation/devicetree/bindings/u-boot,chosen.yaml new file mode 100644 index 000000000000..8369da91193d --- /dev/null +++ b/Documentation/devicetree/bindings/u-boot,chosen.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/u-boot,chosen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot setup + +maintainers: + - Rafał Miłecki <rafal(a)milecki.pl> + +properties: + u-boot,env: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + A list of storage volumes containing U-Boot environment data. + + Env data can be stored on various kinds of storage devices, e.g.: + 1. Raw flash partition + 2. UBI volume + +additionalProperties: true + +examples: + - | + chosen { + u-boot,env = <&env>; + }; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + env: partition@0 { + reg = <0x0000000 0x1000>; + label = "u-boot-env"; + }; + }; -- 2.34.1

2 1

Please pull u-boot-marvell/master
by Stefan Roese 17 Feb '22

17 Feb '22

Hi Tom, please pull the next batch of mostly Marvell kwboot & MVEBU related fixes and enhancement patches: ---------------------------------------------------------------- - a37xx: pci: Cleanup and minor fix for root port check (Pali) - pci: mvebu: Ensure that root port is always on root zero bus (Pali) - kwbimage: Fix dumping DATA registers for v0 images (Pali) - kwbimage: Support for parsing extended v0 format (Pali) - a37xx: Fix code and update DTS files to upstream version (Pali) - a37xx: Fix and extend building memory map (Pali) - ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision (Marek) - mvebu: Optionally reset board on DDR training failure (Marek) ---------------------------------------------------------------- Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=162&view=results Thanks, Stefan The following changes since commit ab8903a24db11571d634ef255976bb364c3ba64d: configs: Resync with savedefconfig (2022-02-14 22:21:29 +0000) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 4b7db75616712606fd6b61a13df38326e41b3301: arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure (2022-02-17 14:17:07 +0100) ---------------------------------------------------------------- Marek Behún (3): ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision arm: mvebu: spl: Add option to reset the board on DDR training failure arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure Pali Rohár (28): arm: a37xx: pci: Use standard register macros from pci.h arm: a37xx: pci: Cleanup macro names arm: a37xx: pci: Use dev_read_addr() arm: a37xx: pci: Ensure that root port is always on root zero bus tools: kwbimage: Fix dumping DATA registers for v0 images rtc: ds1307: Add bindings for microchip, mcp7940x phy: marvell: a3700: Update compatible string to official DT bindings usb: ehci: ehci-marvell: Update compatible string to official DT bindings watchdog: armada_37xx: Convert to official DT bindings arm: mvebu: turris_mox: Remove hardcoded ethernet node names arm: a37xx: Update sdhci pointers to official DT bindings arm: a37xx: espressobin: Move U-Boot specific partitions node to -u-boot.dtsi arm: a37xx: espressobin: Explicitly enable eMMC node in -u-boot.dtsi arm: a37xx: Update DTS files to version from upstream Linux kernel arm: a37xx: pci: Do not try to access other buses when link is down arm: a37xx: pci: Register controller also when no PCIe card is connected arm: a37xx: pci: Update comment about Command/Direct mode pci: mvebu: Ensure that root port is always on root zero bus arm: mvebu: a37xx: Fix calling build_mem_map() arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space arm: mvebu: a37xx: Fix comment with name of the function tools: kwbimage: Define structures for extended kwbimage v0 headers tools: kwbimage: Fix calculating size of kwbimage v0 header tools: kwbimage: Add support for dumping extended and binary v0 headers tools: kwbimage: Do not show mkimage error message in dumpimage tools: kwbimage: Add support for NAND_BLKSZ and NAND_BADBLK_LOCATION for v0 images tools: kwbimage: Fix help how to extract DDR3 training code tools: kwbimage: Add me as an author of kwbimage arch/arm/dts/armada-371x.dtsi | 38 +- arch/arm/dts/armada-3720-db.dts | 226 +++--- arch/arm/dts/armada-3720-espressobin-u-boot.dtsi | 31 + arch/arm/dts/armada-3720-espressobin.dts | 189 +---- arch/arm/dts/armada-3720-espressobin.dtsi | 218 ++++++ arch/arm/dts/armada-3720-turris-mox.dts | 776 +++++++++++++++++++-- arch/arm/dts/armada-3720-uDPU-u-boot.dtsi | 2 +- arch/arm/dts/armada-3720-uDPU.dts | 218 +++--- arch/arm/dts/armada-372x.dtsi | 43 +- arch/arm/dts/armada-37xx.dtsi | 448 ++++++++---- arch/arm/mach-mvebu/Kconfig | 13 + arch/arm/mach-mvebu/armada3700/cpu.c | 29 +- arch/arm/mach-mvebu/spl.c | 7 +- board/CZ.NIC/turris_mox/turris_mox.c | 22 +- configs/turris_omnia_defconfig | 1 + .../marvell/a38x/ddr3_training_centralization.c | 6 +- drivers/pci/pci-aardvark.c | 544 +++++++-------- drivers/pci/pci_mvebu.c | 52 +- drivers/phy/marvell/comphy_a3700.c | 2 +- drivers/phy/marvell/comphy_core.c | 3 +- drivers/rtc/ds1307.c | 1 + drivers/usb/host/ehci-marvell.c | 4 +- drivers/watchdog/armada-37xx-wdt.c | 7 +- include/dt-bindings/bus/moxtet.h | 16 + include/pci.h | 24 + tools/kwbimage.c | 158 ++++- tools/kwbimage.h | 116 ++- 27 files changed, 2170 insertions(+), 1024 deletions(-) create mode 100644 arch/arm/dts/armada-3720-espressobin-u-boot.dtsi create mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi create mode 100644 include/dt-bindings/bus/moxtet.h

2 1

[PATCH v3 1/1] env: fat: Allow overriding interface, device and partition
by hyyxohk 17 Feb '22

17 Feb '22

For platform which can boot on different device, this allows to override interface, device and partition from board code Signed-off-by: hyyxohk <hyyoxhk(a)163.com> --- env/fat.c | 34 +++++++++++++++++++--------------- include/env_internal.h | 20 ++++++++++++++++++++ 2 files changed, 39 insertions(+), 15 deletions(-) diff --git a/env/fat.c b/env/fat.c index fdccd6cd2a..6251d9649b 100644 --- a/env/fat.c +++ b/env/fat.c @@ -32,7 +32,12 @@ DECLARE_GLOBAL_DATA_PTR; -static char *env_fat_device_and_part(void) +__weak const char *env_fat_get_intf(void) +{ + return (const char *)CONFIG_ENV_FAT_INTERFACE; +} + +__weak char *env_fat_get_dev_part(void) { #ifdef CONFIG_MMC static char *part_str; @@ -60,14 +65,15 @@ static int env_fat_save(void) int dev, part; int err; loff_t size; + const char *ifname = env_fat_get_intf(); + const char *dev_and_part = env_fat_get_dev_part(); err = env_export(&env_new); if (err) return err; - part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE, - env_fat_device_and_part(), - &dev_desc, &info, 1); + part = blk_get_device_part_str(ifname, dev_and_part, + &dev_desc, &info, 1); if (part < 0) return 1; @@ -77,8 +83,7 @@ static int env_fat_save(void) * This printf is embedded in the messages from env_save that * will calling it. The missing \n is intentional. */ - printf("Unable to use %s %d:%d... \n", - CONFIG_ENV_FAT_INTERFACE, dev, part); + printf("Unable to use %s %d:%d...\n", ifname, dev, part); return 1; } @@ -93,8 +98,7 @@ static int env_fat_save(void) * This printf is embedded in the messages from env_save that * will calling it. The missing \n is intentional. */ - printf("Unable to write \"%s\" from %s%d:%d... \n", - file, CONFIG_ENV_FAT_INTERFACE, dev, part); + printf("Unable to write \"%s\" from %s%d:%d...\n", file, ifname, dev, part); return 1; } @@ -117,15 +121,16 @@ static int env_fat_load(void) struct disk_partition info; int dev, part; int err1; + const char *ifname = env_fat_get_intf(); + const char *dev_and_part = env_fat_get_dev_part(); #ifdef CONFIG_MMC - if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc")) + if (!strcmp(ifname, "mmc")) mmc_initialize(NULL); #endif - part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE, - env_fat_device_and_part(), - &dev_desc, &info, 1); + part = blk_get_device_part_str(ifname, dev_and_part, + &dev_desc, &info, 1); if (part < 0) goto err_env_relocate; @@ -135,8 +140,7 @@ static int env_fat_load(void) * This printf is embedded in the messages from env_save that * will calling it. The missing \n is intentional. */ - printf("Unable to use %s %d:%d... \n", - CONFIG_ENV_FAT_INTERFACE, dev, part); + printf("Unable to use %s %d:%d...\n", ifname, dev, part); goto err_env_relocate; } @@ -154,7 +158,7 @@ static int env_fat_load(void) * will calling it. The missing \n is intentional. */ printf("Unable to read \"%s\" from %s%d:%d... \n", - CONFIG_ENV_FAT_FILE, CONFIG_ENV_FAT_INTERFACE, dev, part); + CONFIG_ENV_FAT_FILE, ifname, dev, part); goto err_env_relocate; } diff --git a/include/env_internal.h b/include/env_internal.h index 07c227ecc0..b704c03363 100644 --- a/include/env_internal.h +++ b/include/env_internal.h @@ -245,6 +245,26 @@ const char *env_ext4_get_dev_part(void); * Return: an enum env_location value on success, or -ve error code. */ enum env_location env_get_location(enum env_operation op, int prio); + +/** + * env_fat_get_intf() - Provide the interface for env in FAT + * + * It is a weak function allowing board to overidde the default interface for + * U-Boot env in FAT: CONFIG_ENV_FAT_INTERFACE + * + * Return: string of interface, empty if not supported + */ +const char *env_fat_get_intf(void); + +/** + * env_fat_get_dev_part() - Provide the device and partition for env in FAT + * + * It is a weak function allowing board to overidde the default device and + * partition used for U-Boot env in FAT: CONFIG_ENV_FAT_DEVICE_AND_PART + * + * Return: string of device and partition + */ +char *env_fat_get_dev_part(void); #endif /* DO_DEPS_ONLY */ #endif /* _ENV_INTERNAL_H_ */ -- 2.17.1

3 3

[PATCH u-boot-marvell 0/7] tools: kwbimage: Support for parsing extended v0 format
by Pali Rohár 17 Feb '22

17 Feb '22

This patch series extends kwbimage v0 format support by providing ability to dump content of Dove boot images (extension of v0 format). It also fixes recognition of these images in kwboot utility (as it uses macros and inline functions from kwbimage.h header file). Implementation is based on 88AP510 Functional Specifications, Chapter 5.2 Boot Image Format, which is publicly available at: https://web.archive.org/web/20120130172443/https://www.marvell.com/applicat… Printing information about image.kwb is possible by: $ ./tools/dumpimage -l image.kwb Dumping image.kwb is possible by commands: $ ./tools/dumpimage -T kwbimage -p -1 -o image.cfg image.kwb $ ./tools/dumpimage -T kwbimage -p 0 -o data.bin image.kwb $ ./tools/dumpimage -T kwbimage -p 1 -o binary1.bin image.kwb $ ./tools/dumpimage -T kwbimage -p 2 -o binary2.bin image.kwb ... (where -p N is Nth binary executable header, e.g. SPL) Dove images contains more sections which in config file begins with line "MATCH ADDRESS 0xaddr MASK 0xmask VALUE 0xval" and means that section is executed only when check ((readl(addr) & mask) == (val & mask)) passes. Support for generating these kind of images is not provided. I hope that this patch series helps somebody else to implement it. Pali Rohár (7): tools: kwbimage: Define structures for extended kwbimage v0 headers tools: kwbimage: Fix calculating size of kwbimage v0 header tools: kwbimage: Add support for dumping extended and binary v0 headers tools: kwbimage: Do not show mkimage error message in dumpimage tools: kwbimage: Add support for NAND_BLKSZ and NAND_BADBLK_LOCATION for v0 images tools: kwbimage: Fix help how to extract DDR3 training code tools: kwbimage: Add me as an author of kwbimage tools/kwbimage.c | 139 ++++++++++++++++++++++++++++++++++++++++++----- tools/kwbimage.h | 116 +++++++++++++++++++++++++++++++++++---- 2 files changed, 231 insertions(+), 24 deletions(-) -- 2.20.1

3 27

[PATCH u-boot-marvell v2 1/2] arm: mvebu: spl: Add option to reset the board on DDR training failure
by Marek Behún 17 Feb '22

17 Feb '22

From: Marek Behún <marek.behun(a)nic.cz> 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(a)nic.cz> --- Changes since v1: - dont reset if booting via UART, as suggested by Pali --- 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 273ecb8bd6..5ad323f9d9 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 <fdtdec.h> #include <hang.h> @@ -330,7 +331,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.34.1

3 7

[PATCH u-boot-marvell] ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision
by Marek Behún 17 Feb '22

17 Feb '22

From: Marek Behún <marek.behun(a)nic.cz> 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(a)nic.cz> Tested-by: Chris Packham <judge.packham(a)gmail.com> Reviewed-by: Stefan Roese <sr(a)denx.de> --- drivers/ddr/marvell/a38x/ddr3_training_centralization.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c index 42308b6965..be9f985f22 100644 --- 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 dev_num, u32 mode) [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 dev_num, u32 mode) 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, -- 2.34.1

2 1