April 2024 - U-Boot

[PATCH v3 00/20] FWU: Add support for FWU metadata version 2
by Sughosh Ganu 25 May '24

25 May '24

The following patch series adds support for version 2 of the FWU metadata. The version 2 metadata structure is defined in the latest revision of the FWU specification [1]. The earlier versions of these patches were migrating to a version 2 only support in U-Boot, similar to TF-A. However, based on feedback from ST [2], this series has been updated to support both versions. A platform would still be needed to enable one of the two versions of metadata through a config symbol. TF-A has code which reads the FWU metadata and boots the platform from the active partition. TF-A has decided to migrate the FWU code to a version 2 only support. These changes have been merged in upstream TF-A. These changes have been tested on the ST DK2 board, which uses the GPT based partitioning scheme. Both V1 and V2 metadata versions have been tested on the DK2 board. These changes need to be tested on platforms with MTD partitioned storage devices. @Michal and @Kojima-san, please help in this testing. Note: The CI is breaking on some sandbox py tests, but the errors look unrelated. I will look into those issues, but the code review can proceed. [1] - https://developer.arm.com/documentation/den0118/latest/ [2] - https://lists.denx.de/pipermail/u-boot/2024-February/546277.html Changes since V2: * New patch which retains support for V1 of metadata * Earlier patch was catering to v2 only support. These changes support both versions of metadata. * Earlier patch was migrating to v2 only support. These changes support both versions. * Support both metadata versions instead of only v2. * Added documentation changes. * Make changes to have the test work with v1 metadata. * Make changes to have the test work with updated logic in fwu code. * Changes to indicate support for both v1 and v2 instead of only v2. * Add config symbol for selecting either of the two metadata versions. Sughosh Ganu (20): configs: fwu: remove FWU configs for metadata V2 support tools: mkfwumdata: fix the size parameter to the fwrite call drivers: fwu: add the size parameter to the metadata access API's drivers: fwu: mtd: allocate buffer for image info dynamically fwu: metadata: add support for version 2 of the structure fwu: metadata: add a version agnostic structure fwu: metadata: add functions for handling version specific metadata fields fwu: make changes to access version agnostic structure fields capsule: fwu: transition the platform state on a successful update fwu: add config symbols for enabling FWU metadata versions fwu: mtd: remove unused argument from function call fwu: mtd: get MTD partition specific info from driver fwu: mtd: obtain image information from version agnostic structure cmd: fwu: make changes for supporting FWU metadata version 2 tools: mkfwumdata: add support for metadata version 2 tools: mkfwumdata: add logic to append vendor data to the FWU metadata test: fwu: make changes to the FWU metadata access test doc: fwu: make changes to reflect support for FWU metadata v2 MAINTAINERS: add entry for FWU multi bank update feature configs: fwu: re-enable FWU configs MAINTAINERS | 8 + cmd/fwu_mdata.c | 39 ++-- configs/corstone1000_defconfig | 1 + configs/sandbox64_defconfig | 1 + configs/synquacer_developerbox_defconfig | 2 +- doc/board/socionext/developerbox.rst | 7 +- doc/develop/uefi/fwu_updates.rst | 20 +- doc/mkfwumdata.1 | 16 +- drivers/fwu-mdata/fwu-mdata-uclass.c | 10 +- drivers/fwu-mdata/gpt_blk.c | 23 +- drivers/fwu-mdata/raw_mtd.c | 78 ++++--- include/fwu.h | 147 ++++++++++++- include/fwu_mdata.h | 71 ++++++- lib/efi_loader/efi_capsule.c | 14 +- lib/fwu_updates/Kconfig | 14 ++ lib/fwu_updates/Makefile | 2 + lib/fwu_updates/fwu.c | 204 ++++++++++++------ lib/fwu_updates/fwu_mtd.c | 34 +-- lib/fwu_updates/fwu_v1.c | 167 +++++++++++++++ lib/fwu_updates/fwu_v2.c | 260 +++++++++++++++++++++++ test/dm/fwu_mdata.c | 16 +- tools/mkfwumdata.c | 235 ++++++++++++++++---- 22 files changed, 1153 insertions(+), 216 deletions(-) create mode 100644 lib/fwu_updates/fwu_v1.c create mode 100644 lib/fwu_updates/fwu_v2.c -- 2.34.1

5 26

