May 2024 - U-Boot

[PATCH 00/42] mmc: dw_mmc: Enable eMMC on E850-96 board
by Sam Protsenko 10 Jun '24

10 Jun '24

Bring 64-bit support to dw_mmc core and Exynos dw_mmc drivers, and enable it on E850-96 board. Additionally do some related cleanups and device tree updates. 64-bit version of DesignWare MMC can be often found on modern ARM64 chips. It's different from its older 32-bit version (which is already implemented in U-Boot): some new registers were added, existing register addresses are changed, DMA descriptor table is different, etc. Exynos DW MMC driver was updated too: ARM64 Exynos chips implement their clock drivers using CCF framework, pinmux configuration is done at startup in DM capable pinctrl drivers, device tree properties were changed w.r.t. their upstream (Linux kernel) counterparts. CLKSEL register address is also different on 64-bit Exynos platforms. The patch series was tested on E850-96 board by running mainline Linux kernel with Debian rootfs from eMMC ("boot" partition) with these commands: 8<-------------------------------------------------------------------->8 env set fdtaddr 0x8a000000 env set bootaddr 0x94000000 env set boot_kerneladdr 0x94000800 part start mmc 0 boot boot_start part size mmc 0 boot boot_size mmc read $bootaddr $boot_start $boot_size abootimg addr $bootaddr abootimg get dtb --index=0 dtb_start dtb_size cp.b $dtb_start $fdtaddr $dtb_size fdt addr $fdtaddr 0x100000 cp.b $boot_kerneladdr $loadaddr 2aaaa00 env set bootargs console=ttySAC0,115200n8 printk.devkmsg=on \ root=/dev/mmcblk0p12 rootwait rw booti $loadaddr - $fdtaddr 8<-------------------------------------------------------------------->8 For E850-96 eMMC to function properly in DDR mode, the pending patch [1] has to be applied. Otherwise it won't be possible for exynos_dw_mmc driver to change CIU clock rate from 200 MHz up to 400 MHz, and MMC will fall back to SDR mode, which makes eMMC throughput twice as slower. With patch [1] applied, 'mmc info' reports this: Bus Speed: 52000000 Mode: MMC DDR52 (52MHz) and 'clk dump' shows CIU clock rate to be ~400 MHz (after first mmc operation, e.g. 'part start' or 'mmc read'): 399750000 gout_mmc_embd_sdclkin Which makes sense, because dw_mmc requests to set CCLKIN = 52 MHz (with DDR/8-bit mode), and exynos_dw_mmc tries to set CIU clock rate to: SDCLKIN = 2 * ciu_div * CCLKIN = 2 * 4 * 52 MHz = 416 MHz, and the closest possible value the clock driver can set is 399.75 MHz, which works just fine. For Exynos4 and Exynos5 (ARM32) boards, this patch series was only build tested (manually and with buildman). The build is clean (no errors or warnings), but I don't have any Exynos4/Exynos5 boards at my disposal, so I can't actually verify MMC operation there. [1] https://lists.denx.de/pipermail/u-boot/2024-March/547719.html Sam Protsenko (42): mmc: dw_mmc: Remove common.h mmc: dw_mmc: Remove unused version field from struct dwmci_host mmc: dw_mmc: Move struct idmac to dw_mmc.c mmc: dw_mmc: Extract waiting for data busy into a separate routine mmc: dw_mmc: Extract FIFO init into a separate routine mmc: dw_mmc: Extract clock on/off code into a separate routine mmc: dw_mmc: Extract FIFO data transfer into a separate routine mmc: dw_mmc: Extract DMA transfer handling code into a separate routine mmc: dw_mmc: Extract setting the DMA descriptor into a separate routine mmc: dw_mmc: Improve 32-bit IDMAC descriptor namings mmc: dw_mmc: Add support for 64-bit IDMAC mmc: dw_mmc: Replace fifoth_val property with fifo-depth mmc: dw_mmc: Fix kernel-doc comments in dwmmc.h mmc: dw_mmc: Use CONFIG_IS_ENABLED() to check config options mmc: dw_mmc: Improve coding style arm: dts: exynos: Add upstream DW MMC properties to all Exynos dts dt-bindings: exynos: Update bindings doc for DW MMC controller arm: exynos: Add header guard for dwmmc.h mmc: exynos_dw_mmc: Fix obtaining the base address of controller mmc: exynos_dw_mmc: Fix getting private data in exynos_dwmci_board_init() mmc: exynos_dw_mmc: Don't call pinmux functions on ARM64 chips mmc: exynos_dw_mmc: Obtain and use CIU clock via CCF API mmc: exynos_dw_mmc: Use .of_to_plat for device tree parsing mmc: exynos_dw_mmc: Convert to use livetree API mmc: exynos_dw_mmc: Read upstream SDR timing properties mmc: exynos_dw_mmc: Abstract CLKSEL register mmc: exynos_dw_mmc: Refactor fixed CIU clock divider mmc: exynos_dw_mmc: Read common bus-width property mmc: exynos_dw_mmc: Read common clock-frequency property mmc: exynos_dw_mmc: Move quirks from struct dwmci_host to chip data mmc: exynos_dw_mmc: Read and use DDR timing when available mmc: exynos_dw_mmc: Set requested freq in get_mmc_clk() callback mmc: exynos_dw_mmc: Add support for ARM64 Exynos chips mmc: exynos_dw_mmc: Remove common.h mmc: exynos_dw_mmc: Use CONFIG_IS_ENABLED() to check config options mmc: exynos_dw_mmc: Pull all init code into probe function mmc: exynos_dw_mmc: Don't call dwmci_setup_cfg() after add_dwmci() mmc: exynos_dw_mmc: Use dev->name as driver's displayed name mmc: exynos_dw_mmc: Improve coding style arm: dts: exynos: Remove outdated DW MMC properties in all Exynos dts configs: e850-96: Enable MMC doc: samsung: Mention enabled eMMC in E850-96 board doc arch/arm/dts/exynos4210-origen.dts | 3 +- arch/arm/dts/exynos4210-trats.dts | 6 +- arch/arm/dts/exynos4210-universal_c210.dts | 6 +- arch/arm/dts/exynos4412-odroid.dts | 14 +- arch/arm/dts/exynos4412-trats2.dts | 20 +- arch/arm/dts/exynos5250-arndale.dts | 10 +- arch/arm/dts/exynos5250-smdk5250.dts | 13 +- arch/arm/dts/exynos5250-snow.dts | 13 +- arch/arm/dts/exynos5250-spring.dts | 7 +- arch/arm/dts/exynos5420-smdk5420.dts | 13 +- arch/arm/dts/exynos5422-odroidxu3.dts | 4 +- arch/arm/dts/exynos54xx.dtsi | 13 +- arch/arm/mach-exynos/include/mach/dwmmc.h | 40 +- configs/e850-96_defconfig | 10 +- doc/board/samsung/e850-96.rst | 5 +- doc/device-tree-bindings/exynos/dwmmc.txt | 46 +- drivers/mmc/ca_dw_mmc.c | 2 +- drivers/mmc/dw_mmc.c | 535 +++++++++++++-------- drivers/mmc/exynos_dw_mmc.c | 362 +++++++++----- drivers/mmc/ftsdc010_mci.h | 1 - drivers/mmc/hi6220_dw_mmc.c | 7 +- drivers/mmc/nexell_dw_mmc.c | 5 +- drivers/mmc/rockchip_dw_mmc.c | 5 +- drivers/mmc/s5p_sdhci.c | 2 +- drivers/mmc/snps_dw_mmc.c | 6 +- drivers/mmc/socfpga_dw_mmc.c | 4 +- include/dwmmc.h | 246 +++++----- 27 files changed, 858 insertions(+), 540 deletions(-) -- 2.39.2

