April 2024 - U-Boot

[PATCH] clk: sifive: check wrpll_configure_for_rate() return value
by Heinrich Schuchardt 11 Apr '24

11 Apr '24

wrpll_configure_for_rate() might fail. We should check the return value. Fixes: d56d79ed27c6 ("drivers: clk: add fu740 support") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- drivers/clk/sifive/sifive-prci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/sifive/sifive-prci.c b/drivers/clk/sifive/sifive-prci.c index c8fb6002907..a950736f11b 100644 --- a/drivers/clk/sifive/sifive-prci.c +++ b/drivers/clk/sifive/sifive-prci.c @@ -209,7 +209,9 @@ unsigned long sifive_prci_wrpll_round_rate(struct __prci_clock *pc, memcpy(&c, &pwd->c, sizeof(c)); - wrpll_configure_for_rate(&c, rate, *parent_rate); + r = wrpll_configure_for_rate(&c, rate, *parent_rate); + if (r) + return r; return wrpll_calc_output_rate(&c, *parent_rate); } -- 2.43.0

2 1

Re: [PATCH v3] clk: set initial best mux parent to current parent with CLK_MUX_ROUND_CLOSEST
by Yang Xiwen 11 Apr '24

11 Apr '24

On 3/11/2024 5:34 PM, Maxime Ripard wrote: > On Thu, Mar 07, 2024 at 07:18:05PM +0800, Yang Xiwen wrote: >> On 3/7/2024 4:48 PM, Maxime Ripard wrote: >>> Hi, >>> >>> On Thu, Mar 07, 2024 at 10:03:50AM +0800, Yang Xiwen via B4 Relay wrote: >>>> From: Yang Xiwen <forbidden405(a)outlook.com> >>>> >>>> Originally, the initial clock rate is hardcoded to 0, this can lead to >>>> some problem when setting a very small rate with CLK_MUX_ROUND_CLOSEST. >>>> >>>> For example, if the lowest possible rate provided by the mux is 1000Hz, >>>> setting a rate below 500Hz will fail, because no clock can provide a >>>> better rate than the non-existant 0Hz. But it should succeed with 1000Hz >>>> being set. >>>> >>>> Setting the initial best parent to current parent could solve this bug. >>>> >>>> Signed-off-by: Yang Xiwen <forbidden405(a)outlook.com> >>> I don't think it would be the way to go. The biggest issue to me is that >>> it's inconsistent, and only changing the behaviour for a given flag >>> doesn't solve that. >> >> I think the current behavior is odd but conforms to the document if >> CLK_MUX_ROUND_CLOSEST is not specified. > clk_mux_determine_rate_flags isn't documented, and the determine_rate > clk_ops documentation doesn't mention it can return an error. > >> If i understand correctly, the default behavior of mux clocks is to >> select the closest rate lower than requested rate, and >> CLK_MUX_ROUND_CLOSEST removes the "lower than" limitation, which is >> what this version tries to accomplish. > The situation is not as clear-cut as you make it to be, unfortunately. > The determine_rate clk_ops implementation states: > > Given a target rate as input, returns the closest rate actually > supported by the clock, and optionally the parent clock that should be > used to provide the clock rate. > > So CLK_MUX_ROUND_CLOSEST shouldn't exist, because that's what > determine_rate expects so it should always be there. > > Now, the "actually supported by the clock" can be interpreted in > multiple ways, and most importantly, doesn't state what the behaviour is > if we can't find a rate actually supported by the clock. > > But now, this situation has been ambiguous for a while and thus drivers > kind of relied on that ambiguity. > > So the way to fix it up is: > > - Assess what drivers are relying on > - Document the current behaviour in clk_ops determine_rate From my investigation, it's totally a mess, especially for platform clk drivers (PLL). Some drivers always round down, the others round to nearest, with or without a specific flag to switch between them, depend on the division functions they choose. Fixing all of them seems needs quite a lot of time and would probably introduce some regressions. We'd probably only have to say both rounding to nearest and rounding down are acceptable, though either one is preferred. > - Make clk_mux_determine_rate_flags consistent with that I think we must keep existing flags and document the current behavior correctly because of the massive existing users of clk_mux. That's why i'm going to only fix CLK_MUX_ROUND_CLOSEST users. Hopefully it won't cause too many regressions. > - Run that through kernelci to make sure we don't have any regression We don't. I run 'tools/testing/kunit/kunit.py run --kunitconfig drivers/clk/.kunitconfig' each time before i send patches. Over all, it seems quite a lot of work here. > > Maxime The situation here becomes even more complex when it comes to U-Boot clk framework. They chose slightly different prototypes and stated clk_set_rate() can fail with -ve. It's a great burden for clk driver authors and maintainers when they try to port their drivers to U-Boot. Let's Cc U-Boot clk maintainers as well, and see how we can resolve the mess here. -- Regards, Yang Xiwen

