September 2021 - U-Boot

[PATCH] stm32mp: Fix board_get_usable_ram_top()
by Patrice Chotard 06 Sep '21

06 Sep '21

When booting in EFI, lib/efi_loader/efi_memory.c calls board_get_usable_ram_top(0) which returns by default gd->ram_base + gd->ram_size which is the top of DDR. In case of OPTEE boot, the top of DDR is currently reserved by OPTEE, board_get_usable_ram_top(0) must return an address outside OPTEE reserved memory. gd->ram_top matches this constraint as it has already been initialized by substracting all DT reserved-memory (included OPTEE memory area). Fixes: 92b611e8b003 ("stm32mp: correctly handle board_get_usable_ram_top(0)") Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- arch/arm/mach-stm32mp/dram_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-stm32mp/dram_init.c index 94f25f34e0..920b99bb68 100644 --- a/arch/arm/mach-stm32mp/dram_init.c +++ b/arch/arm/mach-stm32mp/dram_init.c @@ -47,7 +47,7 @@ ulong board_get_usable_ram_top(ulong total_size) struct lmb lmb; if (!total_size) - return gd->ram_base + gd->ram_size; + return gd->ram_top; /* found enough not-reserved memory to relocated U-Boot */ lmb_init(&lmb); -- 2.17.1

2 2

[PATCH v2 0/9] arm: dts: ls1028a: sync device tree with linux
by Michael Walle 06 Sep '21

06 Sep '21

This series sync the device tree of the LS1028A SoC with the linux one. To ease future debugging and reviewing, we first clean up the existing one, removing bogus nodes, moving all CCSR related nodes in /soc and update the drivers to accept the offical compatible strings. This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the LS1028A-RDB and -QDS. It would be nice if someone could actually test it on such a board. I didn't sync the device trees for the NXP boards because u-boot related things aren't split into its own -u-boot.dtsi file. So I'll leave that task to NXP :) The following patch is a prerequisite for this series: https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tri… Michael Walle (9): armv8: ls1028a: add IOMMU stream ID to vivante node arm: dts: ls1028a: move devices into /soc arm: dts: ls1028a: remove /memory node arm: dts: ls1028a: update the labels watchdog: sp805_wdt: use correct compatible string spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi serial: lpuart: add new compatible fsl,ls1028a-lpuart arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux arm: dts: sl28: sync dtbs .../arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 1 + .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 24 +- .../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi | 2 +- .../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 31 +- .../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi | 8 + .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46 +- .../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi | 2 +- .../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi | 4 +- .../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 18 +- arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 256 ++- .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 4 +- .../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi | 4 +- .../dts/fsl-ls1028a-qds-7777-sch-30841.dtsi | 12 +- .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 8 +- .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 4 +- .../fsl-ls1028a-qds-9999-sch-24801-LBRW.dtsi | 12 +- .../dts/fsl-ls1028a-qds-9999-sch-24801.dtsi | 12 +- arch/arm/dts/fsl-ls1028a-qds-duart.dts | 2 +- .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 12 +- .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 12 +- .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 6 +- .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 6 +- arch/arm/dts/fsl-ls1028a-qds.dtsi | 17 +- arch/arm/dts/fsl-ls1028a-rdb.dts | 23 +- arch/arm/dts/fsl-ls1028a.dtsi | 1443 ++++++++++++----- arch/arm/dts/hi3660.dtsi | 4 +- drivers/serial/serial_lpuart.c | 2 + drivers/spi/fsl_dspi.c | 1 + drivers/watchdog/sp805_wdt.c | 2 +- .../dt-bindings/clock/fsl,qoriq-clockgen.h | 15 + 30 files changed, 1431 insertions(+), 562 deletions(-) create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h -- 2.30.2

3 28

[PATCH v3 0/3] efi_loader: secure boot using preseed cert db
by Heinrich Schuchardt 06 Sep '21

06 Sep '21