2 56

[PATCH] doc: Add UEFI supplement document
by Jiaxun Yang 08 Jun '24

08 Jun '24

Add UEFI supplement document to define some behaviours on architectures not covered by the original specification. Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Hi all, This document is in response to discussion at [1]. It is produced based on my attempt to port U-Boot UEFI to MIPS and Xtensa. I also plan to try m68k. Please review Thanks [1]: https://lore.kernel.org/u-boot/CAC_iWjLbY6+FaUYQw2Zv5y5byCnXRHxfzvrFf1dMyJX… --- doc/develop/uefi/index.rst | 1 + doc/develop/uefi/uefi_supplement.rst | 73 ++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+) diff --git a/doc/develop/uefi/index.rst b/doc/develop/uefi/index.rst index e26b1fbe05c5..a274fff88754 100644 --- a/doc/develop/uefi/index.rst +++ b/doc/develop/uefi/index.rst @@ -11,6 +11,7 @@ can be run an UEFI payload. :maxdepth: 2 uefi.rst + uefi_supplement.rst u-boot_on_efi.rst iscsi.rst fwu_updates.rst diff --git a/doc/develop/uefi/uefi_supplement.rst b/doc/develop/uefi/uefi_supplement.rst new file mode 100644 index 000000000000..cb20cd290912 --- /dev/null +++ b/doc/develop/uefi/uefi_supplement.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (c) 2024 Jiaxun Yang <jiaxun.yang(a)flygoat.com> + +U-Boot Supplement to UEFI Specifications +======================================== + +Motivation +---------- + +The UEFI specifications are designed to be platform-independent, enabling the +implementation of UEFI-like API support across various architectures. However, +some platform-dependent aspects and constraints remain. This document provides +a supplement to the UEFI specifications for U-Boot, clarifying these platform +dependent details for architectures not covered by the original specifications. + +Architectural Conventions +------------------------- + +The UEFI specifications cover IA32, X64, ARM, AARCH64, RISC-V, LoongArch, and +Itanium architectures. This document extends the UEFI specifications to include +all architectures supported by U-Boot. + +The following conventions are used for these architectures: + +- For architectures with multiple ABIs, we adhere to the calling conventions + used by the Linux kernel for the same architecture. + +- Optional CPU registers (floating-point, SIMD) are excluded from calling + conventions. However, the UEFI payload should be able to utilize them if + available. + +- Control is handed over to the UEFI payload at the privilege level used + by the Linux kernel for the same architecture. + +- Identity mapping (i.e., VA == PA mapping) is preferred for UEFI. However, + this may not be possible for some architectures. In such cases, if the + processor supports a default linear translation, it should be used. + +- Endianness: UEFI specifications enforce little-endian architectures. + However, U-Boot supports both little-endian and big-endian architectures. + For big-endian architectures, UEFI data structures should be stored in + native endianness, with exceptions explicitly specified. + +UEFI Images +----------- + +The UEFI specifications define the PE/COFF image format for UEFI applications. +U-Boot extends this format as follows: + +- **PE32+ Machine Type**: UEFI specifications define machine types for supported + architectures. For machines not covered by UEFI specifications, we use the + machine type defined by the Microsoft PE/COFF specification if possible. + Otherwise, we use the ``IMAGE_FILE_MACHINE_UNKNOWN`` (0) machine type. + U-Boot should always accept ``IMAGE_FILE_MACHINE_UNKNOWN`` as a valid + machine type. + +- **Header Endianness**: PE/COFF header data fields are always stored as + little-endian, regardless of the target architecture's endianness. + +- **DOS Stub**: To accommodate various boot image formats, we relax the requirement + for a DOS stub in the UEFI image. U-Boot should accept UEFI images without a DOS + stub and MZ signature. However, U-Boot still expects the PE/COFF header at the + file offset specified at offset 0x3C. + +I/O Device Access +----------------- + +UEFI specifications define the EFI_DEVICE_IO_PROTOCOL and EFI_PCI_IO_PROTOCOL +for accessing I/O devices. U-Boot extends these specifications as follows: + +- All I/O access is performed using the CPU's native endianness. + For big-endian architectures, U-Boot should convert data to/from little-endian + before/after accessing I/O devices. --- base-commit: 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a change-id: 20240529-efi-spec-0ea657985272 Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