3 2

[PATCH 1/1] sandbox: use sane access rights for files
by Heinrich Schuchardt 11 Apr '24

11 Apr '24

When writing an executable, allowing other users to modify it introduces a security issue. Generally we should avoid giving other users write access to our files by default. Replace chmod(777) by chmod(755) and chmod(644). Fixes: 47f5fcfb4169 ("sandbox: Add os_jump_to_image() to run another executable") Fixes: d9165153caea ("sandbox: add flags for open() call") Fixes: 5c2859cdc302 ("sandbox: Allow reading/writing of RAM buffer") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- arch/sandbox/cpu/os.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index cbae5109e85..1cf41578010 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -109,7 +109,7 @@ int os_open(const char *pathname, int os_flags) */ flags |= O_CLOEXEC; - return open(pathname, flags, 0777); + return open(pathname, flags, 0644); } int os_close(int fd) @@ -746,7 +746,7 @@ int os_write_ram_buf(const char *fname) struct sandbox_state *state = state_get_current(); int fd, ret; - fd = open(fname, O_CREAT | O_WRONLY, 0777); + fd = open(fname, O_CREAT | O_WRONLY, 0644); if (fd < 0) return -ENOENT; ret = write(fd, state->ram_buf, state->ram_size); @@ -791,7 +791,7 @@ static int make_exec(char *fname, const void *data, int size) if (write(fd, data, size) < 0) return -EIO; close(fd); - if (chmod(fname, 0777)) + if (chmod(fname, 0755)) return -ENOEXEC; return 0; -- 2.43.0

2 1

Tinkering Problems when Compiling on Apple Silicon
by Maxwell Leo 11 Apr '24

11 Apr '24

Dear Das U-Boot Developers: I recently tried to compile the OpenWRT system on a Mac with Apple Silicon, but encountered problems related to U-Boot. The problem is that the compiler is not adding system Python3 library by default when compiling the PyModule in some libs, pylibfdt, for example. In the Makefile of pylibfdt, the line “$(call if_changed,pymod)” invokes the pymod_cmd defined in the Makefile, and it further invokes the gcc command as below: /Volumes/Develop/openwrt/staging_dir/host/bin/gcc -shared -L/Volumes/Develop/openwrt/staging_dir/host/lib -L/Volumes/Develop/openwrt/staging_dir/hostpkg/lib -L/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/lib -O2 -I/Volumes/Develop/openwrt/staging_dir/host/include -I/Volumes/Develop/openwrt/staging_dir/hostpkg/include -I/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/include -I/Volumes/Develop/openwrt/staging_dir/host/include -I/Volumes/Develop/openwrt/staging_dir/hostpkg/include -I/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/include -std=gnu11 -I/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_addresses.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_empty_tree.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_overlay.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_ro.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_rw.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_strerror.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_sw.o build/temp.macosx-14.0-arm64-cpython-312/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/libfdt/fdt_wip.o build/temp.macosx-14.0-arm64-cpython-312/scripts/dtc/pylibfdt/libfdt_wrap.o -L/Volumes/Develop/openwrt/build_dir/target-aarch64_generic_musl/u-boot-nanopi-r2s-rk3328/u-boot-2024.01/scripts/dtc/pylibfdt/../libfdt -o build/lib.macosx-14.0-arm64-cpython-312/_libfdt.cpython-312-darwin.so<http://libfdt.cpython-312-darwin.so> Apparently it tries to link several files together but it gives the error: ld: warning: search path '/Volumes/Develop/openwrt/staging_dir/target-aarch64_generic_musl/host/lib' not found Undefined symbols for architecture arm64: "_PyArg_UnpackTuple", referenced from: _SwigPyObject_own in libfdt_wrap.o "_PyBool_FromLong", referenced from: _SwigPyObject_richcompare in libfdt_wrap.o _SwigPyObject_own in libfdt_wrap.o "_PyByteArray_AsString", referenced from: __wrap_fdt_magic in libfdt_wrap.o __wrap_fdt_totalsize in libfdt_wrap.o __wrap_fdt_off_dt_struct in libfdt_wrap.o __wrap_fdt_off_dt_strings in libfdt_wrap.o __wrap_fdt_off_mem_rsvmap in libfdt_wrap.o __wrap_fdt_version in libfdt_wrap.o __wrap_fdt_last_comp_version in libfdt_wrap.o … But interestingly enough, when I manually add the library at “/opt/homebrew/Cellar/python(a)3.12/3.12.2_1/Frameworks/Python.framework/Versions/3.12/lib/libpython3.12.xn--dylib-sw3b to the first gcc command, it runs fine. Hence I think the library is the main problem here. After executing the modified command, the compile goes on without complaining at “PYMOD rebuild”, but similar problems occured with other libs. As macOS is a completely POSIX compatible *nix operating system and ARM64 is blooming, I sincerely hope that you guys could consider fix the compiling on Apple Silicon platform. Thanks! Looking forward to your reply. Leo Maxwell Apr 11th, 2024