[PATCH v11 0/8] spi-nor: Add parallel and stacked memories support
by Venkatesh Yadav Abbarapu 24 May '24

24 May '24

This series adds support for Xilinx qspi parallel and stacked memeories. In parallel mode, the current implementation assumes that a maximum of two flashes are connected. The QSPI controller splits the data evenly between both the flashes so, both the flashes that are connected in parallel mode should be identical. During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in nor->flags. In stacked mode the current implementation assumes that a maximum of two flashes are connected and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical. Spi-nor will pass on the appropriate flash select flag to low level driver, and it will select pass all the data to that particular flash. Write operation in parallel mode are performed in page size * 2 chunks as each write operation results in writing both the flashes. For doubling the address space each operation is performed at addr/2 flash offset, where addr is the address specified by the user. Similarly for read and erase operations it will read from both flashes, so size and offset are divided by 2 and send to flash. Changes in v2: - Fixed the compilation issues. Changes in v3: - Fixed the CI issues. Changes in v4: - Removed the dio,dummy_bytes variables from zynq_qspi driver. - Fix the compilation issue by including the DM_SPI config. Changes in v5: - Fixed the issue reported by buildman. Changes in v6: - Fixed the issues reported while running the sandbox test cases. Changes in v7: - Fixed the issues reported while running these da850evm_defconfig, imx28_xea_defconfig configs. - Fixed the issue when DM_SPI config is disabled. - Fixed the issue while running the sandbox_noinst_defconfig with spl ./spl/u-boot-spl -d arch/sandbox/dts/test.dtb jedec_spi_nor spi.bin@0: has no valid 'reg' property (-12) jedec_spi_nor spi.bin@1: has no valid 'reg' property (-12) ### ERROR ### Please RESET the board ### Changes in v8: - Fixed the compilation issue with imx28_xea_defconfig. - Fixed the SPL size issue with the axm and taurus defconfigs. - Rebased the patches on top of next branch. Changes in v9: - Updated the commit log why SPL_FIT is being enabled. Changes in v10: - Added the new config SPI_ADVANCE to fix the issue while enabling imx28_xea_defconfig. Changes in v11: - Removed the unused variable, corrected the type of variable and replaced memcpy with memmove. Ashok Reddy Soma (4): mtd: spi-nor: Add parallel and stacked memories support mtd: spi-nor: Add parallel memories support for read_sr and read_fsr mtd: spi-nor: Add parallel and stacked memories support in read_bar and write_bar spi: spi-uclass: Read chipselect and restrict capabilities Venkatesh Yadav Abbarapu (4): spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver spi: zynq_qspi: Add parallel memories support in QSPI driver spi: Add the spi advance options for non SPL config: xea: Enable the SPI_ADVANCE config option configs/imx28_xea_defconfig | 1 + drivers/mtd/spi/sandbox.c | 2 +- drivers/mtd/spi/spi-nor-core.c | 399 ++++++++++++++++++++++++++++----- drivers/spi/Kconfig | 7 + drivers/spi/altera_spi.c | 4 +- drivers/spi/atcspi200_spi.c | 2 +- drivers/spi/ath79_spi.c | 2 +- drivers/spi/atmel_spi.c | 6 +- drivers/spi/bcm63xx_hsspi.c | 42 ++-- drivers/spi/bcm63xx_spi.c | 6 +- drivers/spi/bcmbca_hsspi.c | 34 +-- drivers/spi/cf_spi.c | 6 +- drivers/spi/davinci_spi.c | 8 +- drivers/spi/fsl_dspi.c | 18 +- drivers/spi/fsl_espi.c | 4 +- drivers/spi/fsl_qspi.c | 4 +- drivers/spi/gxp_spi.c | 2 +- drivers/spi/mpc8xx_spi.c | 4 +- drivers/spi/mpc8xxx_spi.c | 10 +- drivers/spi/mscc_bb_spi.c | 4 +- drivers/spi/mxc_spi.c | 6 +- drivers/spi/npcm_fiu_spi.c | 14 +- drivers/spi/nxp_fspi.c | 2 +- drivers/spi/octeon_spi.c | 2 +- drivers/spi/omap3_spi.c | 4 +- drivers/spi/pic32_spi.c | 2 +- drivers/spi/rk_spi.c | 4 +- drivers/spi/rockchip_sfc.c | 2 +- drivers/spi/spi-aspeed-smc.c | 28 +-- drivers/spi/spi-mxic.c | 6 +- drivers/spi/spi-qup.c | 4 +- drivers/spi/spi-sifive.c | 6 +- drivers/spi/spi-sn-f-ospi.c | 2 +- drivers/spi/spi-sunxi.c | 6 +- drivers/spi/spi-synquacer.c | 4 +- drivers/spi/spi-uclass.c | 34 ++- drivers/spi/stm32_qspi.c | 2 +- drivers/spi/stm32_spi.c | 4 +- drivers/spi/ti_qspi.c | 14 +- drivers/spi/xilinx_spi.c | 6 +- drivers/spi/zynq_qspi.c | 119 ++++++++-- drivers/spi/zynq_spi.c | 6 +- drivers/spi/zynqmp_gqspi.c | 141 ++++++++++-- include/linux/mtd/spi-nor.h | 12 + include/spi.h | 23 +- lib/acpi/acpi_device.c | 2 +- 46 files changed, 792 insertions(+), 228 deletions(-) -- 2.17.1