2 2

[PATCH] memory: ti-gpmc: use printf to dump settings/timings
by Roger Quadros 08 Jun '24

08 Jun '24

pr_info() depends on CONFIG_LOGLEVEL > 6. If user has enabled CONFIG_TI_GPMC_DEBUG then we should print the GPMC settings/timings regardless of CONFIG_LOGLEVEL. So use printf() instead of pr_info(). Signed-off-by: Roger Quadros <rogerq(a)kernel.org> --- drivers/memory/ti-gpmc.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c index 8af48e199a7..e979c431e33 100644 --- a/drivers/memory/ti-gpmc.c +++ b/drivers/memory/ti-gpmc.c @@ -242,20 +242,20 @@ static int get_gpmc_timing_reg(/* timing specifiers */ if (l) time_ns_min = gpmc_clk_ticks_to_ns(l - 1, cs, cd) + 1; time_ns = gpmc_clk_ticks_to_ns(l, cs, cd); - pr_info("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n", - name, time_ns, time_ns_min, time_ns, l, - invalid ? "; invalid " : " "); + printf("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n", + name, time_ns, time_ns_min, time_ns, l, + invalid ? "; invalid " : " "); } else { /* raw format */ - pr_info("gpmc,%s = <%u>;%s\n", name, l, - invalid ? " /* invalid */" : ""); + printf("gpmc,%s = <%u>;%s\n", name, l, + invalid ? " /* invalid */" : ""); } return l; } #define GPMC_PRINT_CONFIG(cs, config) \ - pr_info("CS%i %s: 0x%08x\n", cs, #config, \ + printf("CS%i %s: 0x%08x\n", cs, #config, \ gpmc_cs_read_reg(cs, config)) #define GPMC_GET_RAW(reg, st, end, field) \ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0, 1, 0) @@ -274,7 +274,7 @@ static int get_gpmc_timing_reg(/* timing specifiers */ static void gpmc_show_regs(int cs, const char *desc) { - pr_info("gpmc cs%i %s:\n", cs, desc); + printf("gpmc cs%i %s:\n", cs, desc); GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG1); GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG2); GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG3); @@ -291,7 +291,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc) { gpmc_show_regs(cs, desc); - pr_info("gpmc cs%i access configuration:\n", cs); + printf("gpmc cs%i access configuration:\n", cs); GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 4, 4, "time-para-granularity"); GPMC_GET_RAW(GPMC_CS_CONFIG1, 8, 9, "mux-add-data"); GPMC_GET_RAW_SHIFT_MAX(GPMC_CS_CONFIG1, 12, 13, 1, @@ -318,7 +318,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc) GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 7, 7, "cycle2cycle-samecsen"); GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 6, 6, "cycle2cycle-diffcsen"); - pr_info("gpmc cs%i timings configuration:\n", cs); + printf("gpmc cs%i timings configuration:\n", cs); GPMC_GET_TICKS(GPMC_CS_CONFIG2, 0, 3, "cs-on-ns"); GPMC_GET_TICKS(GPMC_CS_CONFIG2, 8, 12, "cs-rd-off-ns"); GPMC_GET_TICKS(GPMC_CS_CONFIG2, 16, 20, "cs-wr-off-ns"); @@ -409,9 +409,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit, int max l = gpmc_cs_read_reg(cs, reg); if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) { - pr_info("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n", - cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 1000, - (l >> st_bit) & mask, time); + printf("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n", + cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 1000, + (l >> st_bit) & mask, time); } l &= ~(mask << st_bit); @@ -618,8 +618,8 @@ static int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t, return -ENXIO; if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) { - pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n", - cs, (div * gpmc_get_fclk_period()) / 1000, div); + printf("GPMC CS%d CLK period is %lu ns (div %d)\n", + cs, (div * gpmc_get_fclk_period()) / 1000, div); } gpmc_cs_bool_timings(cs, &t->bool_timings); --- base-commit: e7992828adcd5fad75bce9e6c41dfa9277ab93b0 change-id: 20240515-for-2024-10-gpmc-printf-dcd5f446d951 Best regards, -- Roger Quadros <rogerq(a)kernel.org>