1 0

[PATCH 1/1] tools: use adequate entropy source for initialization vector
by Heinrich Schuchardt 11 Apr '24

11 Apr '24

The random() function is unsafe to initialize cryptographic data. Use getrandom() which reads from /dev/urandom instead. getrandom() is available on Linux sine release 3.17 and on BSD. Addresses-Coverity-ID: 312953 Calling risky function Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- tools/image-host.c | 36 +++--------------------------------- 1 file changed, 3 insertions(+), 33 deletions(-) diff --git a/tools/image-host.c b/tools/image-host.c index b2a0f2e6d16..d30a235baf6 100644 --- a/tools/image-host.c +++ b/tools/image-host.c @@ -13,11 +13,11 @@ #include <fdt_region.h> #include <image.h> #include <version.h> - #if CONFIG_IS_ENABLED(FIT_SIGNATURE) #include <openssl/pem.h> #include <openssl/evp.h> #endif +#include <sys/random.h> /** * fit_set_hash_value - set hash value in requested has node @@ -364,36 +364,6 @@ static int fit_image_read_key_iv_data(const char *keydir, const char *key_iv_nam return ret; } -static int get_random_data(void *data, int size) -{ - unsigned char *tmp = data; - struct timespec date; - int i, ret; - - if (!tmp) { - fprintf(stderr, "%s: pointer data is NULL\n", __func__); - ret = -1; - goto out; - } - - ret = clock_gettime(CLOCK_MONOTONIC, &date); - if (ret) { - fprintf(stderr, "%s: clock_gettime has failed (%s)\n", __func__, - strerror(errno)); - goto out; - } - - srandom(date.tv_nsec); - - for (i = 0; i < size; i++) { - *tmp = random() & 0xff; - tmp++; - } - - out: - return ret; -} - static int fit_image_setup_cipher(struct image_cipher_info *info, const char *keydir, void *fit, const char *image_name, int image_noffset, @@ -465,8 +435,8 @@ static int fit_image_setup_cipher(struct image_cipher_info *info, if (ret < 0) goto out; } else { - /* Generate an ramdom IV */ - ret = get_random_data((void *)info->iv, info->cipher->iv_len); + /* Generate a ramdom initialization vector */ + ret = getrandom((void *)info->iv, info->cipher->iv_len, 0); } out: -- 2.43.0

2 2

[PATCH 00/13] Complete decoupling of zboot logic from commands
by Simon Glass 10 Apr '24

10 Apr '24

