September 2021 - U-Boot

[PATCH u-boot-spi v2 0/9] Fix `mtd erase` when used with mtdpart
by Marek Behún 01 Oct '21

01 Oct '21

From: Marek Behún <marek.behun(a)nic.cz> The original cover letter said: this patch series fixes the `mtd erase` command when used with mtdpart with a partition of non-zero offset. Currently when the `mtd erase` command is used for such a partition, it does not erase all blocks. Instead after a block is erased, the next block address not current block address + block size, but current block address + block size + partition offset, due to spi_nor_erase() not calling mtd_erase_callback(): => mtd erase "Rescue system" Erasing 0x00000000 ... 0x006fffff (1792 eraseblock(s)) jedec_spi_nor spi-nor@0: at 0x100000, len 4096 jedec_spi_nor spi-nor@0: at 0x201000, len 4096 jedec_spi_nor spi-nor@0: at 0x302000, len 4096 jedec_spi_nor spi-nor@0: at 0x403000, len 4096 jedec_spi_nor spi-nor@0: at 0x504000, len 4096 jedec_spi_nor spi-nor@0: at 0x605000, len 4096 jedec_spi_nor spi-nor@0: at 0x706000, len 4096 This series adds some fixes to spi_nor_erase() function, then adds calling of mtd_erase_callback() to fix this bug. The series also contains an improvement - adding the posibility to interrupt spi_nor_erase() with Ctrl+C; and another one - making mtdpart's _erase() method more sane so that the above mentioned bug will not occur even if underlying driver does not call mtd_erase_callback(). Finally the last patch removes mtd_erase_callback() entirely, since: - all provided callbacks across U-Boot are no-ops - mtd_erase_callback() is abused for completely different purpose than the original one (as explained in last commit message) Marek Changes since v1: - fixed CI bugs (by removing mtd_erase_callback() entirely) Marek Behún (9): mtd: spi-nor-core: Try cleaning up in case writing BAR failed mtd: spi-nor-core: Check return value of write_enable() in spi_nor_erase() mtd: spi-nor-core: Don't overwrite return value if it is non-zero mtd: spi-nor-core: Check return value of write_disable() in spi_nor_erase() mtd: spi-nor-core: Don't check for zero length in spi_nor_erase() mtd: spi-nor-core: Call mtd_erase_callback() from spi_nor_erase() mtd: spi-nor-core: Check for ctrlc() in spi_nor_erase() mtd: mtdpart: Make mtdpart's _erase method sane mtd: Remove mtd_erase_callback() entirely cmd/onenand.c | 9 ++----- drivers/mtd/altera_qspi.c | 3 --- drivers/mtd/cfi_mtd.c | 1 - drivers/mtd/mtdconcat.c | 11 -------- drivers/mtd/mtdcore.c | 8 ------ drivers/mtd/mtdpart.c | 23 +++++----------- drivers/mtd/nand/raw/nand_base.c | 4 --- drivers/mtd/onenand/onenand_base.c | 3 --- drivers/mtd/spi/sf_mtd.c | 1 - drivers/mtd/spi/spi-nor-core.c | 43 +++++++++++++++++++++++------- drivers/mtd/ubi/io.c | 13 --------- env/onenand.c | 4 +-- fs/yaffs2/yaffs_mtdif.c | 1 - include/linux/mtd/mtd.h | 11 -------- include/nand.h | 1 - 15 files changed, 42 insertions(+), 94 deletions(-) -- 2.32.0

2 14

[BUG] Pinebook Pro won't boot since ac804143cf, regression from -rc1
by Tomasz Bielecki 01 Oct '21

01 Oct '21

Hi all, Starting with: ac804143cf (refs/bisect/bad) mmc: rockchip_sdhci: add phy and clock config for rk3399 Pinebook Pro won't boot. U-boot is installed on the internal MMC, the serial console shows this: U-Boot TPL 2021.10-rc1-00372-gac804143cf-dirty (Sep 06 2021 - 16:32:50) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2021.10-rc1-00372-gac804143cf-dirty (Sep 06 2021 - 16:32:50 -0700) Trying to boot from SPI Trying to boot from MMC2 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### -- Tomasz

2 1

Driver model at UEFI runtime
by Heinrich Schuchardt 01 Oct '21

01 Oct '21

Hello Simon, The EBBR specification requires that the UEFI SystemReset() runtime service is available to the operating system. Up to now this has been implemented by overriding function efi_reset_system() which is marked as __efi_runtime. Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM and the System Reset Extension for SBI on RISC-V. This has kept the number of implementations low. The only exceptions are: * arch/arm/cpu/armv8/fsl-layerscape/cpu.c * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs * arch/sandbox/cpu/start.c Bin has suggested in https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use reset drivers based on the driver model. Currently after ExitBootServices() the driver model does not exist anymore. When evaluating Bin's suggestion one has to keep in mind that after invoking ExitBootServices() most operating systems call SetVirtualAddressMap(). Due to the change of the address map all pointers used by U-Boot afterwards must be updated to match the new memory map. The impression that Ilias and I have is that keeping the driver model alive after SetVirtualAddressMap() would incur: * a high development effort * a significant code size increase * an enlarged attack surface For RISC-V it has been clarified in the platform specification that the SBI must implement the system reset extension. For ARMv8 using TF-A and PSCI is what ARM suggests. So for these architectures we do not expect a growth in the number of drivers needed. Ilias and my favorite would be keeping the design as is. What is your view on this? Best regards Heinrich

