June 2022 - U-Boot

[PATCH] squashfs: Fix compilation on big endian systems
by Pali Rohár 03 Jun '22

03 Jun '22

Signed-off-by: Pali Rohár <pali(a)kernel.org> --- fs/squashfs/sqfs.c | 3 +-- fs/squashfs/sqfs_dir.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c index 5d9c52af80ba..41cb811c1b32 100644 --- a/fs/squashfs/sqfs.c +++ b/fs/squashfs/sqfs.c @@ -11,8 +11,7 @@ #include <errno.h> #include <fs.h> #include <linux/types.h> -#include <linux/byteorder/little_endian.h> -#include <linux/byteorder/generic.h> +#include <asm/byteorder.h> #include <memalign.h> #include <stdlib.h> #include <string.h> diff --git a/fs/squashfs/sqfs_dir.c b/fs/squashfs/sqfs_dir.c index a265b98fe685..ed83c90682ff 100644 --- a/fs/squashfs/sqfs_dir.c +++ b/fs/squashfs/sqfs_dir.c @@ -7,8 +7,7 @@ #include <errno.h> #include <linux/types.h> -#include <linux/byteorder/little_endian.h> -#include <linux/byteorder/generic.h> +#include <asm/byteorder.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> -- 2.20.1

3 9

[PATCH] ubifs: Fix lockup/crash when reading files
by Pali Rohár 03 Jun '22

03 Jun '22

Commit b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the requested size") added optimization to do not read more bytes than it is really needed. But this commit introduced incorrect handling of the hole at the end of file. This logic cause U-Boot to crash or lockup when trying to read from the ubifs filesystem. When read_block() call returns -ENOENT error (not an error, but the hole) then dn-> structure is not filled and contain garbage. So using of dn->size for memcpy() argument cause that U-Boot tries to copy unspecified amount of bytes from possible unmapped memory. Which randomly cause lockup of P2020 CPU. Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer itself and read_block() fills buffer by zeros when it returns -ENOENT. This patch fixes ubifsload on P2020. Fixes: b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the requested size") Signed-off-by: Pali Rohár <pali(a)kernel.org> --- Stefan, could you please look at this patch? Mentioned commit was introduced by you more than 11 years ago. I'm surprised that nobody hit this issue yet, but it looks like older U-Boot versions somehow filled small garbage number into dn->size and did not cause U-Boot lockup/crash. --- fs/ubifs/ubifs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c index d6be5c947d7e..d3026e310168 100644 --- a/fs/ubifs/ubifs.c +++ b/fs/ubifs/ubifs.c @@ -771,40 +771,42 @@ static int do_readpage(struct ubifs_info *c, struct inode *inode, buff = malloc_cache_aligned(UBIFS_BLOCK_SIZE); if (!buff) { printf("%s: Error, malloc fails!\n", __func__); err = -ENOMEM; break; } /* Read block-size into temp buffer */ ret = read_block(inode, buff, block, dn); if (ret) { err = ret; if (err != -ENOENT) { free(buff); break; } } if (last_block_size) dlen = last_block_size; + else if (ret) + dlen = UBIFS_BLOCK_SIZE; else dlen = le32_to_cpu(dn->size); /* Now copy required size back to dest */ memcpy(addr, buff, dlen); free(buff); } else { ret = read_block(inode, addr, block, dn); if (ret) { err = ret; if (err != -ENOENT) break; } } } if (++i >= UBIFS_BLOCKS_PER_PAGE) break; block += 1; addr += UBIFS_BLOCK_SIZE; -- 2.20.1

3 6

[PATCH] board: ti: am64x: Update MAINTAINERS
by Dave Gerlach 03 Jun '22

03 Jun '22

Move maintainership of TI AM64x boards to Vignesh. Signed-off-by: Dave Gerlach <d-gerlach(a)ti.com> --- board/ti/am64x/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/ti/am64x/MAINTAINERS b/board/ti/am64x/MAINTAINERS index eaca2b865f51..78a21d66af73 100644 --- a/board/ti/am64x/MAINTAINERS +++ b/board/ti/am64x/MAINTAINERS @@ -1,5 +1,5 @@ AM64x BOARD -M: Dave Gerlach <d-gerlach(a)ti.com> +M: Vignesh Raghavendra <vigneshr(a)ti.com> M: Tom Rini <trini(a)konsulko.com> S: Maintained F: board/ti/am64x/ -- 2.35.0