This series refactors the zboot code to allow it to be used with CONFIG_COMMAND disabled. A new zboot_run() function is used to boot a zimage. This is cmde (part e of CMDLINE refactoring) It depends on dm/cmdd-working which depends on dm/bootstda-working which depends on dm/cmdc-working Simon Glass (13): x86: zboot: Move zimage definitions to the header file x86: zboot: Move command code into its own file x86: zboot: Create a separate ZBOOT option for zboot logic x86: zboot: Avoid iteration in do_zboot_states() x86: zboot: Create separate functions for the logic x86: zboot: Move environment setting into zboot_load() x86: zboot: Drop intermediate zboot_setup() function x86: zboot: Drop intermediate zboot_go() function x86: zboot: Move argument processing outside zboot_start() x86: zboot: Rename zboot_start() to zboot_run() x86: zboot: Separate logic functions from commands x86: zboot: Use zboot_start() in zboot_run() x86: zboot: Tidy up the comment for zboot_run() arch/Kconfig | 1 - arch/x86/Kconfig | 8 + arch/x86/include/asm/zimage.h | 97 ++++++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/zimage.c | 267 ++++------------------------------ boot/bootmeth_cros.c | 6 +- cmd/Kconfig | 2 + cmd/x86/Makefile | 1 + cmd/x86/zboot.c | 182 +++++++++++++++++++++++ include/bootm.h | 15 +- 10 files changed, 333 insertions(+), 248 deletions(-) create mode 100644 cmd/x86/zboot.c -- 2.43.0.rc2.451.g8631bc7472-goog

2 17

[GIT PULL] xilinx patches for v2024.07-rc1
by Michal Simek 10 Apr '24

10 Apr '24