2 1

[PATCH] include: extension_board: Increase overlay file name size
by Daniel Schultz 08 Jun '24

08 Jun '24

Upstream overlays like the ARM64 TI k3-am625-beagleplay-csi2-tevi-ov5640.dtso can easily have more then 32 characters. Increase the overlay length to 64 characters to apply overlays with longer names. Signed-off-by: Daniel Schultz <d.schultz(a)phytec.de> --- include/extension_board.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/extension_board.h b/include/extension_board.h index 87d404c0074..22e4104bc54 100644 --- a/include/extension_board.h +++ b/include/extension_board.h @@ -14,7 +14,7 @@ struct extension { char name[32]; char owner[32]; char version[32]; - char overlay[32]; + char overlay[64]; char other[32]; }; -- 2.25.1

3 2

[PATCH v2 0/5] *** phyCORE-AM62x: DDR detection / Inject DDR timing deltas ***
by Wadim Egorov 08 Jun '24

08 Jun '24

Changes in v2: - Reabse to current next - Add Tested-by: John Ma <jma(a)phytec.com> - Add Kconfig option to select RAM size statically - Make board/phytec/common/k3 always compile for CONFIG_ARCH_K3 v1: https://lists.denx.de/pipermail/u-boot/2024-May/553057.html Wadim Egorov (5): board: phytec: Make AM6 SoM detection depend on I2C board: phytec: Fix function definitions in AM6x SOM detection arm: mach-k3: am625: Call do_board_detect() before DDR probing board: phytec: common: Introduce a method to inject DDR timings deltas board: phytec: am62x: Add support for 1 & 4 GB RAM variants arch/arm/mach-k3/am62x/am625_init.c | 2 + board/phytec/common/Kconfig | 2 + board/phytec/common/Makefile | 4 +- board/phytec/common/am6_som_detection.c | 18 +- board/phytec/common/am6_som_detection.h | 8 + board/phytec/common/k3/Makefile | 1 + board/phytec/common/k3/k3_ddrss_patch.c | 68 ++++++ board/phytec/common/k3/k3_ddrss_patch.h | 28 +++ board/phytec/phycore_am62x/Kconfig | 30 +++ board/phytec/phycore_am62x/MAINTAINERS | 1 + board/phytec/phycore_am62x/phycore-am62x.c | 152 ++++++++++++- board/phytec/phycore_am62x/phycore-ddr-data.h | 206 ++++++++++++++++++ configs/phycore_am62x_a53_defconfig | 4 + configs/phycore_am62x_r5_defconfig | 4 + 14 files changed, 514 insertions(+), 14 deletions(-) create mode 100644 board/phytec/common/k3/k3_ddrss_patch.c create mode 100644 board/phytec/common/k3/k3_ddrss_patch.h create mode 100644 board/phytec/phycore_am62x/phycore-ddr-data.h -- 2.34.1