2 1

RockPi4B: spl_load_fit_image() writing past end of buffer & MMC errors
by Jerome Forissier 03 Jun '22

03 Jun '22

Hi, I am trying to enable FIT image verification by SPL on Rockchip 4B (U-Boot v2022.04) and I hit a couple of issues. First, I noticed that spl_load_fit_image() may write memory outside the range given in the image node. For example on RockPi 4B I have the following FIT (irrelevant parts omitted): / { images { atf_2 { /* File size is 8024 bytes */ data = /incbin/("bl31_0xff3b0000.bin"); compression = "none"; load = <0xff3b0000> } } } I expect SPL to load atf_2 into 0xff3b0000 - 0xff3b200b but due to the alignment of the source data in the MMC, spl_load_fit_image() writes one more block and later moves the data in place with memcpy(). What are the guarantees that it is a safe thing to do? In my case, the image starts at offset 308 in the 512-byte MMC block (that offset is called 'overhead' in spl_load_fit_image()). As a result, (8204 + 308) / 512 + 1 = 17 blocks = 8704 bytes are read. For some reason I can't explain, on my board only the first 8K of the 64K SRAM range 0xff3b0000 - 0xff3c0000 (INTMEM1) can be safely written to. Any data written after this point corrupt the lower 8K. I found nothing in the rk3399 TRM about this [1]. Anyways, I tried using a temporary buffer allocated on the heap to handle the first and last blocks at least (the load address is properly aligned for info->read() so the middle blocks can be read in one go). It works but not reliably. And that is the second problem. mmc_read_blocks() in mmc_bread() sometimes returns an error. If I read blocks one by one in a loop THE read randomly fails after a few blocks only. The error is -110 (-ETIMEDOUT) from dwmci_send_cmd(). Am I using the MMC read incorrectly? [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf Thanks, -- Jerome

2 3

[PATCH v1 1/9] ARM: hpe: gxp: add core support
by nick.hawkins＠hpe.com 03 Jun '22

03 Jun '22