Hi Tom, please apply these patches to your tree. Gitlab CI is not showing any issue and buildman for our platforms is also not showing any issue. If you have time please take a look at this https://lore.kernel.org/r/CAHTX3d+qAMKgL9T5Fo6y=rvXDiMS_mCiCEGazHt07eiVN32F… because we have issue in initcall code in connection to reporting issue back. Thanks, Michal The following changes since commit abd4fb5ac13215733569925a06991e0a182ede14: Merge patch series "Dockerfile: Build coreboot from source" (2024-02-27 16:28:57 -0500) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2024.07-rc1 for you to fetch changes up to f03f962c602c428a1091c3e0fad25b4cf64c9497: xilinx: common: Fix MAC address read from EEPROM (2024-04-10 15:16:57 +0200) ---------------------------------------------------------------- Xilinx changes for v2024.07-rc1 xilinx: - Do not call env_get_location when !ENV_IS_NOWHERE - Add FDT_FIXUP_PARTITIONS support - Fix legacy format MAC decoding zynqmp: - Enable semihosting SPL support - DT updates - Kconfig resort/cleanup - Don't describe second image/capsule if !SPL - Add support for dfu/capsule description via MTD - Support JTAG as alternative boot mode - Add support for TEG soc variant zynqmp-kria: - Wire usb4 boot device - Update SDIO tristate pin configuration - Disable SPI_FLASH_BAR to avoid issue with SPI after update mbv: - Enable SPL and binman - Small platform changes zynqmp-nand: - Error out in case of unsupported SW ECC - Clean error path versal-net: - Support multiple locations for variables ---------------------------------------------------------------- James Hilliard (1): xilinx: zynq: add FDT_FIXUP_PARTITIONS support Lukas Funke (1): arm64: zynqmp: Add label to pmu fwnode Manikanta Guntupalli (1): arm64: zynqmp: dts: Add required properties for rs485 support for KD240 Michal Simek (15): arm64: zynqmp: Remove snps,enable_guctl1_ipd_quirk property riscv: mbv: Align addresses with default DT riscv: mbv: Enable REMAKE_ELF by default riscv: mbv: Switch to OF_SEPARATE with fixed address riscv: mbv: Moving little_endian variable to data section riscv: mbv: Enable SPL and binman arm64: zynqmp: Fix gpio-key DT description arm64: zynqmp: Remove additional compatible string for sc-revB arm64: zynqmp: Describe USB wakeup interrupt arm64: zynqmp: Do not setup default SPL options without SPL arm64: zynqmp: Do not describe u-boot.itb if SPL is disabled arm64: zynqmp: Also support JTAG as alternative boot mode xilinx: Do not call private env_get_location() when !ENV_IS_NOWHERE arm64: zynqmp: Generate desc when SPL_FS_LOAD_PAYLOAD_NAME is valid arm64: zynqmp: Add MTD partition handling for dfu_alt_info generation Petr Zejdl (1): xilinx: common: Fix MAC address read from EEPROM Sean Anderson (1): arm64: zynqmp: Support semihosting boot method Shubhangi Shrikrushna Mahalle (1): arm64: zynqmp: Add bootcmd_usb4 variable Tejas Bhumkar (2): arm64: zynqmp: Disable Tri-state for SDIO configs: zynqmp_kria: Deactivate CONFIG_SPI_FLASH_BAR Venkatesh Yadav Abbarapu (6): arm64: zynqmp: Add usb4 to the boot targets mtd: nand: arasan: Print warning for unsupported ecc modes mtd: nand: arasan: Fix the crash caused by use after free xilinx: versal-net: Add support for saving env based on bootmode arm64: dts: zynqmp: make hw-ecc as the default ecc mode soc: zynqmp: Add the IDcode for TEG variant Vishal Sagar (1): arm64: zynqmp: Describe DisplayPort connector for Kria arch/arm/Kconfig | 8 +++ arch/arm/dts/zynqmp-mini-nand.dts | 6 ++ arch/arm/dts/zynqmp-sc-revB.dts | 4 +- arch/arm/dts/zynqmp-sck-kd-g-revA.dtso | 2 + arch/arm/dts/zynqmp-sck-kr-g-revB.dtso | 20 +++++++ arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 1 + arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 21 +++++++ arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts | 2 +- arch/arm/dts/zynqmp-vpk120-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 6 +- arch/arm/dts/zynqmp-zcu208-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu670-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu670-revB.dts | 2 +- arch/arm/dts/zynqmp.dtsi | 14 ++--- arch/arm/mach-zynqmp/Kconfig | 27 +-------- arch/arm/mach-zynqmp/spl.c | 15 +++-- arch/riscv/dts/xilinx-mbv32.dts | 3 + board/xilinx/Kconfig | 1 + board/xilinx/common/board.c | 31 ++++++++-- board/xilinx/mbv/Kconfig | 14 ++++- board/xilinx/mbv/board.c | 10 ++++ board/xilinx/versal-net/board.c | 32 ++++++++++ board/xilinx/versal/board.c | 2 + board/xilinx/zynqmp/zynqmp.c | 62 +++++++++++++++++--- board/xilinx/zynqmp/zynqmp_kria.env | 4 +- configs/xilinx_mbv32_defconfig | 23 ++++++-- configs/xilinx_mbv32_smode_defconfig | 25 ++++++-- configs/xilinx_versal_net_virt_defconfig | 3 + configs/xilinx_zynqmp_kria_defconfig | 1 - drivers/mtd/nand/raw/arasan_nfc.c | 34 +++++++---- drivers/serial/serial_xuartlite.c | 2 +- drivers/soc/soc_xilinx_zynqmp.c | 8 +++ env/Kconfig | 2 +- 34 files changed, 302 insertions(+), 91 deletions(-) -- 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/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

2 1

[PATCH 0/7] binman: ti: create binman nodes for EFI capsules
by Jonathan Humphreys 10 Apr '24

10 Apr '24

