November 2023 - U-Boot

[PATCH v2 0/2] Disable setting ICACHE and DCACHE off for ARM64 platforms
by Bhupesh Sharma 10 Nov '23

10 Nov '23

As suggested by Tom, disable setting ICACHE and DCACHE off for ARM64 platforms. It is also noticed that with CACHEs off u-boot on ARM64 (ARMv8) boots slower. If some platforms still wish to turn off ICACHE / DCACHE during the SPL stage, support that configuration as well. While at it, also fix an compilation issue for stm32mp when SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled. Cc: Patrice Chotard <patrice.chotard(a)foss.st.com> Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Cc: Tom Rini <trini(a)konsulko.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Peng Fan <peng.fan(a)nxp.com> Bhupesh Sharma (2): arm: stm32mp: Really fix compilation issue when SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled armv8: Disable SYS_DCACHE_OFF & SYS_ICACHE_OFF for ARM64 arch/arm/Kconfig | 2 ++ arch/arm/cpu/armv8/Makefile | 4 ++-- arch/arm/mach-stm32mp/cpu.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) -- 2.38.1

5 10

[RFC PATCH 1/1] arm: mach-k3: Enable icache on am625 to boot faster
by Joao Paulo Goncalves 10 Nov '23

10 Nov '23

Enable the am625 instruction cache on SPL and U-boot earlier for the A53 to execute code a bit faster. For normal boot flow, it was possible to gain about 2 seconds on boot time. Signed-off-by: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> --- Hello all, We are trying to optimize boot time on our AM62 devices and on TI community forum [1] someone advised to enable ICACHE for am625. We enabled it, tested and got around 2 seconds faster boot on storage media and about 5 seconds with DFU for downloading images from A53 SPL. However, we don't know if this is the correct solution and want more comments on this or why the ICACHE was not enabled by TI in the first place. [1] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1… Regards, Joao Paulo Goncalves arch/arm/mach-k3/am625_init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c index 8fa36f7b91..d665d07b0b 100644 --- a/arch/arm/mach-k3/am625_init.c +++ b/arch/arm/mach-k3/am625_init.c @@ -210,6 +210,9 @@ void board_init_f(ulong dummy) panic("DRAM init failed: %d\n", ret); } spl_enable_dcache(); + + if (!IS_ENABLED(CONFIG_CPU_V7R) && !IS_ENABLED(CONFIG_SYS_ICACHE_OFF)) + icache_enable(); } u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device) -- 2.34.1

5 5

[PATCH] doc: typo 'form' in qfw.rst
by Heinrich Schuchardt 10 Nov '23

10 Nov '23

%s/form/from/ Fixes: d46bee8c2d24 ("doc: qfw man-page") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- doc/usage/cmd/qfw.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/cmd/qfw.rst b/doc/usage/cmd/qfw.rst index ec13e0967a..e734b26671 100644 --- a/doc/usage/cmd/qfw.rst +++ b/doc/usage/cmd/qfw.rst @@ -15,7 +15,7 @@ Synopsis Description ----------- -The *qfw* command is used to retrieve information form the QEMU firmware. +The *qfw* command is used to retrieve information from the QEMU firmware. The *qfw list* sub-command displays the QEMU firmware files. -- 2.40.1

2 1

[PATCH] pci: ecm generic: use dev_read_() interface
by Mayuresh Chitale 10 Nov '23

10 Nov '23

Use dev_read_() api instead of the fdtdec API to fetch the host controller's reg property value. This is similar to the other host controller drivers such as Sifive, Rockchip etc. Without this change, enabling CONFIG_OF_LIVE breaks the PCIe enumeration on Qemu Risc-V virt machine. The issue is described in the link below: Link: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/1 Signed-off-by: Mayuresh Chitale <mchitale(a)ventanamicro.com> --- drivers/pci/pcie_ecam_generic.c | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/drivers/pci/pcie_ecam_generic.c b/drivers/pci/pcie_ecam_generic.c index 1a9f9aec2e..f0effe0001 100644 --- a/drivers/pci/pcie_ecam_generic.c +++ b/drivers/pci/pcie_ecam_generic.c @@ -132,19 +132,14 @@ static int pci_generic_ecam_write_config(struct udevice *bus, pci_dev_t bdf, static int pci_generic_ecam_of_to_plat(struct udevice *dev) { struct generic_ecam_pcie *pcie = dev_get_priv(dev); - struct fdt_resource reg_res; - DECLARE_GLOBAL_DATA_PTR; - int err; - - err = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev), "reg", - 0, &reg_res); - if (err < 0) { - pr_err("\"reg\" resource not found\n"); - return err; - } - - pcie->size = fdt_resource_size(&reg_res); - pcie->cfg_base = map_physmem(reg_res.start, pcie->size, MAP_NOCACHE); + fdt_addr_t addr; + fdt_size_t size; + + addr = dev_read_addr_size(dev, "reg", &size); + if (addr == FDT_ADDR_T_NONE) + return -EINVAL; + pcie->size = size; + pcie->cfg_base = map_physmem(addr, pcie->size, MAP_NOCACHE); return 0; } -- 2.34.1