3 8

[PATCH 0/6] PHYTEC SOM Detection API v3
by Daniel Schultz 08 Jun '24

08 Jun '24

This patch series adds support for the EEPROM v3 API. V3 is backwards compatible to V2 and therefore, the V2 image still exists at the beginning. Only the API version changed from 2 to 3. V3 is a block-based memory layout organized as singled-linked list with different types of blocks. This is a more flexible approach and allows us to extend it by more block types in the future. The V3 data starts with a 8-byte large header which defines the block count (u8), V3 subversion (u8) and data payload length (u16). Additionally the header contains a CRC8 checksum a 3 reserved bytes. Each block starts with a 4-byte large header which defined the block type (u8), the absolute address of the next block (u16) and a CRC8 checksum. The content itself is defined via the block type and we currently have 2 different types: 1) MAC: Contains the Ethernet interface number (u8), MAC address (6 x u8) and a CRC8 checksum. Daniel Schultz (6): board: phytec: common: Move eeprom read to new function board: phytec: common: Define PHYTEC_API2_DATA_LEN board: phytec: common: Move API v2 init to new function board: phytec: common: Add API v3 board: phytec: common: k3: Set MAC configs: phycore_am62x_a53_defconfig: Enable CONFIG_ENV_OVERWRITE board/phytec/common/Kconfig | 9 + board/phytec/common/Makefile | 2 +- board/phytec/common/k3/board.c | 23 ++ board/phytec/common/phytec_som_detection.c | 228 +++++++++++++++--- board/phytec/common/phytec_som_detection.h | 9 + .../common/phytec_som_detection_blocks.c | 105 ++++++++ .../common/phytec_som_detection_blocks.h | 61 +++++ configs/phycore_am62x_a53_defconfig | 1 + 8 files changed, 408 insertions(+), 30 deletions(-) create mode 100644 board/phytec/common/phytec_som_detection_blocks.c create mode 100644 board/phytec/common/phytec_som_detection_blocks.h -- 2.25.1

3 11

[PATCH 0/2] Add remoteproc support for J784S4 SoCs
by Beleswar Padhi 08 Jun '24

08 Jun '24