When implementing secure boot the database with the certificates must be stored in tamper-resistant storage. This implies it cannot be read from a file on the EFI system partition. We already have the possibility to provide UEFI variables built into U-Boot via CONFIG_EFI_VAR_SEED_FILE. If TF-A validates BL33 alias U-Boot, this seems adequate for secure boot. With the patch series reading or changing the certificate database is disabled. Furthermore the variable AuditMode and DeployedMode cannot be read from file. The series has been split of [PATCH v2 0/6] efi_loader: fix secure boot mode transitions https://lists.denx.de/pipermail/u-boot/2021-August/459054.html because the implementation of Secure Boot mode transitions need more thought. Heinrich Schuchardt (3): efi_loader: don't load signature database from file efi_loader: efi_auth_var_type for AuditMode, DeployedMode efi_loader: correct determination of secure boot state include/efi_variable.h | 6 ++++- lib/efi_loader/efi_var_common.c | 43 +++++++++++++++++++++++++-------- lib/efi_loader/efi_var_file.c | 41 +++++++++++++++++++------------ lib/efi_loader/efi_variable.c | 6 ++--- 4 files changed, 66 insertions(+), 30 deletions(-) -- 2.32.0

3 5

Massive stm32mp1 breakage with v2021.10-rc2
by Alex G. 06 Sep '21

06 Sep '21

Hi Patrick, I'm having issues with some of the recent changes centered around FIP support and CONFIG_STM32MP15x_STM32IMAGE. and commit f91783edf224 ("arm: stm32mp: handle the OP-TEE nodes in DT with FIP support") ## Problem description > +#ifdef CONFIG_STM32MP15x_STM32IMAGE > + /* only needed for boot with TF-A, witout FIP support */ > firmware { > optee { > compatible = "linaro,optee-tz"; > @@ -33,6 +35,7 @@ > no-map; > }; > }; > +#endif This removes the "optee" and "reserved-memory" nodes. These nodes are required by SPL for setting up TZC memory regions, as introduced in commit 8533263c8512 ("stm32mp1: spl: Configure TrustZone controller for OP-TEE"). ## Further details We now have several boot flows: 1) BL1 -> SPL -> u-boot 2) BL1 -> SPL -> OP-TEE (this path is now broken) 3) BL1 -> TF-A -> u-boot (use case for STM32IMAGE) 4) BL1 -> TF-A -> OP-TEE (use case for STM32IMAGE) 5) BL1 -> TF-A -> FIP container So it seems that STM32IMAGE only makes sense for (3) and (4), but shouldn't affect the others. The fact that OP-TEE is mixed into this is the first red flag. > INPUTS-$(CONFIG_STM32MP15x_STM32IMAGE) += u-boot.stm32 > MKIMAGEFLAGS_u-boot.stm32 = -T stm32image ... This tells me we use _STM32IMAGE just to enable another output image format. The build could give me both u-boot.img, and u-boot.stm32, and I would use the correct file. SO in this case, I would expect _STM32IMAGE to not change the code behavior. This is the second red flag. > $ git grep -c 'ifdef CONFIG_STM32MP15x_STM32IMAGE' > arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c:1 > arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:2 > arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h:1 > arch/arm/mach-stm32mp/include/mach/stm32prog.h:1 We're actually trying to move away from ifdefs, so this intense reliance on _STM32IMAGE raises the third red flag. > board/st/common/stm32mp_mtdparts.c:9 I'm not sure I fully understand why there are so many ifdefs in mtdparts.c. MTD layout seems to me like something that is intended to be devicetree-driven. This is the fourth red flag. Let's take a deeper look at one of those: > stm32mp_mtdparts.c:#ifdef CONFIG_STM32MP15x_STM32IMAGE > stm32mp_mtdparts.c: tee = > stm32prog_get_tee_partitions(); > stm32mp_mtdparts.c-#endif This makes no sense to me. What does OP-TEE presence have to do with the image format of u-boot? If TF-A requires a different layout in FIP vs non-FIP mode, then it's the responsibility of TF-A to supply a corrected devicetree to u-boot. It's not u-boot's role. ## Proposal I propose we remove CONFIG_STM32MP15x_STM32IMAGE. Always build u-boot.stm32, and don't mix it with code behavior. Alex

5 7

[PATCH v3 0/3] riscv: enable SBI system reset
by Heinrich Schuchardt 06 Sep '21

06 Sep '21