3 5

[PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension
by Heinrich Schuchardt 10 Nov '23

10 Nov '23

The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It provides an interface to a physical entropy source. A RNG driver based on the seed CSR is provided. It depends on mseccfg.sseed being set in the SBI firmware. If the seed CSR readable, is not determinable by S-mode without risking an exception. For safe driver probing allow to resume via a longjmp after an exception. As the driver depends on mseccfg.sseed=1 we should wait with merging the driver until a decision has been taken in the RISC-V PRS TG on prescribing this. Setting mseccfg.sseed=1 is queued for OpenSBI [1]. This has been discussed in the RISC-V Boot & Runtime Services TG. Standardization has to be pursued via the upcoming platform specification. A bug fix for QEMU relating to the Zkr extension is available in [2]. A similar Linux driver has been proposed in [3]. [1] lib: sbi: Configure seed bits when MSECCFG is readable https://patchwork.ozlabs.org/project/opensbi/patch/20230712083254.1585244-1… [2] [PATCH v2 1/1] target/riscv: correct csr_ops[CSR_MSECCFG] https://lore.kernel.org/qemu-devel/20231030102105.19501-1-heinrich.schuchar… [3] [PATCH v4 4/4] RISC-V: Implement archrandom when Zkr is available https://lore.kernel.org/linux-riscv/20230712084134.1648008-5-sameo@rivosinc… v3: Add API documentation. v2: Catch exception if mseccfg.sseed=0. Heinrich Schuchardt (2): riscv: allow resume after exception rng: Provide a RNG based on the RISC-V Zkr ISA extension arch/riscv/lib/interrupts.c | 13 ++++ doc/api/index.rst | 1 + drivers/rng/Kconfig | 8 +++ drivers/rng/Makefile | 1 + drivers/rng/riscv_zkr_rng.c | 116 ++++++++++++++++++++++++++++++++++++ include/interrupt.h | 45 ++++++++++++++ 6 files changed, 184 insertions(+) create mode 100644 drivers/rng/riscv_zkr_rng.c create mode 100644 include/interrupt.h -- 2.40.1

10 49

[PATCH 0/6] rockchip: puma-rk3399/ringneck-px30: fix check against value in default environment variable
by Quentin Schulz 10 Nov '23

10 Nov '23

For puma-rk3399 and ringneck-px30, U-Boot proper automatically modifies boot_targets to swap the order in which MMC storage media are used for standard boot based on which MMC storage medium was used to load U-Boot proper. This is however only done if the user has not changed it manually, therefore a check between the default and current value is done. This used to work fine until the migration to standard boot where boot_targets value size in the default environment went above the 32 characters that env_get_default function can return, thus resulting in a truncated variable. Therefore the check between default and current value would always fail. By adding the env_get_default_into function, a buffer of the appropriate size can be allocated on the stack to get the whole value of boot_targets in the default environment and thus fixing the check. While at it, only compile functions in the U-Boot boot phase they are used in. This fixes an issue where BOOT_TARGETS constant isn't defined in SPL or TPL and thus failing the build. Signed-off-by: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> --- Quentin Schulz (6): env: allow to copy value from default environment into a buffer env: migrate env_get_default to call env_get_default_into rockchip: puma-rk3399: only declare functions in U-Boot proper rockchip: ringneck-px30: only declare functions in U-Boot proper rockchip: puma-rk3399: fix modified boot_targets detection rockchip: ringneck-px30: fix modified boot_targets detection board/theobroma-systems/puma_rk3399/puma-rk3399.c | 11 +++++++++-- board/theobroma-systems/ringneck_px30/ringneck-px30.c | 11 +++++++++-- env/common.c | 16 +++++++++++++--- include/env.h | 10 ++++++++++ 4 files changed, 41 insertions(+), 7 deletions(-) --- base-commit: e17d174773e9ba9447596708e702b7382e47a6cf change-id: 20231108-env_default_theobroma-33774a337fe6 Best regards, -- Quentin Schulz <quentin.schulz(a)theobroma-systems.com>

4 18

PCIe layerscape ATU
by Fabian Cenedese 10 Nov '23

10 Nov '23

Hello I have a question to this code (drivers/pci/pcie_layerscape.c): void ls_pcie_atu_outbound_set(struct ls_pcie *pcie, int idx, int type, u64 phys, u64 bus_addr, u64 size) { dbi_writel(pcie, PCIE_ATU_REGION_OUTBOUND | idx, PCIE_ATU_VIEWPORT); dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_BASE); dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_BASE); dbi_writel(pcie, (u32)phys + size - 1, PCIE_ATU_LIMIT); dbi_writel(pcie, (u32)bus_addr, PCIE_ATU_LOWER_TARGET); dbi_writel(pcie, bus_addr >> 32, PCIE_ATU_UPPER_TARGET); dbi_writel(pcie, type, PCIE_ATU_CR1); dbi_writel(pcie, PCIE_ATU_ENABLE, PCIE_ATU_CR2); } /* Use bar match mode and MEM type as default */ void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, u32 vf_flag, int type, int idx, int bar, u64 phys) { dbi_writel(pcie, PCIE_ATU_REGION_INBOUND | idx, PCIE_ATU_VIEWPORT); dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_TARGET); dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_TARGET); dbi_writel(pcie, type | PCIE_ATU_FUNC_NUM(pf), PCIE_ATU_CR1); dbi_writel(pcie, PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE | (vf_flag ? PCIE_ATU_FUNC_NUM_MATCH_EN : 0) | (vf_flag ? PCIE_ATU_VFBAR_MATCH_MODE_EN : 0) | PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2); } void ls_pcie_dump_atu(struct ls_pcie *pcie, u32 win_num, u32 type) { int win_idx; for (win_idx = 0; win_idx < win_num; win_idx++) { dbi_writel(pcie, type | win_idx, PCIE_ATU_VIEWPORT); debug("iATU%d:\n", win_idx); debug("\tLOWER PHYS 0x%08x\n", dbi_readl(pcie, PCIE_ATU_LOWER_BASE)); debug("\tUPPER PHYS 0x%08x\n", dbi_readl(pcie, PCIE_ATU_UPPER_BASE)); if (type == PCIE_ATU_REGION_OUTBOUND) { debug("\tLOWER BUS 0x%08x\n", dbi_readl(pcie, PCIE_ATU_LOWER_TARGET)); debug("\tUPPER BUS 0x%08x\n", dbi_readl(pcie, PCIE_ATU_UPPER_TARGET)); debug("\tLIMIT 0x%08x\n", dbi_readl(pcie, PCIE_ATU_LIMIT)); } debug("\tCR1 0x%08x\n", dbi_readl(pcie, PCIE_ATU_CR1)); debug("\tCR2 0x%08x\n", dbi_readl(pcie, PCIE_ATU_CR2)); } } For outbound *_BASE and *_TARGET values are set. For inbound only *_TARGET values are set. However in dump it always prints the *_BASE values while the *_TARGET are only printed for outbound. Shouldn't that be the other way around? Either I didn't understand ATUs or there's a mixup here. Second question: We want to make an endpoint with 4 BARs. Is it possible to configure the internal addresses in the ATUs? The function ls_pcie_ep_setup_atu uses a configurable base address but then all ATUs are placed one after each other. How can I give them arbitrary addresses? Thanks bye Fabi