From: Nick Hawkins <nick.hawkins(a)hpe.com> The GXP is the HPE BMC SoC that is used in the majority of current generation HPE servers. Traditionally the asic will last multiple generations of server before being replaced. Info about SoC: HPE GXP is the name of the HPE Soc. This SoC is used to implement many BMC features at HPE. It supports ARMv7 architecture based on the Cortex A9 core. It is capable of using an AXI bus to whicha memory controller is attached. It has multiple SPI interfaces to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC for network connectivity. It has multiple i2c engines to drive connectivity with a host infrastructure. There currently are no public specifications but this process is being worked. Signed-off-by: Nick Hawkins <nick.hawkins(a)hpe.com> --- arch/arm/Kconfig | 8 ++++++++ arch/arm/Makefile | 1 + arch/arm/mach-hpe/Makefile | 1 + arch/arm/mach-hpe/gxp/Kconfig | 9 +++++++++ arch/arm/mach-hpe/gxp/Makefile | 1 + arch/arm/mach-hpe/gxp/reset.c | 26 ++++++++++++++++++++++++++ 6 files changed, 46 insertions(+) create mode 100644 arch/arm/mach-hpe/Makefile create mode 100644 arch/arm/mach-hpe/gxp/Kconfig create mode 100644 arch/arm/mach-hpe/gxp/Makefile create mode 100644 arch/arm/mach-hpe/gxp/reset.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9898c7d68e..1f9fc1bb8e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2085,6 +2085,12 @@ config TARGET_XENGUEST_ARM64 select SSCANF imply OF_HAS_PRIOR_STAGE +config ARCH_GXP + bool "Support HPE GXP SoCs" + select DM + select OF_CONTROL + imply CMD_DM + endchoice config SUPPORT_PASSING_ATAGS @@ -2193,6 +2199,8 @@ source "arch/arm/mach-davinci/Kconfig" source "arch/arm/mach-exynos/Kconfig" +source "arch/arm/mach-hpe/gxp/Kconfig" + source "arch/arm/mach-highbank/Kconfig" source "arch/arm/mach-integrator/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 85c23bcf77..cfaa38594c 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -62,6 +62,7 @@ machine-$(CONFIG_ARCH_BCM283X) += bcm283x machine-$(CONFIG_ARCH_BCMSTB) += bcmstb machine-$(CONFIG_ARCH_DAVINCI) += davinci machine-$(CONFIG_ARCH_EXYNOS) += exynos +machine-$(CONFIG_ARCH_GXP) += hpe machine-$(CONFIG_ARCH_HIGHBANK) += highbank machine-$(CONFIG_ARCH_IPQ40XX) += ipq40xx machine-$(CONFIG_ARCH_K3) += k3 diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile new file mode 100644 index 0000000000..afe5f7a29e --- /dev/null +++ b/arch/arm/mach-hpe/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SOC_GXP) += gxp/ diff --git a/arch/arm/mach-hpe/gxp/Kconfig b/arch/arm/mach-hpe/gxp/Kconfig new file mode 100644 index 0000000000..2d43133ab0 --- /dev/null +++ b/arch/arm/mach-hpe/gxp/Kconfig @@ -0,0 +1,9 @@ +if ARCH_GXP + +config SOC_GXP + bool + select CPU_V7A + +source "board/hpe/gxp/Kconfig" + +endif diff --git a/arch/arm/mach-hpe/gxp/Makefile b/arch/arm/mach-hpe/gxp/Makefile new file mode 100644 index 0000000000..f3cc6684b8 --- /dev/null +++ b/arch/arm/mach-hpe/gxp/Makefile @@ -0,0 +1 @@ +obj-y += reset.o diff --git a/arch/arm/mach-hpe/gxp/reset.c b/arch/arm/mach-hpe/gxp/reset.c new file mode 100644 index 0000000000..4d4d5f015f --- /dev/null +++ b/arch/arm/mach-hpe/gxp/reset.c @@ -0,0 +1,26 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * GXP driver + * + * (C) Copyright 2022 Hewlett Packard Enterprise Development LP. + * Author: Nick Hawkins <nick.hawkins(a)hpe.com> + * Author: Jean-Marie Verdun <verdun(a)hpe.com> + */ + +#include <common.h> +#include <asm/io.h> + +#define GXP_CCR 0xc0000000 + +/* empty to satisfy current lowlevel_init, can be removed any time */ +void lowlevel_init(void) +{ +} + +void reset_cpu(ulong ignored) +{ + writel(1, GXP_CCR); + + while (1) + ; /* loop forever till reset */ +} -- 2.17.1

3 20

[PATCH] boot: pxe_utils: Do not use fdtcontroladdr for FIT Image format
by Neil Armstrong 03 Jun '22

03 Jun '22