The purpose of this series is to provide the UEFI ResetSystem() service at runtime on RISC-V systems. With SBI v0.3 a system reset extension is available. This allows to implement reboot and poweroff in U-Boot in a system independent way. * Provide missing constants * Provide a system reset driver using the system reset extension. * Provide a UEFI runtime implementation for system reset v3: add SBI_HSM_HART_STATUS_SUSPENDED, SBI_HSM_HART_STATUS_SUSPEND_PENDING, SBI_HSM_HART_STATUS_RESUME_PENDING v2: correct constants that were blindly copied from Linux Heinrich Schuchardt (3): riscv: add missing SBI extension definitions cmd/sbi: use constants instead of numerical values sysreset: provide SBI based sysreset driver MAINTAINERS | 1 + arch/riscv/cpu/cpu.c | 13 ++++- arch/riscv/include/asm/sbi.h | 41 +++++++++++++- arch/riscv/lib/sbi.c | 21 ++++++-- cmd/riscv/sbi.c | 30 +++++------ drivers/sysreset/Kconfig | 11 ++++ drivers/sysreset/Makefile | 1 + drivers/sysreset/sysreset_sbi.c | 96 +++++++++++++++++++++++++++++++++ lib/efi_loader/Kconfig | 2 +- 9 files changed, 193 insertions(+), 23 deletions(-) create mode 100644 drivers/sysreset/sysreset_sbi.c -- 2.30.2

2 13

[PATCH] arm: mvebu : sata_mv should probe all ports
by Tony Dinh 06 Sep '21

06 Sep '21

While a board could have multiple SATA ports, some of the ports might not have a disk attached to them. So while probing for disks, sata_mv_probe() should continue probing all ports, and skip one with no disk attached. Tests with: - Seagate Goflex Net (Marvell Kirkwood 88F6281) out-of-tree u-boot. - Zyxel NSA325 (Marvell Kirkwood 88F6282 out-of-tree u-boot. Observation: If a board has 2 or more SATA ports, and there is only one disk attached to one of the ports, sata_mv_probe() does not return a successful probe status. And if only one disk is attached to the 2nd port (i.e. port 1), it is not probed at all. Patch Description: Let sata_mv_probe() continues probing all ports, even if there is error in probing a given port, and then return a successful status if there is at least one port was probed successfully. Signed-off-by: Tony Dinh <mibodhi(a)gmail.com> --- drivers/ata/sata_mv.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index dadb2c7c2e..003222d47b 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -1068,6 +1068,7 @@ static int sata_mv_probe(struct udevice *dev) int nr_ports; int ret; int i; + int status = -ENODEV; /* If the probe fails to detected any SATA port */ /* Get number of ports of this SATA controller */ nr_ports = min(fdtdec_get_int(blob, node, "nr-ports", -1), @@ -1078,7 +1079,7 @@ static int sata_mv_probe(struct udevice *dev) IF_TYPE_SATA, -1, 512, 0, &blk); if (ret) { debug("Can't create device\n"); - return ret; + continue; } priv = dev_get_plat(blk); @@ -1088,18 +1089,23 @@ static int sata_mv_probe(struct udevice *dev) ret = sata_mv_init_sata(blk, i); if (ret) { debug("%s: Failed to init bus\n", __func__); - return ret; + continue; } /* Scan SATA port */ ret = sata_mv_scan_sata(blk, i); if (ret) { debug("%s: Failed to scan bus\n", __func__); - return ret; + continue; } + + /* If we got here, the current SATA port was probed + * successfully, so set the probe status to successful. + */ + status = 0; } - return 0; + return status; } static int sata_mv_scan(struct udevice *dev) -- 2.20.1

2 1

[PATCH v2 0/4] sunxi: TOC0 image type support
by Samuel Holland 06 Sep '21

06 Sep '21