1 0

[PATCH v2 0/5] fs: fat: calculate FAT type based on cluster count
by christian.taedcke-oss＠weidmueller.com 10 Nov '23

10 Nov '23

From: Christian Taedcke <christian.taedcke(a)weidmueller.com> This series fixes an issue where the FAT type (FAT12, FAT16) is not correctly detected, e.g. when the BPB field BS_FilSysType contains the valid value "FAT ". This issue occures, for example, if a partition is formatted by swupdate using its diskformat handler. swupdate uses the FAT library from http://elm-chan.org/fsw/ff/ internally. See https://groups.google.com/g/swupdate/c/7Yc3NupjXx8 for a discussion in the swupdate mailing list. Please refer to the commit messages for more details. 1. Added bootsector checks Most tests from https://www.win.tue.nl/~aeb/linux/fs/fat/fat-2.html are added in the latest commit. Only the tests VIII, IX and X are not implemented. I also checked the Linux kernel code (v6.6) and did not find any checks on 'vistart->fs_type'. This is the reason why is skipped them here. See section '3. Size comparisons' for the impact on the binary size. 2. Tests I will try to implement some tests for the next version of this series. 3. Size comparisons I executed bloat-o-meter from the Linux kernel for an arm64 target (config xilinx_zynqmp_mini_emmc0_defconfig): Comparison of the binary spl/u-boot-spl between master (rev e17d174773e9ba9447596708e702b7382e47a6cf) and this patch series (including the added validity checks of the boot sector): add/remove: 0/0 grow/shrink: 1/1 up/down: 100/-12 (88) Function old new delta read_bootsectandvi 308 408 +100 fat_itr_root 444 432 -12 Total: Before=67977, After=68065, chg +0.13% When compare the size of the binary spl/u-boot-spl between master this series without the the validity checks of the boot sector (so i removed the last commit in this series): add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-24 (-24) Function old new delta read_bootsectandvi 308 296 -12 fat_itr_root 444 432 -12 Total: Before=67977, After=67953, chg -0.04% So the size of the spl on this arm64 target increases by 88 bytes for this series. When i remove the validity check the size decreases by 24 bytes. Changes in v2: - Use get_unaligned_le16 instead of custom macro - Move code change in test/image/spl_load_fs.c into separate commit - Use get_unaligned_le16 instead of custom macro - Extract FAT32 logic from determine_fat_bits() into read_bootsectandvi() - Rename determine_fat_bits() to determine_legacy_fat_bits() - Keep one goto label instead of removing both - Move changing gotos from read_bootsectandvi() into separate commit - Add validity checks for boot sector Christian Taedcke (5): fs: fat: use get_unaligned_le16 to convert u8[2] to u16 test: spl: Remove usage of FAT32_SIGN fs: fat: calculate FAT type based on cluster count fs: fat: simplify gotos from read_bootsectandvi fs: fat: add bootsector validity check fs/fat/fat.c | 114 +++++++++++++++++++++++++++++---------- include/fat.h | 6 --- test/image/spl_load_fs.c | 2 +- 3 files changed, 88 insertions(+), 34 deletions(-) -- 2.34.1