5 15

[PATCH] mtd: spi-nor-ids: Add Puya Semiconductor chips description
by Dmitry Dunaev 24 May '24

24 May '24

Added support for the Puya Semiconductor chips. The datasheet can be found here: https://www.puyasemi.com/h_xilie715.html Signed-off-by: Dmitry Dunaev <dunaev(a)tecon.ru> --- drivers/mtd/spi/Kconfig | 5 +++++ drivers/mtd/spi/spi-nor-ids.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index d068b7860e..407c8fc304 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -176,6 +176,11 @@ config SPI_FLASH_MACRONIX help Add support for various Macronix SPI flash chips (MX25Lxxx) +config SPI_FLASH_PUYA + bool "Puya Semiconductor SPI flash support" + help + Add support for various Puya Semiconductor SPI flash chips (P25xxx) + config SPI_FLASH_SILICONKAISER bool "Silicon Kaiser SPI flash support" help diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index 4e83b8c94c..92c2d5e2a5 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -294,6 +294,36 @@ const struct flash_info spi_nor_ids[] = { { INFO("mx25uw6445g", 0xc28137, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, { INFO("mx25uw6345g", 0xc28437, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, #endif +#ifdef CONFIG_SPI_FLASH_PUYA + /* Puya Semiconductor (Shanghai) Co., Ltd */ + { INFO + ("p25q05h", 0x856010, 0, 64 * 1024, 1, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q10h", 0x856011, 0, 64 * 1024, 2, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q20h", 0x856012, 0, 64 * 1024, 4, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q40h", 0x856013, 0, 64 * 1024, 8, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q80h", 0x856014, 0, 64 * 1024, 16, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q16h", 0x856015, 0, 64 * 1024, 32, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q32h", 0x856016, 0, 64 * 1024, 64, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q64h", 0x856017, 0, 64 * 1024, 128, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO + ("p25q128h", 0x856018, 0, 64 * 1024, 256, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, +#endif #ifdef CONFIG_SPI_FLASH_SILICONKAISER { INFO("sk25lp128", 0x257018, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, -- 2.34.1

2 2

[PATCH v1] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
by Arseniy Krasnov 24 May '24

24 May '24