This series adds support for the TOC0 image format used by the Allwinner secure boot ROM (SBROM). This series has been tested on the following SoCs/boards, with the eFuse burnt to enable secure mode: - A50: Ainol Q88 Tablet - A64: Pine A64 Plus - H5: Orange Pi Zero Plus - H6: Pine H64 Model B - H616: Orange Pi Zero 2 Due to a small conflict in Makefile.spl, the last patch depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=249757 Changes in v2: - Refactored the first patch on top of TOOLS_LIBCRYPTO - Moved certificate and key item structures out of sunxi_image.h - Renamed "main" and "item" variables for clarity - Improved error messages, and added a hint about key generation - Added a comment explaining the purpose of the various key files - Mentioned testing this code on A50 in the commit message - Moved SPL header signature checks out of sunxi_image.h - Refactored SPL header signature checks to use fewer casts - Rebase on top of Icenowy's RISC-V support series - Rename Kconfig symbols to include the full image type name Samuel Holland (4): tools: Separate image types which depend on OpenSSL tools: mkimage: Add Allwinner TOC0 support sunxi: Support SPL in both eGON and TOC0 images sunxi: Support building a SPL as a TOC0 image arch/arm/Kconfig | 1 + arch/arm/include/asm/arch-sunxi/spl.h | 2 - arch/arm/mach-imx/mxs/Kconfig | 2 + arch/arm/mach-mvebu/Kconfig | 1 + arch/arm/mach-sunxi/Kconfig | 2 + arch/arm/mach-sunxi/board.c | 50 +- board/sunxi/Kconfig | 24 + common/image.c | 1 + include/image.h | 1 + include/sunxi_image.h | 36 + scripts/Makefile.spl | 5 +- scripts/config_whitelist.txt | 1 - tools/Makefile | 20 +- tools/mxsimage.c | 3 - tools/sunxi_toc0.c | 907 ++++++++++++++++++++++++++ 15 files changed, 1028 insertions(+), 28 deletions(-) create mode 100644 board/sunxi/Kconfig create mode 100644 tools/sunxi_toc0.c -- 2.31.1

3 12

[PATCH v2] Rename CONFIG_SPL_FIT_SHAxxx to CONFIG_SPL_SHAxxx
by Chia-Wei Wang 06 Sep '21

06 Sep '21

Rename these options to align the use in common/image-fit.c else if (CONFIG_IS_ENABLED(SHA1) && strcmp(algo, "sha1") == 0) ... else if (CONFIG_IS_ENABLED(SHA256) && strcmp(algo, "sha256") == 0) ... else if (CONFIG_IS_ENABLED(SHA384) && strcmp(algo, "sha384") == 0) ... else if (CONFIG_IS_ENABLED(SHA512) && strcmp(algo, "sha512") == 0) ... Signed-off-by: Chia-Wei Wang <chiawei_wang(a)aspeedtech.com> --- v2: - fix typo in the commit title common/spl/Kconfig | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c155a3b5fc..c771ae028b 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -439,7 +439,7 @@ config SPL_MD5 applications where images may be changed maliciously, you should consider SHA256 or SHA384. -config SPL_FIT_SHA1 +config SPL_SHA1 bool "Support SHA1" depends on SPL_FIT select SHA1 @@ -451,7 +451,7 @@ config SPL_FIT_SHA1 due to the expanding computing power available to brute-force attacks. For more security, consider SHA256 or SHA384. -config SPL_FIT_SHA256 +config SPL_SHA256 bool "Support SHA256" depends on SPL_FIT select SHA256 @@ -460,7 +460,7 @@ config SPL_FIT_SHA256 checksum is a 256-bit (32-byte) hash value used to check that the image contents have not been corrupted. -config SPL_FIT_SHA384 +config SPL_SHA384 bool "Support SHA384" depends on SPL_FIT select SHA384 @@ -471,7 +471,7 @@ config SPL_FIT_SHA384 image contents have not been corrupted. Use this for the highest security. -config SPL_FIT_SHA512 +config SPL_SHA512 bool "Support SHA512" depends on SPL_FIT select SHA512 -- 2.17.1

1 0

[PATCH] drivers: net: phy: in112525: fix out of bounds write
by Cosmin-Florin Aluchenesei 05 Sep '21

05 Sep '21