Add binman nodes for EFI capsules of firmware components. This is enabled for several TI SoC based platforms: AM64, AM62, AM62p, BeaglePlay, J7, and BeagleboneAI. Jonathan Humphreys (7): dts: ti: binman: Add base K3 firmware capsule nodes dts: am64x: binman: Include base K3 firmware capsule binman nodes dts: j721e: binman: Include firmware capsules binman nodes dts: beagleplay: binman: Include firmware capsules binman nodes dts: am62px: binman: Include base K3 firmware capsule binman nodes dts: am62x: binman: Include base K3 firmware capsule binman nodes dts: beagleboneai64: binman: Include firmware capsules binman nodes arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 9 ++++ arch/arm/dts/k3-am625-r5-beagleplay.dts | 5 +++ arch/arm/dts/k3-am625-sk-binman.dtsi | 5 +++ arch/arm/dts/k3-am62p-sk-binman.dtsi | 4 ++ arch/arm/dts/k3-am64x-binman.dtsi | 5 +++ arch/arm/dts/k3-binman-capsule-r5.dtsi | 24 +++++++++++ arch/arm/dts/k3-binman-capsule.dtsi | 42 +++++++++++++++++++ .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 9 ++++ arch/arm/dts/k3-j721e-binman.dtsi | 32 ++++++++++++++ arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 22 ++++++++++ 10 files changed, 157 insertions(+) create mode 100644 arch/arm/dts/k3-binman-capsule-r5.dtsi create mode 100644 arch/arm/dts/k3-binman-capsule.dtsi -- 2.34.1

3 10

[PATCH v2 0/3] mtd: spi-nor: Add support for S25FS-S family
by tkuw584924＠gmail.com 10 Apr '24

10 Apr '24

From: Takahiro Kuwano <Takahiro.Kuwano(a)infineon.com> The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR Flash devices with S25FS512S. Datasheets: https://www.infineon.com/dgdl/Infineon-S25FS064S_64_Mb_8_MB_FS-S_Flash_SPI_… https://www.infineon.com/dgdl/Infineon-S25FS128S_S25FS256S_1.8_V_Serial_Per… Takahiro Kuwano (3): mtd: spi-nore-core: Fix 4KB erase opcode in s25fs-s mtd: spi-nor-id: Use INFO6 for S25FL-S mtd: spi-nor: Add support for Infineon S25FS-S family drivers/mtd/spi/spi-nor-core.c | 28 +++++++++++++++++++++------- drivers/mtd/spi/spi-nor-ids.c | 7 +++++-- 2 files changed, 26 insertions(+), 9 deletions(-) -- 2.34.1

4 9

[PATCH] trace: use dynamic string buffer in make_flamegraph()
by Vincent Stehlé 10 Apr '24

10 Apr '24

