November 2022 - U-Boot

[PATCH] xilinx: Add option to select SC id instead of DUT id for SC support
by Michal Simek 28 Nov '22

28 Nov '22

Reading MAC address from on board EEPROM requires different type for System Controller (SC). Signed-off-by: Michal Simek <michal.simek(a)amd.com> --- board/xilinx/Kconfig | 9 +++++++++ board/xilinx/common/fru.h | 1 + board/xilinx/common/fru_ops.c | 6 +++++- 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig index 4ea78418780c..4f0776e8bd95 100644 --- a/board/xilinx/Kconfig +++ b/board/xilinx/Kconfig @@ -65,3 +65,12 @@ config CMD_FRU information present in the device. The FRU Information is used to primarily to provide "inventory" information about the boards that the FRU Information Device is located on. + +config FRU_SC + bool "FRU system controller decoding" + help + Xilinx System Controller (SC) FRU format is describing boards from two + angles. One from DUT and then from SC. DUT is default option for + the main CPU. SC behaves more or less as slave and have different ID. + If you build U-Boot for SC you should enable this option to get proper + MAC address. diff --git a/board/xilinx/common/fru.h b/board/xilinx/common/fru.h index 59f6b722cf12..586c41b66ef7 100644 --- a/board/xilinx/common/fru.h +++ b/board/xilinx/common/fru.h @@ -90,6 +90,7 @@ struct fru_table { #define FRU_MULTIREC_MAC_OFFSET 4 #define FRU_LAST_REC BIT(7) #define FRU_DUT_MACID 0x31 +#define FRU_SC_MACID 0x11 /* This should be minimum of fields */ #define FRU_BOARD_AREA_TOTAL_FIELDS 5 diff --git a/board/xilinx/common/fru_ops.c b/board/xilinx/common/fru_ops.c index 49846ae3d660..c4f009affc5e 100644 --- a/board/xilinx/common/fru_ops.c +++ b/board/xilinx/common/fru_ops.c @@ -239,8 +239,12 @@ static int fru_parse_multirec(unsigned long addr) if (mrc.rec_type == FRU_MULTIREC_TYPE_OEM) { struct fru_multirec_mac *mac = (void *)addr + hdr_len; + u32 type = FRU_DUT_MACID; - if (mac->ver == FRU_DUT_MACID) { + if (CONFIG_IS_ENABLED(FRU_SC)) + type = FRU_SC_MACID; + + if (mac->ver == type) { mac_len = mrc.len - FRU_MULTIREC_MAC_OFFSET; memcpy(&fru_data.mac.macid, mac->macid, mac_len); } -- 2.36.1

2 1

[PATCH] xilinx: Remove unused ZYNQ_MAC_IN_EEPROM/ZYNQ_GEM_I2C_MAC_OFFSET entries
by Michal Simek 28 Nov '22

28 Nov '22

The commit ba74bcf3e07b ("xilinx: common: Remove zynq_board_read_rom_ethaddr()") removed zynq_board_read_rom_ethaddr() because xlnx,eeprom link via DT chosen node is no longer used. But forget to remove Kconfig entries which are used by this code only. Signed-off-by: Michal Simek <michal.simek(a)amd.com> --- board/xilinx/Kconfig | 17 ----------------- ...azedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 2 -- configs/syzygy_hub_defconfig | 2 -- configs/xilinx_zynqmp_virt_defconfig | 2 -- 4 files changed, 23 deletions(-) diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig index 746a2332ad5f..4ea78418780c 100644 --- a/board/xilinx/Kconfig +++ b/board/xilinx/Kconfig @@ -58,23 +58,6 @@ config BOOT_SCRIPT_OFFSET help Specifies distro boot script offset in NAND/QSPI/NOR flash. -config ZYNQ_MAC_IN_EEPROM - bool "Reading MAC address from EEPROM" - help - Enable this option if your MAC address is saved in eeprom and - xlnx,eeprom DT property in chosen node points to it. - -if ZYNQ_MAC_IN_EEPROM - -config ZYNQ_GEM_I2C_MAC_OFFSET - hex "Set the I2C MAC offset" - default 0x0 - depends on DM_I2C - help - Set the MAC offset for i2C. - -endif - config CMD_FRU bool "FRU information for product" help diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig index 943b4da21d13..ce07f1633e04 100644 --- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig +++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig @@ -8,8 +8,6 @@ CONFIG_DEFAULT_DEVICE_TREE="avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0" CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y -CONFIG_ZYNQ_MAC_IN_EEPROM=y -CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xfa CONFIG_ZYNQMP_PSU_INIT_ENABLED=y CONFIG_SYS_LOAD_ADDR=0x8000000 CONFIG_DEBUG_UART=y diff --git a/configs/syzygy_hub_defconfig b/configs/syzygy_hub_defconfig index acce95ec026c..179cb5221250 100644 --- a/configs/syzygy_hub_defconfig +++ b/configs/syzygy_hub_defconfig @@ -9,8 +9,6 @@ CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="zynq-syzygy-hub" CONFIG_SPL_STACK_R_ADDR=0x200000 CONFIG_SPL=y -CONFIG_ZYNQ_MAC_IN_EEPROM=y -CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xFA CONFIG_SYS_LOAD_ADDR=0x0 CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 9696e418daf5..4732c39bdbe1 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -13,8 +13,6 @@ CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x1E80000 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y -CONFIG_ZYNQ_MAC_IN_EEPROM=y -CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x20 CONFIG_CMD_FRU=y CONFIG_ZYNQMP_USB=y CONFIG_SYS_LOAD_ADDR=0x8000000 -- 2.36.1

2 1

[PATCH] spi: zynqmp_qspi: Add support for 64-bit read/write
by Venkatesh Yadav Abbarapu 28 Nov '22

28 Nov '22

When we pass the 64-bit address to read/write, only lower 32-bit address is getting updated. Program the upper 32-bit address in the DMA destination memory address MSBs register, which can handle upto 44-bit destination address. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu(a)amd.com> --- drivers/spi/zynqmp_gqspi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c index 48eff777df..10f6b85cd3 100644 --- a/drivers/spi/zynqmp_gqspi.c +++ b/drivers/spi/zynqmp_gqspi.c @@ -662,7 +662,7 @@ static int zynqmp_qspi_start_io(struct zynqmp_qspi_priv *priv, static int zynqmp_qspi_start_dma(struct zynqmp_qspi_priv *priv, u32 gen_fifo_cmd, u32 *buf) { - u32 addr; + unsigned long addr; u32 size; u32 actuallen = priv->len; u32 totallen = priv->len; @@ -678,7 +678,9 @@ static int zynqmp_qspi_start_dma(struct zynqmp_qspi_priv *priv, totallen -= priv->len; /* Save remaining bytes length to read */ actuallen = priv->len; /* Actual number of bytes reading */ - writel((unsigned long)buf, &dma_regs->dmadst); + writel(lower_32_bits((unsigned long)buf), &dma_regs->dmadst); + writel(upper_32_bits((unsigned long)buf) & GENMASK(11, 0), + &dma_regs->dmadstmsb); writel(roundup(priv->len, GQSPI_DMA_ALIGN), &dma_regs->dmasize); writel(GQSPI_DMA_DST_I_STS_MASK, &dma_regs->dmaier); addr = (unsigned long)buf; -- 2.17.1

2 1

[PATCH] arm64: versal: Enable REMAKE_ELF for mini_ospi/mini_qspi
by Venkatesh Yadav Abbarapu 28 Nov '22

28 Nov '22

Enable the config REMAKE_ELF in xilinx_versal_mini_ospi_defconfig and xilinx_versal_mini_qspi_defconfig which generates u-boot.elf. This commit a8c281d4b737("Convert CONFIG_REMAKE_ELF to Kconfig") misses to enable this config in these defconfigs. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu(a)amd.com> --- configs/xilinx_versal_mini_ospi_defconfig | 1 + configs/xilinx_versal_mini_qspi_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/xilinx_versal_mini_ospi_defconfig b/configs/xilinx_versal_mini_ospi_defconfig index 2c4e21028d..abcd20ba85 100644 --- a/configs/xilinx_versal_mini_ospi_defconfig +++ b/configs/xilinx_versal_mini_ospi_defconfig @@ -17,6 +17,7 @@ CONFIG_SYS_LOAD_ADDR=0x8000000 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xFFFE0000 # CONFIG_EXPERT is not set +CONFIG_REMAKE_ELF=y # CONFIG_AUTOBOOT is not set CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set diff --git a/configs/xilinx_versal_mini_qspi_defconfig b/configs/xilinx_versal_mini_qspi_defconfig index 0062f6a69f..9ca9b7e68a 100644 --- a/configs/xilinx_versal_mini_qspi_defconfig +++ b/configs/xilinx_versal_mini_qspi_defconfig @@ -15,6 +15,7 @@ CONFIG_SYS_LOAD_ADDR=0x8000000 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xFFFE0000 # CONFIG_EXPERT is not set +CONFIG_REMAKE_ELF=y # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set # CONFIG_AUTOBOOT is not set CONFIG_LOGLEVEL=0 -- 2.17.1

2 1

[PATCH v1 0/3] This series adds U-boot bootloader support for
by Manoj Sai 28 Nov '22

28 Nov '22

Patch 1/3 adds dts support for Engicam i.Core MX8M Plus SoM Patch 2/3 adds dts support for Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit Patch 3/3 adds board and configs related support for Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit Manoj Sai (3): arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus SoM arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit board: imx8mp: Add Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit arch/arm/dts/Makefile | 1 + .../imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi | 148 ++ arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2.dts | 176 ++ arch/arm/dts/imx8mp-icore-mx8mp.dtsi | 186 ++ arch/arm/mach-imx/imx8m/Kconfig | 15 + board/engicam/imx8mp/Kconfig | 15 + board/engicam/imx8mp/MAINTAINERS | 7 + board/engicam/imx8mp/Makefile | 12 + board/engicam/imx8mp/icore_mx8mp.c | 73 + board/engicam/imx8mp/imximage-lpddr4.cfg | 8 + board/engicam/imx8mp/lpddr4_timing.c | 1850 +++++++++++++++++ board/engicam/imx8mp/spl.c | 152 ++ configs/imx8mp-icore-mx8mp-edimm2.2_defconfig | 112 + include/configs/imx8mp_evk.h | 6 +- include/configs/imx8mp_icore_mx8mp.h | 64 + 15 files changed, 2821 insertions(+), 4 deletions(-) create mode 100644 arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2.dts create mode 100644 arch/arm/dts/imx8mp-icore-mx8mp.dtsi create mode 100644 board/engicam/imx8mp/Kconfig create mode 100644 board/engicam/imx8mp/MAINTAINERS create mode 100644 board/engicam/imx8mp/Makefile create mode 100644 board/engicam/imx8mp/icore_mx8mp.c create mode 100644 board/engicam/imx8mp/imximage-lpddr4.cfg create mode 100644 board/engicam/imx8mp/lpddr4_timing.c create mode 100644 board/engicam/imx8mp/spl.c create mode 100644 configs/imx8mp-icore-mx8mp-edimm2.2_defconfig create mode 100644 include/configs/imx8mp_icore_mx8mp.h -- 2.25.1

5 13

[PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments
by Rafał Miłecki 28 Nov '22

28 Nov '22

From: Rafał Miłecki <rafal(a)milecki.pl> Pass whole NVMEM cell struct and length pointer as arguments to callback functions. This allows: 1. Cells content to be modified based on more info Some cells (identified by their names) contain specific data that needs further processing. This can be e.g. MAC address stored in an ASCII format. NVMEM consumers expect MAC to be read in a binary form. More complex cells may be additionally described in DT. This change allows also accessing relevant DT nodes and reading extra info. 2. Adjusting data length If cell processing results in reformatting it, it's required to adjust length. This again applies e.g. to the MAC format change from ASCII to the byte-based. Later on we may consider more cleanups & features like: 1. Dropping "const char *id" and just using NVMEM cell name 2. Adding extra argument for cells providing multiple values Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> --- This solution conflicts with 1 part of Michael's work: [PATCH v2 00/20] nvmem: core: introduce NVMEM layouts https://lore.kernel.org/linux-arm-kernel/20220901221857.2600340-1-michael@w… Instead of: 1. Adding NVMEM cell-level post_process callback 2. Adding callback (.fixup_cell_info()) for setting callbacks 3. Dropping NVMEM device-level post_process callback I decided to refactor existing callback. Michael's work on adding #nvmem-cell-cells should be possible to easily rebase on top of those changes. This doen't add support for 1 cell providing multiple values. That needs to be added later once we sort out #nvmem-cell-cells bindings. This fixes the basic case with reformatting cells data. --- drivers/nvmem/core.c | 19 +++---------------- drivers/nvmem/imx-ocotp.c | 8 ++++---- include/linux/nvmem-provider.h | 17 ++++++++++++++--- 3 files changed, 21 insertions(+), 23 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 321d7d63e068..0bc3e26e4ca8 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -46,16 +46,6 @@ struct nvmem_device { #define to_nvmem_device(d) container_of(d, struct nvmem_device, dev) #define FLAG_COMPAT BIT(0) -struct nvmem_cell_entry { - const char *name; - int offset; - int bytes; - int bit_offset; - int nbits; - struct device_node *np; - struct nvmem_device *nvmem; - struct list_head node; -}; struct nvmem_cell { struct nvmem_cell_entry *entry; @@ -1416,24 +1406,21 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem, int rc; rc = nvmem_reg_read(nvmem, cell->offset, buf, cell->bytes); - if (rc) return rc; + if (len) + *len = cell->bytes; /* shift bits in-place */ if (cell->bit_offset || cell->nbits) nvmem_shift_read_buffer_in_place(cell, buf); if (nvmem->cell_post_process) { - rc = nvmem->cell_post_process(nvmem->priv, id, - cell->offset, buf, cell->bytes); + rc = nvmem->cell_post_process(nvmem->priv, cell, id, buf, len); if (rc) return rc; } - if (len) - *len = cell->bytes; - return 0; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 14284e866f26..d383989d48bf 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -222,8 +222,8 @@ static int imx_ocotp_read(void *context, unsigned int offset, return ret; } -static int imx_ocotp_cell_pp(void *context, const char *id, unsigned int offset, - void *data, size_t bytes) +static int imx_ocotp_cell_pp(void *context, struct nvmem_cell_entry *cell, + const char *id, void *data, size_t *len) { struct ocotp_priv *priv = context; @@ -233,8 +233,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, unsigned int offset, u8 *buf = data; int i; - for (i = 0; i < bytes/2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < cell->bytes / 2; i++) + swap(buf[i], buf[cell->bytes - i - 1]); } } diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h index 50caa117cb62..b0d2b6af9f37 100644 --- a/include/linux/nvmem-provider.h +++ b/include/linux/nvmem-provider.h @@ -14,14 +14,25 @@ #include <linux/gpio/consumer.h> struct nvmem_device; -struct nvmem_cell_info; + +struct nvmem_cell_entry { + const char *name; + int offset; + int bytes; + int bit_offset; + int nbits; + struct device_node *np; + struct nvmem_device *nvmem; + struct list_head node; +}; + typedef int (*nvmem_reg_read_t)(void *priv, unsigned int offset, void *val, size_t bytes); typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset, void *val, size_t bytes); /* used for vendor specific post processing of cell data */ -typedef int (*nvmem_cell_post_process_t)(void *priv, const char *id, unsigned int offset, - void *buf, size_t bytes); +typedef int (*nvmem_cell_post_process_t)(void *priv, struct nvmem_cell_entry *cell, const char *id, + void *buf, size_t *len); enum nvmem_type { NVMEM_TYPE_UNKNOWN = 0, -- 2.34.1

3 3

[PATCH 1/2] nvmem: core: refactor .cell_post_process() CB arguments
by Rafał Miłecki 28 Nov '22

28 Nov '22

From: Rafał Miłecki <rafal(a)milecki.pl> Pass whole NVMEM cell struct and length pointer as arguments to callback functions. This allows: 1. Cells content to be modified based on more info Some cells (identified by their names) contain specific data that needs further processing. This can be e.g. MAC address stored in an ASCII format. NVMEM consumers expect MAC to be read in a binary form. More complex cells may be additionally described in DT. This change allows also accessing relevant DT nodes and reading extra info. 2. Adjusting data length If cell processing results in reformatting it, it's required to adjust length. This again applies e.g. to the MAC format change from ASCII to the byte-based. Later on we may consider more cleanups & features like: 1. Dropping "const char *id" and just using NVMEM cell name 2. Adding extra argument for cells providing multiple values Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> --- This solution conflicts with 1 part of Michael's work: [PATCH v2 00/20] nvmem: core: introduce NVMEM layouts https://lore.kernel.org/linux-arm-kernel/20220901221857.2600340-1-michael@w… Instead of: 1. Adding NVMEM cell-level post_process callback 2. Adding callback (.fixup_cell_info()) for setting callbacks 3. Dropping NVMEM device-level post_process callback I decided to refactor existing callback. Michael's work on adding #nvmem-cell-cells should be possible to easily rebase on top of those changes. This doen't add support for 1 cell providing multiple values. That needs to be added later once we sort out #nvmem-cell-cells bindings. This fixes the basic case with reformatting cells data. --- drivers/nvmem/core.c | 19 +++---------------- drivers/nvmem/imx-ocotp.c | 8 ++++---- include/linux/nvmem-provider.h | 17 ++++++++++++++--- 3 files changed, 21 insertions(+), 23 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 321d7d63e068..0bc3e26e4ca8 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -46,16 +46,6 @@ struct nvmem_device { #define to_nvmem_device(d) container_of(d, struct nvmem_device, dev) #define FLAG_COMPAT BIT(0) -struct nvmem_cell_entry { - const char *name; - int offset; - int bytes; - int bit_offset; - int nbits; - struct device_node *np; - struct nvmem_device *nvmem; - struct list_head node; -}; struct nvmem_cell { struct nvmem_cell_entry *entry; @@ -1416,24 +1406,21 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem, int rc; rc = nvmem_reg_read(nvmem, cell->offset, buf, cell->bytes); - if (rc) return rc; + if (len) + *len = cell->bytes; /* shift bits in-place */ if (cell->bit_offset || cell->nbits) nvmem_shift_read_buffer_in_place(cell, buf); if (nvmem->cell_post_process) { - rc = nvmem->cell_post_process(nvmem->priv, id, - cell->offset, buf, cell->bytes); + rc = nvmem->cell_post_process(nvmem->priv, cell, id, buf, len); if (rc) return rc; } - if (len) - *len = cell->bytes; - return 0; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 14284e866f26..d383989d48bf 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -222,8 +222,8 @@ static int imx_ocotp_read(void *context, unsigned int offset, return ret; } -static int imx_ocotp_cell_pp(void *context, const char *id, unsigned int offset, - void *data, size_t bytes) +static int imx_ocotp_cell_pp(void *context, struct nvmem_cell_entry *cell, + const char *id, void *data, size_t *len) { struct ocotp_priv *priv = context; @@ -233,8 +233,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, unsigned int offset, u8 *buf = data; int i; - for (i = 0; i < bytes/2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < cell->bytes / 2; i++) + swap(buf[i], buf[cell->bytes - i - 1]); } } diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h index 50caa117cb62..b0d2b6af9f37 100644 --- a/include/linux/nvmem-provider.h +++ b/include/linux/nvmem-provider.h @@ -14,14 +14,25 @@ #include <linux/gpio/consumer.h> struct nvmem_device; -struct nvmem_cell_info; + +struct nvmem_cell_entry { + const char *name; + int offset; + int bytes; + int bit_offset; + int nbits; + struct device_node *np; + struct nvmem_device *nvmem; + struct list_head node; +}; + typedef int (*nvmem_reg_read_t)(void *priv, unsigned int offset, void *val, size_t bytes); typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset, void *val, size_t bytes); /* used for vendor specific post processing of cell data */ -typedef int (*nvmem_cell_post_process_t)(void *priv, const char *id, unsigned int offset, - void *buf, size_t bytes); +typedef int (*nvmem_cell_post_process_t)(void *priv, struct nvmem_cell_entry *cell, const char *id, + void *buf, size_t *len); enum nvmem_type { NVMEM_TYPE_UNKNOWN = 0, -- 2.34.1

2 3

[PATCH] EFI: update the documentation to correctly order loading SB keys
by luca.boccassi＠gmail.com 28 Nov '22

28 Nov '22

From: Luca Boccassi <bluca(a)debian.org> Loading the PK locks down the EFI variables, so it needs to be done last. Fix the order in the documentation and add a note. Signed-off-by: Luca Boccassi <bluca(a)debian.org> --- doc/develop/uefi/uefi.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index e0835beba4..68a0bb6832 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -169,12 +169,16 @@ Sign an image with one of the keys in "db" on your host Now in U-Boot install the keys on your board:: - fatload mmc 0:1 <tmpaddr> PK.auth - setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK - fatload mmc 0:1 <tmpaddr> KEK.auth - setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK fatload mmc 0:1 <tmpaddr> db.auth setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize db + fatload mmc 0:1 <tmpaddr> KEK.auth + setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK + fatload mmc 0:1 <tmpaddr> PK.auth + setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK + +Note that loading a key into PK automatically enables Secure Boot, and further +unsigned updates of secure EFI variables will no longer be allowed, so PK should +be loaded last. Set up boot parameters on your board:: -- 2.34.1

3 3

[PATCH] net: phy: micrel: Get phy node from phy-handle
by Jit Loon Lim 28 Nov '22

28 Nov '22

From: Ley Foon Tan <ley.foon.tan(a)intel.com> HSD #1509063521: Try to get phy node from "phy-handle" if can't find ethernet-phy subnode. Lastly only use Ethernet node if can't find phy node from ethernet-phy subnode and phy-handle. Signed-off-by: Ley Foon Tan <ley.foon.tan(a)intel.com> Signed-off-by: Jit Loon Lim <jit.loon.lim(a)intel.com> --- drivers/net/phy/micrel_ksz90x1.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/net/phy/micrel_ksz90x1.c b/drivers/net/phy/micrel_ksz90x1.c index e5f578201f..e33789b7f7 100644 --- a/drivers/net/phy/micrel_ksz90x1.c +++ b/drivers/net/phy/micrel_ksz90x1.c @@ -112,6 +112,7 @@ static int ksz90x1_of_config_group(struct phy_device *phydev, { struct udevice *dev = phydev->dev; struct phy_driver *drv = phydev->drv; + struct ofnode_phandle_args phandle; int val[4]; int i, changed = 0, offset, max; u16 regval = 0; @@ -128,8 +129,14 @@ static int ksz90x1_of_config_group(struct phy_device *phydev, } if (!ofnode_valid(node)) { - /* No node found, look in the Ethernet node */ - node = dev_ofnode(dev); + if (dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0, + &phandle)) { + /* No phy-handle found, look in the Ethernet node */ + node = dev_ofnode(dev); + } else { + /* phy-handle found */ + node = phandle.node; + } } for (i = 0; i < ofcfg->grpsz; i++) { -- 2.26.2

3 2

Nokia RX51 U-Boot USB support updates?
by Tom Rini 27 Nov '22

27 Nov '22

Hey all, So, the DM_USB migration deadline issue has been addressed by the series here: https://patchwork.ozlabs.org/project/uboot/list/?series=252793&state=* which splits out host and gadget support from the CONFIG_USB symbol itself. The migration deadline was for host support, and as noted, N900 is gadget only. That particular issue is resolved. But investigating that issue lead me to figure out some other problems, that I do need someone to say how will be addressed. Now that the other board removal series has been applied, and then with: https://patchwork.ozlabs.org/project/uboot/patch/20210708014348.4010-1-trin… also applied (for which the maintainer is happy to take), this brings N900 as the last and only user of the "old" musb driver (the "new" musb driver is now almost 9 years old) and also the last and only user of the usbtty driver. I suspect that moving to the "new" MUSB driver, for gadget only, and with that enabling DM_USB_GADGET should be a mechanical affair, so long as you can fit within the space constraints of the platform. I'm not immediately sure how hard it will be to update usbtty.c to modern gadget APIs. If there are size problems, then, well, we need solutions proposed (it's possible that some of the usb-uclass.c code is host-only and needs moving, but that likely won't stop gadget from needing it for gadget related information, to bring up a specific example). It's also likely that the MUSB support needs a little further clean-up for supporting building as gadget-only when there's some common code under a host-only check. What I would like is for someone to step forward and say they'll pick up this work. Is there an immediate deadline? No. I don't think that would be helpful. I'm not going to dictate how long it takes for someone to do the work, that's for the person doing the work to say how long they think it'll take. Thanks all! -- Tom

2 6