Changed declarations of line_temp, reg_addr and reg_data arrays in order to avoid out-of-bounds write which may be caused by the following writing: line_temp[column_cnt] = '\0'; (Increased size from 80 to 81). Signed-off-by: Cosmin-Florin Aluchenesei <aluchenesei.cosmin-florin(a)nxp.com> --- drivers/net/phy/in112525.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/in112525.c b/drivers/net/phy/in112525.c index 2ce1ab1195..e286fa8f14 100644 --- a/drivers/net/phy/in112525.c +++ b/drivers/net/phy/in112525.c @@ -224,9 +224,9 @@ struct phy_device *inphi_phydev; int in112525_upload_firmware(struct phy_device *phydev) { - char line_temp[0x50] = {0}; - char reg_addr[0x50] = {0}; - char reg_data[0x50] = {0}; + char line_temp[0x51] = {0}; + char reg_addr[0x51] = {0}; + char reg_data[0x51] = {0}; int i, line_cnt = 0, column_cnt = 0; struct in112525_reg_config fw_temp; char *addr = NULL; -- 2.21.0

2 1

Subject: [PATCH 0/6] Add support for SDM845 based boards, and SM-G9600
by Дмитрий Санковский 05 Sep '21

05 Sep '21

>From 94e21cc200e09c51752e4bb86cfac320a92c48a5 Mon Sep 17 00:00:00 2001 From: Dzmitry Sankouski <dsankouski(a)gmail.com> Date: Tue, 31 Aug 2021 11:25:37 +0300 Subject: [PATCH 0/6] Add support for SDM845 based boards, and SM-G9600 Snapdragon 845 - hi-end qualcomm chip, introduced in late 2017. Mostly used in flagship phones and tablets of 2018. Features: - arm64 arch - total of 8 Kryo 385 Gold / Silver cores - Hexagon 685 DSP - Adreno 630 GPU Tested only as second-stage bootloader. Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone, for China \ Hong Kong markets. Has unlockable bootloader, unlike SM-G960U (American market version), which allows running u-boot as a chain-loaded bootloader. Dzmitry Sankouski (6): serial: qcom: add support for GENI serial driver spmi: msm: add arbiter version 5 support pinctrl: qcom: add pinctrl and gpio drivers for SDM845 SoC clocks: qcom: add clocks for SDM845 debug uart SoC: qcom: add support for SDM845 board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board MAINTAINERS | 2 + arch/arm/dts/Makefile | 1 + arch/arm/dts/sdm845.dtsi | 118 ++++ arch/arm/dts/starqltechn-uboot.dtsi | 39 ++ arch/arm/dts/starqltechn.dts | 53 ++ arch/arm/mach-snapdragon/Kconfig | 17 + arch/arm/mach-snapdragon/Makefile | 4 + arch/arm/mach-snapdragon/clock-sdm845.c | 92 +++ arch/arm/mach-snapdragon/clock-snapdragon.c | 1 + arch/arm/mach-snapdragon/clock-snapdragon.h | 3 +- .../include/mach/sysmap-sdm845.h | 42 ++ arch/arm/mach-snapdragon/init_sdm845.c | 82 +++ arch/arm/mach-snapdragon/pinctrl-sdm845.c | 44 ++ arch/arm/mach-snapdragon/pinctrl-snapdragon.c | 1 + arch/arm/mach-snapdragon/pinctrl-snapdragon.h | 1 + arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 + board/samsung/starqltechn/Kconfig | 14 + board/samsung/starqltechn/MAINTAINERS | 6 + board/samsung/starqltechn/Makefile | 9 + board/samsung/starqltechn/starqltechn.c | 10 + configs/starqltechn_defconfig | 33 + .../serial/msm-geni-serial.txt | 6 + drivers/gpio/msm_gpio.c | 1 + drivers/gpio/pm8916_gpio.c | 8 +- drivers/serial/Kconfig | 17 + drivers/serial/Makefile | 1 + drivers/serial/serial_msm_geni.c | 579 ++++++++++++++++++ drivers/spmi/spmi-msm.c | 156 +++-- include/configs/sdm845.h | 32 + include/configs/starqltechn.h | 16 + 30 files changed, 1365 insertions(+), 54 deletions(-) create mode 100644 arch/arm/dts/sdm845.dtsi create mode 100644 arch/arm/dts/starqltechn-uboot.dtsi create mode 100644 arch/arm/dts/starqltechn.dts create mode 100644 arch/arm/mach-snapdragon/clock-sdm845.c create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h create mode 100644 arch/arm/mach-snapdragon/init_sdm845.c create mode 100644 arch/arm/mach-snapdragon/pinctrl-sdm845.c create mode 100644 arch/arm/mach-snapdragon/sysmap-sdm845.c create mode 100644 board/samsung/starqltechn/Kconfig create mode 100644 board/samsung/starqltechn/MAINTAINERS create mode 100644 board/samsung/starqltechn/Makefile create mode 100644 board/samsung/starqltechn/starqltechn.c create mode 100644 configs/starqltechn_defconfig create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt create mode 100644 drivers/serial/serial_msm_geni.c create mode 100644 include/configs/sdm845.h create mode 100644 include/configs/starqltechn.h -- 2.20.1

2 1