1 5

[PATCH 0/2] cmd: bcb: extend BCB APIs to support Android boot flow
by Dmitrii Merkurev 10 Nov '23

10 Nov '23

Following patches introduce various block interfaces support and extend API of BCB (bootloader control block) to reuse it for Android boot flow of Cuttlefish virtual device. Signed-off-by: Dmitrii Merkurev <dimorinny(a)google.com> Cc: Eugeniu Rosca <erosca(a)de.adit-jv.com> Cc: Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org> Cc: Simon Glass <sjg(a)chromium.org> Cc: Mattijs Korpershoek <mkorpershoek(a)baylibre.com> Cc: Sean Anderson <sean.anderson(a)seco.com> Cc: Cody Schuffelen <schuffelen(a)google.com> Dmitrii Merkurev (2): cmd: bcb: support various block device interfaces for BCB command cmd: bcb: extend BCB C API to allow read/write the fields cmd/Kconfig | 1 - cmd/bcb.c | 206 +++++++++++++++++++++++------------ doc/android/bcb.rst | 34 +++--- drivers/fastboot/fb_common.c | 14 ++- include/bcb.h | 59 +++++++++- 5 files changed, 227 insertions(+), 87 deletions(-) -- 2.42.0.869.gea05f2083d-goog

2 7

Lichee Pi 4A GMAC driver
by Gilbert Gilbs 09 Nov '23

09 Nov '23

Hi, I'm the happy owner of a Lichee Pi 4A by Sipeed, a RISC-V SBC based on the TH1520 SoC by Alibaba. Very basic support for this board was added in 5f3a7fdb. For now it's just able to chainload mainline U-Boot from vendor's fork of U-Boot. As an experiment, I started porting the glue layer for the GMAC into U-Boot, taking inspiration from the implementation that got merged into the net branch of Linux recently[1]. I eventually got the driver in a working state, but I had to rely on two suspicious workarounds that I'm unsure how to address. I'd like to discuss them here first before submitting a patch (if you're interested): 1. The designware driver can only read/write RX/TX DMA buffers from/to the 4GB address space, and I guess this is a hardware limitation. After chainloading U-Boot, these buffers are consistently allocated beyond the 4GB space making the driver inoperative. Is there a generic way of "forcing" U-Boot to allocate these DMA buffers in the 4GB address space? I believe it should be possible by dynamically allocating the buffers and using something like LMBs, but that sounds like a big and risky undertaking. For the time being, I've arbitrarily reduced the amount of RAM in the FDT to circumvent the issue, but it is completely not acceptable. 2. Some RX packets are corrupted because U-Boot occasionally modifies packets in-place, and those changes are flushed from the CPU data cache later, when the same RX buffer gets recycled. My current fix consists in invalidating the dcache of the whole buffer when freeing the packet in the designware driver. While this works fine, I was wondering if this is a common thing to do in drivers relying on DMA, and if there is a more efficient/common way to tackle this problem. I'm not aware of non-cached memory on this device that we could use. Thank you in advance, Nils [1] https://github.com/torvalds/linux/commit/f3c05bcddd5db130300e5ebaf27d355dd4…

1 0