Support for OTP area access on MX30LFxG18AC chip series. Signed-off-by: Arseniy Krasnov <avkrasnov(a)salutedevices.com> --- drivers/mtd/nand/raw/nand_macronix.c | 170 +++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) diff --git a/drivers/mtd/nand/raw/nand_macronix.c b/drivers/mtd/nand/raw/nand_macronix.c index dc972e5909..4c6ddd9233 100644 --- a/drivers/mtd/nand/raw/nand_macronix.c +++ b/drivers/mtd/nand/raw/nand_macronix.c @@ -16,13 +16,183 @@ * GNU General Public License for more details. */ +#include <dm/device_compat.h> #include <linux/mtd/rawnand.h> +#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90 +#define MACRONIX_30LFXG18AC_OTP_START_PAGE 2 +#define MACRONIX_30LFXG18AC_OTP_PAGES 30 +#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE 2112 +#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES \ + (MACRONIX_30LFXG18AC_OTP_PAGES * \ + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE) + +#define MACRONIX_30LFXG18AC_OTP_EN BIT(0) + +static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd, size_t len, + size_t *retlen, + struct otp_info *buf) +{ + if (len < sizeof(*buf)) + return -EINVAL; + + /* Always report that OTP is unlocked. Reason is that this + * type of flash chip doesn't provide way to check that OTP + * is locked or not: subfeature parameter is implemented as + * volatile register. Technically OTP region could be locked + * and become readonly, but as there is no way to check it, + * don't allow to lock it ('_lock_user_prot_reg' callback + * always returns -EOPNOTSUPP) and thus we report that OTP + * is unlocked. + */ + buf->locked = 0; + buf->start = 0; + buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES; + + *retlen = sizeof(*buf); + + return 0; +} + +static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand) +{ + u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 }; + struct mtd_info *mtd; + + mtd = nand_to_mtd(nand); + feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN; + + return nand->onfi_set_features(mtd, nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP, feature_buf); +} + +static int macronix_30lfxg18ac_otp_disable(struct nand_chip *nand) +{ + u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 }; + struct mtd_info *mtd; + + mtd = nand_to_mtd(nand); + return nand->onfi_set_features(mtd, nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP, feature_buf); +} + +static int __macronix_30lfxg18ac_rw_otp(struct mtd_info *mtd, + loff_t offs_in_flash, + size_t len, size_t *retlen, + u_char *buf, bool write) +{ + struct nand_chip *nand; + size_t bytes_handled; + off_t offs_in_page; + u64 page; + int ret; + + nand = mtd_to_nand(mtd); + nand->select_chip(mtd, 0); + + ret = macronix_30lfxg18ac_otp_enable(nand); + if (ret) + goto out_otp; + + page = offs_in_flash; + /* 'page' will be result of division. */ + offs_in_page = do_div(page, MACRONIX_30LFXG18AC_OTP_PAGE_SIZE); + bytes_handled = 0; + + while (bytes_handled < len && + page < MACRONIX_30LFXG18AC_OTP_PAGES) { + size_t bytes_to_handle; + u64 phys_page = page + MACRONIX_30LFXG18AC_OTP_START_PAGE; + + bytes_to_handle = min_t(size_t, len - bytes_handled, + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE - + offs_in_page); + + if (write) + ret = nand_prog_page_op(nand, phys_page, offs_in_page, + &buf[bytes_handled], bytes_to_handle); + else + ret = nand_read_page_op(nand, phys_page, offs_in_page, + &buf[bytes_handled], bytes_to_handle); + if (ret) + goto out_otp; + + bytes_handled += bytes_to_handle; + offs_in_page = 0; + page++; + } + + *retlen = bytes_handled; + +out_otp: + if (ret) + dev_err(mtd->dev, "failed to perform OTP IO: %i\n", ret); + + ret = macronix_30lfxg18ac_otp_disable(nand); + if (ret) + dev_err(mtd->dev, "failed to leave OTP mode after %s\n", + write ? "write" : "read"); + + nand->select_chip(mtd, -1); + + return ret; +} + +static int macronix_30lfxg18ac_write_otp(struct mtd_info *mtd, loff_t to, + size_t len, size_t *rlen, + u_char *buf) +{ + return __macronix_30lfxg18ac_rw_otp(mtd, to, len, rlen, (u_char *)buf, + true); +} + +static int macronix_30lfxg18ac_read_otp(struct mtd_info *mtd, loff_t from, + size_t len, size_t *rlen, + u_char *buf) +{ + return __macronix_30lfxg18ac_rw_otp(mtd, from, len, rlen, buf, false); +} + +static int macronix_30lfxg18ac_lock_otp(struct mtd_info *mtd, loff_t from, + size_t len) +{ + /* See comment in 'macronix_30lfxg18ac_get_otp_info()'. */ + return -EOPNOTSUPP; +} + +static void macronix_nand_setup_otp(struct nand_chip *chip) +{ + static const char * const supported_otp_models[] = { + "MX30LF1G18AC", + "MX30LF2G18AC", + "MX30LF4G18AC", + }; + int i; + + if (!chip->onfi_version || + !(le16_to_cpu(chip->onfi_params.opt_cmd) + & ONFI_OPT_CMD_SET_GET_FEATURES)) + return; + + for (i = 0; i < ARRAY_SIZE(supported_otp_models); i++) { + if (!strcmp(chip->onfi_params.model, supported_otp_models[i])) { + struct mtd_info *mtd; + + mtd = nand_to_mtd(chip); + mtd->_get_user_prot_info = macronix_30lfxg18ac_get_otp_info; + mtd->_read_user_prot_reg = macronix_30lfxg18ac_read_otp; + mtd->_write_user_prot_reg = macronix_30lfxg18ac_write_otp; + mtd->_lock_user_prot_reg = macronix_30lfxg18ac_lock_otp; + return; + } + } +} + static int macronix_nand_init(struct nand_chip *chip) { if (nand_is_slc(chip)) chip->bbt_options |= NAND_BBT_SCAN2NDPAGE; + macronix_nand_setup_otp(chip); + return 0; } -- 2.35.0