When patch [1] introduced "fdtcontroladdr" fallback in order to use built-in DT when no DT in provided in PXE config, it broke FIT image boot where the DT from the FIT configuration was used. This disables the "fdtcontroladdr" fallback when the provided image is from the FIT image type. [1] d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") Fixes: d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") Cc: Tom Rini <trini(a)konsulko.com> Cc: Peter Hoyes <peter.hoyes(a)arm.com> Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- boot/pxe_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index b08aee9896..5eb328c86b 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -725,7 +725,7 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) if (!bootm_argv[3]) bootm_argv[3] = env_get("fdt_addr"); - if (!bootm_argv[3]) + if (genimg_get_format(buf) != IMAGE_FORMAT_FIT && !bootm_argv[3]) bootm_argv[3] = env_get("fdtcontroladdr"); if (bootm_argv[3]) { -- 2.25.1

2 1

[PATCH] xilinx: zynqmp: Do not use null as spl bss start address
by Stefan Herbrechtsmeier 03 Jun '22

03 Jun '22

From: Stefan Herbrechtsmeier <stefan.herbrechtsmeier(a)weidmueller.com> Do not use null as address for memory because of the special meaning for pointers. Change the spl bss start address to the second page. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier(a)weidmueller.com> --- The problem was discovered with a static char array initialized with an empty string. include/configs/xilinx_zynqmp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index f25d796a1e..21a5cf1617 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -209,7 +209,7 @@ #define CONFIG_SPL_MAX_SIZE 0x40000 /* Just random location in OCM */ -#define CONFIG_SPL_BSS_START_ADDR 0x0 +#define CONFIG_SPL_BSS_START_ADDR 0x1000 #define CONFIG_SPL_BSS_MAX_SIZE 0x80000 #if defined(CONFIG_SPL_SPI_FLASH_SUPPORT) -- 2.30.2

2 6

[PATCH RFC v2 00/11] Integration of sysfw, tispl and tiboot3
by Neha Malcom Francis 03 Jun '22

03 Jun '22

Devices that belong to the K3 architecture require SYSFW which is a FIT image consisting of a signed system firmware image and board config binaries. Board config binaries are needed to bring up SYSFW during U-Boot SPL startup. The board config data is given in YAML as input. These board configs contain board-specific information such as resource management, power management and security. The following series intends to plumb the system firmware generation into U-Boot using binman for packaging. Thus it will eliminate the need for additional custom repositories for SYSFW generation and also moves t owards the community standard build flow. We use binman to package tiboot3.bin and sysfw.itb images. These images also require x509 certificates which are created using the etype x509-cert. The series also plumbs the generation of tispl.bin into the build flow. This image is required for loading u-boot in K3 devices. The image is packaged using ATF, OPTEE and DM (Device Manager). Please note that the following series has implemented the above for J721E general purpose board. The board configs and device trees added are specific to J721E GP devices. Also note the introduction of three new etypes: ti-sysfw, ti-dm and x509-cert. On running CI tests on Github, errors were produced during world builds of keystone2_keystone3 and siemens (I0T2050 which is based on AM65x). This patch series is intended for only J721E and future work is to expand to the remaining K3 devices as well. The errors that come are mainly due to the boards other than J721E trying to generate tispl.bin. v2: - Added etype x509-cert for creating x509 Texas Instruments certificate binary - Added packaging of tiboot3.bin - Packaging of tiboot3.bin and sysfw.itb using new etype x509 - sysfw --> ti-sysfw - Reformatted and re-arranged patches - Removed k3_fit_atf.sh and k3_gen_x509_cert.sh as their functionality is provided by binman now Neha Malcom Francis (11): j721e_evm: schema: yaml: Add general schema and J721E board config files ti: tools: config: Add board config class to generate config binaries ti: etype: sysfw: Add entry type for sysfw ti: etype: dm: Add entry type for TI DM ti: etype: x509: Add etype for x509 certificate for K3 devices ti: sysfw: Add support for packaging sysfw.itb ti: tiboot3.bin: Remove tiboot3.bin target from makefile ti: tispl.bin: Removed script that packages tispl.bin ti: x509: Remove shell script used for signing ti: dtsi: j721e: Use binman to package sysfw.itb and tiboot3.bin ti: dtsi: j721e: Use binman to package tispl.bin Makefile | 2 + arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 + .../k3-j721e-common-proc-board-u-boot.dtsi | 1 + arch/arm/dts/k3-j721e-r5-binman.dtsi | 88 + .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 1 + arch/arm/mach-k3/config.mk | 64 +- board/ti/common/schema.yaml | 355 ++ board/ti/j721e/Kconfig | 2 + board/ti/j721e/config.yaml | 3162 +++++++++++++++++ scripts/Makefile.spl | 4 - test/py/requirements.txt | 1 + tools/binman/entries.rst | 36 + tools/binman/etype/ti_dm.py | 23 + tools/binman/etype/ti_sysfw.py | 28 + tools/binman/etype/x509_cert.py | 248 ++ tools/binman/ftest.py | 21 + tools/binman/test/225_ti_dm.dts | 13 + tools/binman/test/232_ti_sysfw.dts | 13 + tools/binman/test/232_x509_cert.dts | 18 + tools/k3_fit_atf.sh | 123 - tools/k3_gen_x509_cert.sh | 252 -- tools/tibcfg_gen.py | 114 + 22 files changed, 4227 insertions(+), 428 deletions(-) create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi create mode 100644 arch/arm/dts/k3-j721e-r5-binman.dtsi create mode 100644 board/ti/common/schema.yaml create mode 100644 board/ti/j721e/config.yaml create mode 100644 tools/binman/etype/ti_dm.py create mode 100644 tools/binman/etype/ti_sysfw.py create mode 100644 tools/binman/etype/x509_cert.py create mode 100644 tools/binman/test/225_ti_dm.dts create mode 100644 tools/binman/test/232_ti_sysfw.dts create mode 100644 tools/binman/test/232_x509_cert.dts delete mode 100755 tools/k3_fit_atf.sh delete mode 100755 tools/k3_gen_x509_cert.sh create mode 100644 tools/tibcfg_gen.py -- 2.17.1

5 35

[PATCH 00/22] microblaze: Add support for full relocation
by Michal Simek 02 Jun '22

02 Jun '22

Hi, this series is adding support for full rela relocation. Origin NEEDS_MANUAL_RELOC option is still there as default. Code has been tested with multiple configurations on QEMU. - Origin behavior - u-boot - Relocated version - u-boot.elf - Loading u-boot.bin to higher address than TEXT_BASE - Loading u-boot.bin to lower address than TEXT_BASE There is still one more issue with Kconfig and conflict with MIPS but I want to send it out to be available for review. Thanks, Michal Michal Simek (22): tools: relocate-rela: Open binary u-boot file later Makefile: Fix description for relocate-rela parameters tools: relocate-rela: Use global variables tools: relocate-rela: Read rela start/end directly from ELF microblaze: Switch absolute branches to relative microblaze: Fix stack protection behavior microblaze: Fix early stack allocation microblaze: Remove CONFIG_TEXT_BASE from code microblaze: Fix typo in exception.c microblaze: Enable REMAKE_ELF microblaze: Separate code end substraction microblaze: Change stack protection address to new stack address microblaze: Optimize register usage in relocate_code microblaze: Remove code around r20 in relocate_code() microblaze: Remove _start symbol handling at U-Boot start microblaze: Add comment about reset location microblaze: Create SYM_ADDR macro to deal with symbols tools: relocate-rela: Extract elf64 reloc to special function tools: relocate-rela: Check that relocation works only for EM_AARCH64 tools: relocate-rela: Add support for elf32 decoding tools: relocate-rela: Add support for 32bit Microblaze relocation microblaze: Add support for run time relocation Makefile | 6 +- arch/Kconfig | 1 - arch/microblaze/Kconfig | 30 ++ arch/microblaze/config.mk | 11 + arch/microblaze/cpu/Makefile | 1 + arch/microblaze/cpu/exception.c | 2 +- arch/microblaze/cpu/relocate.c | 111 ++++++ arch/microblaze/cpu/start.S | 130 +++++-- arch/microblaze/cpu/u-boot.lds | 14 + common/board_f.c | 2 + configs/microblaze-generic_defconfig | 1 + include/configs/microblaze-generic.h | 4 - tools/relocate-rela.c | 545 +++++++++++++++++++++++++-- 13 files changed, 780 insertions(+), 78 deletions(-) create mode 100644 arch/microblaze/cpu/relocate.c -- 2.36.0

1 22

[PATCH 0/3] arm: rockchip: rk3399: rock-pi-4: power domain driver to boot from MMCSD
by Xavier Drudis Ferran 02 Jun '22

02 Jun '22

Hello. I've been trying to compile myself all the stack to boot a Radxa Rock Pi 4B. I've found and worked around a few issues and I'm starting to select, clean up and send the patches I used. Since I'm new to the project I may have overseen something obvious. If so sorry. For the rest I hope something can be useful to others. Likewise I've found a couple of suspicions lines in clk_rk3399.c, but since I haven't found cases where they give problems, I should not send changes, or should I? This series is the minimum I needed to be able to boot linux-libre from a SD card, which wasn't possible for me just from master. It still displays some errors, but I leave them for later because it boots. The series is basically about trying not to overlap ATF, enabling a couple of clocks that MMCSD uses, and adding a power domain driver for rockchip, since I guess the DTS must have been updated from linux and the board may have worked before but the new DTS maybe broke boot from SD. I'm not sure why power domain drivers in U-Boot leave the clocks they need enabled, but I tried to disable them once powered up and it didn't boot. If people wants to test with other rockchip SOCs that'd be welcome, but I'm not sure whether they need the new driver. For now I only configured it for Rock Pi 4. Thanks beforehand for any feedback. Specially if I should run any tests. -- Xavier Drudis Ferran

1 3