The str[] buffer declared in make_flamegraph() is used to hold strings representing the full call-stacks recorded in traces. The size of this buffer is currently 500 characters and this works well for the documented examples. However, it is possible to exhaust this buffer when processing traces captured when running the UEFI shell on aarch64 sandbox for example. Indeed, the maximum length needed for such traces can reach 780 characters. As it is difficult to evaluate the maximum size that would ever be needed for all the possible traces, let's use a dynamically allocated `abuf' instead, which we reallocate when needed. This fixes the following error: String too short (500 chars) While at it, fix a few typos in strings and comments. Signed-off-by: Vincent Stehlé <vincent.stehle(a)arm.com> Cc: Tom Rini <trini(a)konsulko.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Michal Simek <michal.simek(a)amd.com> --- Hi, This can be verified using the `test_trace.py' pytest as a starting point. Configure with `sandbox_defconfig' plus the following options: CONFIG_TRACE=y CONFIG_TRACE_BUFFER_SIZE=0x02000000 CONFIG_TRACE_EARLY=y CONFIG_TRACE_EARLY_SIZE=0x01000000 Build with: make FTRACE=1 NO_LTO=1 Run the test with: ./test/py/test.py --bd sandbox --build-dir . -k trace -s Note that no reallocation happens during the test as the initial size of 500 characters is never exhausted; reduce the size manually if you want to force re-allocation. Also, make sure to delete /tmp/test_trace between tests. Best regards, Vincent Stehlé tools/proftool.c | 58 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 39 insertions(+), 19 deletions(-) diff --git a/tools/proftool.c b/tools/proftool.c index fca45e4a5af..c2e38099354 100644 --- a/tools/proftool.c +++ b/tools/proftool.c @@ -290,7 +290,7 @@ static void usage(void) "Options:\n" " -c <cfg>\tSpecify config file\n" " -f <subtype>\tSpecify output subtype\n" - " -m <map>\tSpecify Systen.map file\n" + " -m <map>\tSpecify System.map file\n" " -o <fname>\tSpecify output file\n" " -t <fname>\tSpecify trace data file (from U-Boot 'trace calls')\n" " -v <0-4>\tSpecify verbosity\n" @@ -306,7 +306,7 @@ static void usage(void) } /** - * h_cmp_offset - bsearch() function to compare two functions bny their offset + * h_cmp_offset - bsearch() function to compare two functions by their offset * * @v1: Pointer to first function (struct func_info) * @v2: Pointer to second function (struct func_info) @@ -431,7 +431,7 @@ static struct func_info *find_func_by_offset(uint offset) static struct func_info *find_caller_by_offset(uint offset) { int low; /* least function that could be a match */ - int high; /* greated function that could be a match */ + int high; /* greatest function that could be a match */ struct func_info key; low = 0; @@ -1352,7 +1352,7 @@ static int write_pages(struct twriter *tw, enum out_format_t out_format, } if (!(func->flags & FUNCF_TRACE)) { - debug("Funcion '%s' is excluded from trace\n", + debug("Function '%s' is excluded from trace\n", func->name); skip_count++; continue; @@ -1781,7 +1781,8 @@ static int make_flame_tree(enum out_format_t out_format, * * This works by maintaining a string shared across all recursive calls. The * function name for this node is added to the existing string, to make up the - * full call-stack description. For example, on entry, @str might contain: + * full call-stack description. For example, on entry, @str_buf->data might + * contain: * * "initf_bootstage;bootstage_mark_name" * ^ @base @@ -1795,18 +1796,18 @@ static int make_flame_tree(enum out_format_t out_format, * @fout: Output file * @out_format: Output format to use * @node: Node to output (pass the whole tree at first) - * @str: String to use to build the output line (e.g. 500 charas long) - * @maxlen: Maximum length of string + * @str_buf: String buffer to use to build the output line * @base: Current base position in the string * @treep: Returns the resulting flamegraph tree * Returns 0 if OK, -1 on error */ static int output_tree(FILE *fout, enum out_format_t out_format, - const struct flame_node *node, char *str, int maxlen, + const struct flame_node *node, struct abuf *str_buf, int base) { const struct flame_node *child; int pos; + char *str = abuf_data(str_buf); if (node->count) { if (out_format == OUT_FMT_FLAMEGRAPH_CALLS) { @@ -1832,18 +1833,29 @@ static int output_tree(FILE *fout, enum out_format_t out_format, if (pos) str[pos++] = ';'; list_for_each_entry(child, &node->child_head, sibling_node) { - int len; + int len, needed; len = strlen(child->func->name); - if (pos + len + 1 >= maxlen) { - fprintf(stderr, "String too short (%d chars)\n", - maxlen); - return -1; + needed = pos + len + 1; + if (needed > abuf_size(str_buf)) { + /* + * We need to re-allocate the string buffer; increase + * its size by multiples of 500 characters. + */ + needed = 500 * ((needed / 500) + 1); + if (!abuf_realloc(str_buf, needed)) + return -1; + str = abuf_data(str_buf); + memset(str + pos, 0, abuf_size(str_buf) - pos); } strcpy(str + pos, child->func->name); - if (output_tree(fout, out_format, child, str, maxlen, - pos + len)) + if (output_tree(fout, out_format, child, str_buf, pos + len)) return -1; + /* + * Update our pointer as the string buffer might have been + * re-allocated. + */ + str = abuf_data(str_buf); } return 0; @@ -1859,16 +1871,24 @@ static int output_tree(FILE *fout, enum out_format_t out_format, static int make_flamegraph(FILE *fout, enum out_format_t out_format) { struct flame_node *tree; - char str[500]; + struct abuf str_buf; + char *str; + int ret = 0; if (make_flame_tree(out_format, &tree)) return -1; - *str = '\0'; - if (output_tree(fout, out_format, tree, str, sizeof(str), 0)) + abuf_init(&str_buf); + if (!abuf_realloc(&str_buf, 500)) return -1; - return 0; + str = abuf_data(&str_buf); + memset(str, 0, abuf_size(&str_buf)); + if (output_tree(fout, out_format, tree, &str_buf, 0)) + ret = -1; + + abuf_uninit(&str_buf); + return ret; } /** -- 2.43.0

2 1