3 12

[PATCH RFC 0/4] efi: CapsuleUpdate: support for dynamic GUIDs
by Caleb Connolly 24 May '24

24 May '24

As more boards adopt support for the EFI CapsuleUpdate mechanism, there is a growing issue of being able to target updates to them properly. The current mechanism of hardcoding UUIDs for each board at compile time is unsustainable, and maintaining lists of GUIDs is similarly cumbersome. In this series, I propose that we adopt v5 GUIDs, these are generated by using a well-known salt GUID as well as board specific information (like the model/revision), these are hashed together and the result is truncated to form a new UUID. The well-known salt GUID can be specific to the architecture (SoC vendor), or OEM. Exact rules on how these are used (e.g. if vendors should be told to generate their own for their products, and if that can be added upstream, etc) will need to be decided. Specifically, the following fields are used to generate a GUID for a particular fw_image: * namespace salt * soc name * board model (usually from dt root model property) * board compatible (usually the first entry in the dt root compatible array). * fw_image name (the string identifying the specific image, especially relevant for board that can update multiple images). Once generated, the GUIDs can be printed with the "%pUs" format string, these can then be stored externally to U-Boot. The SoC name field might be controversial, it could be generated from the last entry in the dt root compatible in most cases, or in some board specific way. It might make sense to remove this field if it is unfeasible for some boards. == Usage == Boards can integrate dynamic UUID support as follows: 1. Adjust Kconfig to depend on EFI_CAPSULE_DYNAMIC_UUIDS if EFI_HAVE_CAPSULE_SUPPORT 2. Skip setting the fw_images image_type_id property. 3. In board_init() (or anywhere before the EFI subsystem is initialised), add a call to efi_capsule_update_info_gen_ids() with the board specific info. == Limitations == * Changing GUIDs The primary limitation with this approach is that if any of the source fields change, so will the GUID for the board. It is therefore pretty important to ensure that GUID changes are caught during development. * Supporting multiple boards with a single image This now requires having an entry with the GUID for every board which might lead to larger UpdateCapsule images. == Tooling == Not part of this RFC is a tool to generate the GUIDs outside of U-Boot. I suspect this might be a requirement, but it makes sense to decide on what fields we use first. The tool should take in the salt, DTB, and a list of fw_image names. It could also accept values to overwrite the individual fields if they aren't derived from the DTB for some reason. It would then generate the expected GUID. A potential idea here would be to integrate this into the build system so that it prints a warning if the GUID changes. == TOOD == Missing from this RFC are unit tests for the dynamic UUID feature, these will be implemented for future revisions. I would appreciate any feedback on the above. This follows a related discussion started by Ilias: https://lore.kernel.org/u-boot/CAC_iWjJNHa4gMF897MqYZNdbgjFG8K4kwGsTXWuy72W… --- Caleb Connolly (4): lib: uuid: add UUID v5 support efi: add a helper to generate dynamic UUIDs doc: uefi: document dynamic GUID generation sandbox: switch to dynamic UUIDs arch/Kconfig | 1 + board/sandbox/sandbox.c | 28 +++++++++++++++------------- doc/develop/uefi/uefi.rst | 35 +++++++++++++++++++++++++++++++++++ include/efi_loader.h | 28 ++++++++++++++++++++++++++++ include/uuid.h | 16 ++++++++++++++++ lib/Kconfig | 8 ++++++++ lib/efi_loader/Kconfig | 14 ++++++++++++++ lib/efi_loader/efi_capsule.c | 33 +++++++++++++++++++++++++++++++++ lib/uuid.c | 33 +++++++++++++++++++++++++++++++++ 9 files changed, 183 insertions(+), 13 deletions(-) --- change-id: 20240422-b4-dynamic-uuid-1a5ab1486c27 base-commit: d097f9e1299a3bdb7de468f0d9bbc63932f461cd // Caleb (they/them)