Hello All, This series adds remoteproc support for TI's J784S4 SoCs. The K3 J784S4 SoCs have four dual-core R5F subsystems and four C71x DSP subsystems. Enable the remoteproc drivers in defconfig and set the rproc firmware names to add remoteproc support. Note: No driver changes are required as J784S4 SoCs have the same data as J721S2 SoCs. Thus, utilize the existing compatible string for driver probe. Beleswar Padhi (2): configs: j784s4_evm_a72_defconfig: Enable remoteproc drivers board: ti: j784s4: j784s4.env: Set remoteproc firmware names board/ti/j784s4/j784s4.env | 6 ++++++ configs/j784s4_evm_a72_defconfig | 3 +++ 2 files changed, 9 insertions(+) -- 2.34.1

2 3

[PATCH 0/4] Adding support to load secure firmware for HS devices
by Udit Kumar 08 Jun '24

08 Jun '24

Some use case needs rproc firmware to be loaded at u-boot stage, using following commands at u-boot shell, firmware could be loaded => setenv dorprocboot 1 => run boot_rprocs For Secure devices, secure version of rproc firmware should be loaded, which is appended by sec keyword[0]. but currently non-secure firmware is loaded even for secure devices. So adding support for loading secure firmware on Secured devices. [0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7 Bootlogs: GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-g… line 65 onwards HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-h… line 60 onwards Manorit Chawdhry (3): include: mach-k3: move k3 security functions to security.h drivers: remoteproc: ti_k3 : enable secure booting with firmware images mach-k3: common.c: add a flag for booting authenticated rproc binaries Udit Kumar (1): include: env: ti: Add support for secure firmwares arch/arm/mach-k3/common.c | 4 +++- arch/arm/mach-k3/common.h | 4 ++-- arch/arm/mach-k3/include/mach/security.h | 11 +++++++++++ drivers/remoteproc/ti_k3_dsp_rproc.c | 4 ++++ drivers/remoteproc/ti_k3_r5f_rproc.c | 4 ++++ include/env/ti/k3_rproc.env | 6 +++++- include/env/ti/ti_common.env | 1 + 7 files changed, 30 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/security.h -- 2.34.1

4 15

[PATCH v1 0/2] arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control
by Emanuele Ghidoli 08 Jun '24

08 Jun '24

From: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> Manually, since SysConfig tool do not have the relevant option, set PHY_LP4_WDQS_OE_EXTEND to 1. Since WDQS control mode is required on our modules LPDDR4, this enables WDQS control mode 1. Emanuele Ghidoli (2): arm: dts: k3-am625-verdin: Update autogenerated LPDDR4 configuration arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) -- 2.34.1

2 3

[PATCH 00/11] 'eeprom' command improvements
by Marek Behún 07 Jun '24

07 Jun '24

Hi Tom, this series contains improvements for the 'eeprom' command: - refactors - fixes - improvements - ability to use driver model EEPROMs (uclass UCLASS_I2C_EEPROM) - more flexible EEPROM layout support It should not cause any behavior change for any existing board. This series is a dependency for some DDR issue fixes for Turris Omnia. I will be sending that one separately. github PR link (with CI): https://github.com/u-boot/u-boot/pull/540 - there is a failure for test.py for sandbox sandbox_clang but it seems unrelated to these changes Marek Behún (11): common: eeprom_layout: Assign default layout methods and parameters before specific ones common: eeprom_layout: Split field finding code from the field update function common: eeprom_field: Fix updating binary field common: eeprom_field: Drop unnecessary comparison cmd: eeprom: Fix usage help for the eeprom command cmd: eeprom: Hide eeprom layout versioning behind a Kconfig option cmd: eeprom: Deduplicate parse_i2c_bus_addr() calls cmd: eeprom: Refactor eeprom device specifier parsing cmd: eeprom: Refactor command execution into function by action cmd: eeprom: Don't read/write whole EEPROM if not necessary cmd: eeprom: Extend to EEPROMs probed via driver model cmd/Kconfig | 9 +- cmd/eeprom.c | 305 +++++++++++++++++++++++++--------- common/eeprom/eeprom_field.c | 4 +- common/eeprom/eeprom_layout.c | 54 +++--- configs/cm_fx6_defconfig | 1 + configs/cm_t43_defconfig | 1 + include/eeprom_layout.h | 4 + 7 files changed, 273 insertions(+), 105 deletions(-) -- 2.44.1

2 12