7 26

Status of the various RISC-V specification and policy
by Atish Patra 30 Sep '21

30 Sep '21

Hi All, Please find the below email from Stephano about the freeze announcement for various RISC-V specifications that will be part of privilege specification v1.12. All the review discussions are happening in the isa-dev mailing list. The review period will be open for 45 days ending Sunday October 31, 2021. I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions are frozen now. *This will help us merge some patches that have been present in the mailing list for a while. Here are the ratification policy and extension life cycle documents present in the public. If you have any questions regarding this, please check with Mark/Stephano (cc'd). Ratification policy: https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tp… Extension life cycle: https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZP… -- Regards, Atish Mail from Stephano: ---------------------------------------------------------------------------------- Subject: Privileged Specification 1.12 Freeze Milestone: Public Review All, The Privileged Specification version 1.12 has gone to public review. You can view the specification documents by following the links provided here: https://docs.google.com/document/d/1soGI__HytotOkoJtgTYD0nzf82Zhp5nWw1Mcgqv… Review discussion can be followed on the ISA-DEV mailing list here: https://groups.google.com/a/groups.riscv.org/g/isa-dev The review period will be open for 45 days ending Sunday October 31, 2021. We encourage all conversation to happen on this mailing list. Simply reply to the posts linked above with any questions or comments. If you feel that you have a topic that is best discussed internally with RISC-V members only, please contact me directly. Kind Regards, Stephano -- Stephano Cetola Director of Technical Programs RISC-V International ----------------------------------------------------------------------------------------------------

3 11

CI and ca-certificates packages
by Tom Rini 30 Sep '21

30 Sep '21

Hey all, Due to the combination of the Let's Encrypt root certificate change and the CI images not ending up with a new enough ca-certificates package, CI is currently failing. It looks like the best fix for this, sadly, is to rebuild the CI images, so I'll be doing that, uploading to Docker and pushing those changes as soon as I can. -- Tom

1 1

[GIT PULL] xilinx patches for v2022.01-rc1
by Michal Simek 30 Sep '21

30 Sep '21

Hi Tom, I want to clean my queue for next version that's why please merge these patches to your tree. Thanks, Michal The following changes since commit 67ae2897235e516d8fa9ab3f296a1caf40f6ebee: Merge tag 'rpi-next-2021.10.2' of https://source.denx.de/u-boot/custodians/u-boot-raspberrypi (2021-09-29 15:13:35 -0400) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2022.01-rc1 for you to fetch changes up to dced079c53b283e15f04282f405de410a9be584d: watchdog: versal: Add support for expire now (2021-09-30 12:30:38 +0200) ---------------------------------------------------------------- Xilinx changes for v2022.01-rc1 zynq: - Enable capsule update for qspi and mmc - Update zed DT qspi compatible string zynqmp: - Add missing modeboot for EMMC - Add missing nand DT properties - List all eeproms for SC on vck190 - Add vck190 SC psu_init clk: - Handle only GATE type clock for Versal watchdog: - Update versal driver to handle system reset ---------------------------------------------------------------- Amit Kumar Mahapatra (1): arm64: zynqmp: Add device tree properties for nand flash Ashok Reddy Soma (3): xilinx: zynqmp: Set modeboot env variable in eMMC bootmode watchdog: versal: Add support for basic window watchdog watchdog: versal: Add support for expire now Michal Simek (4): ARM: zynq: Enable capsule update for qspi and mmc arm: zynq: Use s25fl256s1 compatible string on zedboard arm64: zynqmp: Define all eeproms for SC on vck190 arm64: zynqmp: Add psu_init_gpl for vck190/vmk180 SC T Karthik Reddy (1): clk: versal: Enable only GATE type clocks arch/arm/dts/zynq-zed.dts | 2 +- arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 15 ++ arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 4 + board/xilinx/zynq/board.c | 35 +++ board/xilinx/zynqmp/zynqmp-e-a2197-00-revA/psu_init_gpl.c | 2052 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ board/xilinx/zynqmp/zynqmp.c | 1 + configs/xilinx_zynq_virt_defconfig | 6 + drivers/clk/clk_versal.c | 5 +- drivers/watchdog/xilinx_wwdt.c | 100 ++++--- 9 files changed, 2182 insertions(+), 38 deletions(-) create mode 100644 board/xilinx/zynqmp/zynqmp-e-a2197-00-revA/psu_init_gpl.c -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

2 1

[PATCH 0/4] White Space cleanup
by Wolfgang Denk 30 Sep '21

30 Sep '21

3 9

[PATCH] fastboot: mmc: Fix dest size in strlcat()
by Ariel D'Alessandro 30 Sep '21

30 Sep '21

strlcat() is truncating the destination string to the size of the source string. Fix size argument in strlcat() to match the size of destination buffer. Bug was introduced in the following commit: commit 69a752983171c2983fc1f29c7cfa1844f41e5d8b Author: Sean Anderson <seanga2(a)gmail.com> fastboot: Fix possible buffer overrun Signed-off-by: Ariel D'Alessandro <ariel.dalessandro(a)collabora.com> --- drivers/fastboot/fb_mmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c index cbb3f7b1dea..4c54f0c3893 100644 --- a/drivers/fastboot/fb_mmc.c +++ b/drivers/fastboot/fb_mmc.c @@ -40,7 +40,7 @@ static int raw_part_get_info_by_name(struct blk_desc *dev_desc, /* check for raw partition descriptor */ strcpy(env_desc_name, "fastboot_raw_partition_"); - strlcat(env_desc_name, name, PART_NAME_LEN); + strlcat(env_desc_name, name, ARRAY_SIZE(env_desc_name)); raw_part_desc = strdup(env_get(env_desc_name)); if (raw_part_desc == NULL) return -ENODEV; @@ -114,7 +114,7 @@ static int part_get_info_by_name_or_alias(struct blk_desc **dev_desc, /* check for alias */ strcpy(env_alias_name, "fastboot_partition_alias_"); - strlcat(env_alias_name, name, PART_NAME_LEN); + strlcat(env_alias_name, name, ARRAY_SIZE(env_alias_name)); aliased_part_name = env_get(env_alias_name); if (aliased_part_name != NULL) ret = do_get_part_info(dev_desc, aliased_part_name, -- 2.30.2

2 2

How to build additional bin with adding dependency via Makefiles
by Michal Simek 30 Sep '21

30 Sep '21

Hi, I am trying to build one configuration blob which should be included in SPL. And still I didn't find the right way how to do it. I need to build C file just as object and run objcopy -O binary. I can be done with host gcc or target gcc. Both of them are little endian that's why it shouldn't be a problem. I just created rules in Makefile OBJCOPYFLAGS := -O binary KBUILD_CFLAGS := -nostdlib -nostartfiles -nodefaultlibs $(obj)/%.bin: $(obj)/%.o FORCE $(call if_changed,objcopy) obj-y += pm_obj.bin binary is generated properly but I have a problem to setup dependency. The same file is referenced via CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE and should be included in pm_cfg_obj.o as the part of SPL. This is the rule (a little bit update compare to version upstream) ifneq ($(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE),"") PM_CFG_OBJ_FILE := $(shell cd $(srctree); readlink -f $(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE)) obj-$(CONFIG_SPL_BUILD) += pm_cfg_obj.o $(obj)/pm_cfg_obj.o: $(PM_CFG_OBJ_FILE) FORCE endif And there is dependency on binary file but I think my issue is that pm_obj.bin is not listed in targets that's why that dependency is not handled properly. Would be good to get some hints how to do it properly. It is PMU fw configuration blob which PMUFW requires to setup proper permission for IPs that I think it would be good to have generic version of this file in u-boot source code that it doesn't need to be created outside of u-boot. At the end there is new option for applying configuration object overlays which will bring new functionality later in boot process that's why generic configuration could work for the most of boards. And if not additional binary could be applied via existing zynqmp pmufw command. Thanks, Michal

1 0

[PATCH] rpi: always set fdt_addr with firmware-provided FDT address
by Mauro Salvini 30 Sep '21

30 Sep '21

Raspberry firmware prepares the FDT blob in memory at an address that depends on both the memory size and the blob size [1]. After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT blob") this FDT is passed to kernel through fdt_addr environment variable, handled in set_fdt_addr() function in board file. When u-boot environment is persistently saved, if a change happens in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT address different from the saved one, but u-boot still use the saved one because set_fdt_addr() function does not overwrite the fdt_addr variable. So, for example, if there is a script that uses fdt commands for e.g. manipulate the bootargs, boot hangs with error libfdt fdt_check_header(): FDT_ERR_BADMAGIC Removing the fdt_addr variable in saved environment allows to boot. With this patch set_fdt_addr() function always overwrite fdt_addr value. [1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018 Signed-off-by: Mauro Salvini <m.salvini(a)koansoftware.com> Cc: Cédric Schieli <cschieli(a)gmail.com> Cc: Matthias Brugger <mbrugger(a)suse.com> --- board/raspberrypi/rpi/rpi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index df52a4689f..611013471e 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -318,9 +318,6 @@ static void set_fdtfile(void) */ static void set_fdt_addr(void) { - if (env_get("fdt_addr")) - return; - if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC) return; -- 2.17.1

3 9