2 13

[PATCH v2 0/6] Introduce UBI block device
by Alexey Romanov 24 May '24

24 May '24

Hello! This series adds support for the UBI block device, which allows to read/write data block by block. For example, it can now be used for BCB or Android AB command: $ bcb load ubi 0 part_name Tested only on SPI NAND, so bind is made only for SPI NAND drivers. Can be used with mtdblock device [1]. --- Changes V1 -> V2 [2]: - Rebased over mtdblock v2 patchset [3]. - Compile UBI partitions support only if CONFIG_BLK option is enabled. - Links: [1] https://lore.kernel.org/all/20240227100441.1811047-1-avromanov@salutedevice… [2] https://lore.kernel.org/all/20240306134906.1179285-1-avromanov@salutedevice… [3] https://lore.kernel.org/all/20240307130726.1582487-1-avromanov@salutedevice… Alexey Romanov (6): ubi: allow to read from volume with offset ubi: allow to write to volume with offset drivers: introduce UBI block abstraction disk: don't try search for partition type if already set disk: support UBI partitions spinand: bind UBI block cmd/ubi.c | 77 +++++++++++++++++++-- disk/part.c | 7 ++ drivers/block/blk-uclass.c | 1 + drivers/mtd/nand/spi/core.c | 8 ++- drivers/mtd/ubi/Makefile | 1 + drivers/mtd/ubi/block.c | 130 ++++++++++++++++++++++++++++++++++++ drivers/mtd/ubi/part.c | 99 +++++++++++++++++++++++++++ env/ubi.c | 16 ++--- include/part.h | 2 + include/ubi_uboot.h | 8 ++- 10 files changed, 332 insertions(+), 17 deletions(-) create mode 100644 drivers/mtd/ubi/block.c create mode 100644 drivers/mtd/ubi/part.c -- 2.34.1

6 19

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

24 May '24

Add binman nodes for EFI capsules of firmware components so that capsules are automatically created during the UBoot builds. This is enabled for several TI SoC based platforms: AM64, AM62, AM62p, BeaglePlay, J7, and BeagleboneAI. Changes from v1: - on GP devices, still use signed images in capsules where available - Insert board specific capsule GUIDs into the capsule node's image-guid. Jonathan Humphreys (7): dts: ti: binman: Add base K3 firmware capsule nodes dts: am64x: binman: Include firmware capsules binman nodes dts: j721e: binman: Include firmware capsules binman nodes dts: beagleplay: binman: Include firmware capsules binman nodes dts: am62px: binman: Include firmware capsules binman nodes dts: am62x: binman: Include firmware capsules binman nodes dts: beagleboneai64: binman: Include firmware capsules binman nodes arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 27 ++++++++++ arch/arm/dts/k3-am625-r5-beagleplay.dts | 15 ++++++ arch/arm/dts/k3-am625-sk-binman.dtsi | 30 ++++++++++++ arch/arm/dts/k3-am62p-sk-binman.dtsi | 29 +++++++++++ arch/arm/dts/k3-am64x-binman.dtsi | 30 ++++++++++++ arch/arm/dts/k3-binman-capsule-r5.dtsi | 21 ++++++++ arch/arm/dts/k3-binman-capsule.dtsi | 38 ++++++++++++++ .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 23 +++++++++ arch/arm/dts/k3-j721e-binman.dtsi | 49 +++++++++++++++++++ arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 29 +++++++++++ 10 files changed, 291 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 14

[PATCH v2 00/10] Add support for Ethernet Boot on SK-AM62
by Chintan Vankar 22 May '24

22 May '24

This series enables Ethernet Boot on SK-AM62 device. Link to v1: https://lore.kernel.org/all/20240112064759.1801600-1-s-vadapalli@ti.com/ Changes from v1 to v2: - Updated dram_init_banksize() function to be called from common section instead of board specific function call as suggested by Tom. - Dropped [PATCH 06/10] from this version since it was a clean up patch and not required for AM62x Ethernet Boot functionality. - Removed independent defconfig files for R5 and A53 configs and created a config fragment for them as suggested by Nishanth. - Added new patch [PATCH v2 10/10] in this series to enable CPSW MAC's PHY node "phy_gmii_sel" which is required for Ethernet Boot. This changes are done as per discussion here: https://lore.kernel.org/r/20240112064759.1801600-1-s-vadapalli@ti.com/ Logs: https://gist.github.com/chintanv133/07bcb1473301581aab6d4e951d9c6572 Chintan Vankar (2): common: spl: spl: Init DRAM size in R5/A53 SPL arch: arm: dts: k3-am62-sk-u-boot: Add missing "bootph-all" property to phy_gmii_sel node Kishon Vijay Abraham I (6): firmware: ti_sci: Add No-OP for "RX_FL_CFG" soc: ti: k3-navss-ringacc: Initialize base address of ring cfg registers dma: ti: k3-udma: Add support for native configuration of chan/flow arm: mach-k3: am625_init: Probe AM65 CPSW NUSS configs: am62: Add configs for enabling ETHBOOT in R5SPL configs: am62: Enable configs required for Ethboot Siddharth Vadapalli (1): arm: dts: k3-am625-r5-sk: Enable DM services for main_pktdma Vignesh Raghavendra (1): soc: ti: k3-navss-ringacc: Fix reset ring API arch/arm/dts/k3-am625-r5-sk.dts | 5 +++++ arch/arm/dts/k3-am625-sk-u-boot.dtsi | 4 ++++ arch/arm/mach-k3/am625_init.c | 10 ++++++++++ common/spl/spl.c | 2 +- configs/am62x_evm_a53_ethboot_defconfig | 11 +++++++++++ configs/am62x_evm_r5_ethboot_defconfig | 19 +++++++++++++++++++ drivers/dma/ti/k3-udma.c | 6 ++++++ drivers/firmware/ti_sci.c | 8 +++++++- drivers/soc/ti/k3-navss-ringacc-u-boot.c | 9 ++++++++- drivers/soc/ti/k3-navss-ringacc.c | 7 ++++++- 10 files changed, 77 insertions(+), 4 deletions(-) create mode 100644 configs/am62x_evm_a53_ethboot_defconfig create mode 100644 configs/am62x_evm_r5_ethboot_defconfig -- 2.34.1

2 20

[RFC 00/14] efi_loader: improve device-tree loading
by Heinrich Schuchardt 22 May '24

22 May '24

In U-Boot EFI boot options can already specify both an EFI binary and an initrd. With this series we can additionally define the matching device-tree to be loaded in the boot option. With the last patch the boot manager will fall back the device-tree specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' on the boot device if no device-tree is specified in the boot option or via a bootefi command parameter. Heinrich Schuchardt (14): efi_loader: pass GUID by address to efi_dp_from_lo efi_loader: library function efi_dp_merge efi_loader: simplify efi_dp_concat() cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: superfluous efi_restore_gd after EFI_CALL cmd: terminate efidebug test bootmgr early on error efi_loader: improve error handling in try_load_entry() efi_loader: do not install dtb if bootmgr fails efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr boot/bootmeth_efi.c | 60 +----- cmd/bootefi.c | 1 - cmd/eficonfig.c | 90 +++++++-- cmd/efidebug.c | 89 +++++++-- include/efi_loader.h | 15 +- lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 186 +++++++++++++----- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 77 +++++--- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 +++++++++++ lib/efi_loader/efi_helper.c | 6 +- lib/efi_loader/efi_load_initrd.c | 2 +- test/py/tests/test_efi_secboot/test_signed.py | 28 +-- .../test_efi_secboot/test_signed_intca.py | 10 +- .../tests/test_efi_secboot/test_unsigned.py | 6 +- 17 files changed, 489 insertions(+), 206 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c -- 2.43.0

5 35

[PATCH 0/2] Add AM64x Support to PRUSS and PRU_RPROC driver
by MD Danish Anwar 22 May '24

22 May '24

This series adds AM64x related compatibles to PRUSS and PRU_RPROC drivers. This series is a prerequisite for ICSSG Ethernet driver. Once Support for AM64x is added to PRUSS and PRU_RPROC driver, I'll send another series to enable ICSSG Ethernet driver for AM64x as well. MD Danish Anwar (2): remoteproc: pru: Add support for AM64x PRU / RTU cores soc: ti: pruss: Add support for AM64x drivers/remoteproc/pru_rproc.c | 9 +++++++-- drivers/soc/ti/pruss.c | 1 + 2 files changed, 8 insertions(+), 2 deletions(-) base-commit: ff0de1f0557ed7d2dab47ba976a37347a1fdc432 -- 2.34.1

3 8