Re: [PATCH v2 3/5] efi_loader: utility function to check the variable name is "Boot####"
On Mon, Nov 28, 2022 at 09:45:07PM +0900, Masahisa Kojima wrote:
> Some commands need to enumerate the existing UEFI load
> option variable("Boot"). This commit transfers some code
> from cmd/efidebug.c to lib/efi_loder/, then exposes u16_tohex() and
> efi_varname_is_load_option() function to check whether the
> UEFI variable name is "Boot".
>
> Signed-off-by: Masahisa Kojima
> ---
> Newly created in v2
>
> cmd/efidebug.c | 23 +--
> include/efi_loader.h| 2 ++
> lib/efi_loader/efi_helper.c | 33 +
> 3 files changed, 36 insertions(+), 22 deletions(-)
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index ef239bb34b..ceb3aa5cee 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -1010,17 +1010,6 @@ static void show_efi_boot_opt(u16 *varname16)
> }
> }
>
> -static int u16_tohex(u16 c)
> -{
> - if (c >= '0' && c <= '9')
> - return c - '0';
> - if (c >= 'A' && c <= 'F')
> - return c - 'A' + 10;
> -
> - /* not hexadecimal */
> - return -1;
> -}
> -
> /**
> * show_efi_boot_dump() - dump all UEFI load options
> *
> @@ -1041,7 +1030,6 @@ static int do_efi_boot_dump(struct cmd_tbl *cmdtp, int
> flag,
> u16 *var_name16, *p;
> efi_uintn_t buf_size, size;
> efi_guid_t guid;
> - int id, i, digit;
> efi_status_t ret;
>
> if (argc > 1)
> @@ -1074,16 +1062,7 @@ static int do_efi_boot_dump(struct cmd_tbl *cmdtp, int
> flag,
> return CMD_RET_FAILURE;
> }
>
> - if (memcmp(var_name16, u"Boot", 8))
> - continue;
> -
> - for (id = 0, i = 0; i < 4; i++) {
> - digit = u16_tohex(var_name16[4 + i]);
> - if (digit < 0)
> - break;
> - id = (id << 4) + digit;
> - }
> - if (i == 4 && !var_name16[8])
> + if (efi_varname_is_load_option(var_name16, NULL))
> show_efi_boot_opt(var_name16);
> }
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0c6c95ba46..b1ded811e7 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -707,6 +707,8 @@ int algo_to_len(const char *algo);
>
> int efi_link_dev(efi_handle_t handle, struct udevice *dev);
> int efi_unlink_dev(efi_handle_t handle);
> +int u16_tohex(u16 c);
> +bool efi_varname_is_load_option(u16 *var_name16, int *index);
>
> /**
> * efi_size_in_pages() - convert size in bytes to size in pages
> diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
> index c71e87d118..8a7afcc381 100644
> --- a/lib/efi_loader/efi_helper.c
> +++ b/lib/efi_loader/efi_helper.c
> @@ -190,3 +190,36 @@ int efi_unlink_dev(efi_handle_t handle)
>
> return 0;
> }
> +
> +int u16_tohex(u16 c)
This needs static
> +{
> + if (c >= '0' && c <= '9')
> + return c - '0';
> + if (c >= 'A' && c <= 'F')
> + return c - 'A' + 10;
> +
> + /* not hexadecimal */
> + return -1;
> +}
> +
> +bool efi_varname_is_load_option(u16 *var_name16, int *index)
> +{
> + int id, i, digit;
> +
> + if (memcmp(var_name16, u"Boot", 8))
> + return false;
> +
> + for (id = 0, i = 0; i < 4; i++) {
> + digit = u16_tohex(var_name16[4 + i]);
> + if (digit < 0)
> + break;
> + id = (id << 4) + digit;
> + }
> + if (i == 4 && !var_name16[8]) {
> + if (index)
> + *index = id;
> + return true;
> + }
> +
> + return false;
> +}
> --
> 2.17.1
>
With that
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 1/5] eficonfig: fix going one directory up issue
On Mon, Nov 28, 2022 at 09:45:05PM +0900, Masahisa Kojima wrote:
> The directory name in eficonfig menu entry contains the
> '\' separator. strcmp() argument ".." is wrong and one directory
> up handling does not work correctly. strcmp() argument must
> include '\' separator.
>
> Signed-off-by: Masahisa Kojima
> ---
> No change since v1
>
> cmd/eficonfig.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> index 97d35597a2..5529edc85e 100644
> --- a/cmd/eficonfig.c
> +++ b/cmd/eficonfig.c
> @@ -488,7 +488,7 @@ static efi_status_t eficonfig_file_selected(void *data)
> if (!info)
> return EFI_INVALID_PARAMETER;
>
> - if (!strcmp(info->file_name, "..")) {
> + if (!strcmp(info->file_name, "..\\")) {
> struct eficonfig_filepath_info *iter;
> struct list_head *pos, *n;
> int is_last;
> --
> 2.17.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 2/5] eficonfig: use u16_strsize() to get u16 string buffer size
On Mon, Nov 28, 2022 at 09:45:06PM +0900, Masahisa Kojima wrote: > Use u16_strsize() to simplify the u16 string buffer > size calculation. > > Signed-off-by: Masahisa Kojima > Reviewed-by: Heinrich Schuchardt > --- > No update since v1. > > cmd/eficonfig.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c > index 5529edc85e..88d507d04c 100644 > --- a/cmd/eficonfig.c > +++ b/cmd/eficonfig.c > @@ -452,8 +452,7 @@ struct efi_device_path > *eficonfig_create_device_path(struct efi_device_path *dp_ > struct efi_device_path *dp; > struct efi_device_path_file_path *fp; > > - fp_size = sizeof(struct efi_device_path) + > - ((u16_strlen(current_path) + 1) * sizeof(u16)); > + fp_size = sizeof(struct efi_device_path) + u16_strsize(current_path); > buf = calloc(1, fp_size + sizeof(END)); > if (!buf) > return NULL; > -- > 2.17.1 > Reviewed-by: Ilias Apalodimas
Re: [PATCH v5 0/3] Add riscv semihosting support in u-boot
I have tested it both on Qemu and Ventana's internal simulator. On Tue, Nov 29, 2022 at 12:06 PM Bin Meng wrote: > Hi Kautuk, > > On Tue, Nov 29, 2022 at 2:29 PM Kautuk Consul > wrote: > > > > Hi, > > > > Can someone pick this patchset up ? > > > > It has been reviewed and there has been no comment on this in recent > days. > > > > Thanks. > > > > On Fri, Sep 23, 2022 at 12:33 PM Kautuk Consul > wrote: > >> > >> Semihosting is a mechanism that enables code running on > >> a target to communicate and use the Input/Output > >> facilities on a host computer that is running a debugger. > >> This patchset adds support for semihosting in u-boot > >> for RISCV64 targets. > >> > >> CHANGES since v4: > >> - Check arch dependencies for SEMIHOSTING as well as > SPL_SEMIHOSTING > >> config options as per Sean's comment. > >> - arch/riscv/lib/interrupts.c: Check for post and pre instructions > >> of the ebreak statement whether they are as per the RISCV > >> semihosting specification. Only then do a disable_semihosting > >> and epc += 4 and return. > >> > >> Compilation and test commands for SPL and S-mode configurations > >> = > >> > >> U-Boot S-mode on QEMU virt > >> > >> // Compilation of S-mode u-boot > >> ARCH=riscv > >> CROSS_COMPILE=riscv64-unknown-linux-gnu- > >> make qemu-riscv64_smode_defconfig > >> make > >> // Run riscv 64-bit u-boot with opensbi on qemu > >> qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > >> opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ > >> u-boot/u-boot.bin > >> > >> U-Boot SPL on QEMU virt > >> > >> // Compilation of u-boot-spl > >> ARCH=riscv > >> CROSS_COMPILE=riscv64-unknown-linux-gnu- > >> make qemu-riscv64_spl_defconfig > >> make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin > >> // Run 64-bit u-boot-spl in qemu > >> qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > >> u-boot/spl/u-boot-spl.bin -device\ > >> loader,file=u-boot/u-boot.itb,addr=0x8020 > >> > > Do you have instructions on how to actually test semihosting? Does it > require a JTAG debugger? But I see you are using QEMU? > > Regards, > Bin >
[RFC PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte
EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
whether addressing is 1-byte or 2-byte. There are currently different
behaviours seen across boards as documented in commit bf6376642fe8
("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
the list, we see that there are 2-byte EEPROMs that read properly
with 1-byte addressing with no offset.
For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
earlier commit d2ab2a2bafd5 ("board: ti: common: board_detect: Fix
EEPROM read quirk for AM6 style data") tried to resolve this by running
ti_i2c_eeprom_get() twice. However this commit along with its former
commit fails on J7 platforms where EEPROM successfully return back the
header on 1-byte addressing and continues to do so until an offset is
introduced. So the second read incorrectly determines the EEPROM as
1-byte addressing.
A more generic solution is introduced here to solve
this issue: 1-byte read without offset and 1-byte read with offset. If
both passes, it follows 1-byte addressing else we proceed with 2-byte
addressing check.
Tested on J721E, J7200, DRA7xx, AM64x
Signed-off-by: Neha Malcom Francis
Fixes: d2ab2a2bafd5 (board: ti: common: board_detect: Fix EEPROM read
quirk for AM6 style data) and bf6376642fe8 (board: ti: common: board_detect:
Fix EEPROM read quirk)
---
board/ti/common/board_detect.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index c37629fe8a..b9f2ebf2a0 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -91,6 +91,8 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int
dev_addr,
#if CONFIG_IS_ENABLED(DM_I2C)
struct udevice *dev;
struct udevice *bus;
+ uint8_t offset_test;
+ bool one_byte_addressing = true;
rc = uclass_get_device_by_seq(UCLASS_I2C, bus_addr, &bus);
if (rc)
@@ -114,8 +116,23 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
*/
(void)dm_i2c_read(dev, 0, ep, size);
+ if (*((u32 *)ep) != header)
+ one_byte_addressing = false;
+
+ /*
+* Handle case of bad 2 byte eeproms that responds to 1 byte addressing
+* but gets stuck in const addressing when read requests are performed
+* on offsets. We perform an offset test to make sure it is not a 2 byte
+* eeprom that works with 1 byte addressing but just without an offset
+*/
+
+ rc = dm_i2c_read(dev, 0x1, &offset_test, sizeof(offset_test));
+
+ if (*((u32 *)ep) != (header & 0xFF))
+ one_byte_addressing = false;
+
/* Corrupted data??? */
- if (*((u32 *)ep) != header) {
+ if (!one_byte_addressing) {
/*
* read the eeprom header using i2c again, but use only a
* 2 byte address (some newer boards need this..)
@@ -444,16 +461,6 @@ int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int
dev_addr,
if (rc)
return rc;
- /*
-* Handle case of bad 2 byte eeproms that responds to 1 byte addressing
-* but gets stuck in const addressing when read requests are performed
-* on offsets. We re-read the board ID to ensure we have sane data back
-*/
- rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC,
- sizeof(board_id), (uint8_t *)&board_id);
- if (rc)
- return rc;
-
if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) {
pr_err("%s: Invalid board ID record!\n", __func__);
return -EINVAL;
--
2.34.1
Re: [PATCH v5 0/3] Add riscv semihosting support in u-boot
Hi Kautuk, On Tue, Nov 29, 2022 at 2:29 PM Kautuk Consul wrote: > > Hi, > > Can someone pick this patchset up ? > > It has been reviewed and there has been no comment on this in recent days. > > Thanks. > > On Fri, Sep 23, 2022 at 12:33 PM Kautuk Consul > wrote: >> >> Semihosting is a mechanism that enables code running on >> a target to communicate and use the Input/Output >> facilities on a host computer that is running a debugger. >> This patchset adds support for semihosting in u-boot >> for RISCV64 targets. >> >> CHANGES since v4: >> - Check arch dependencies for SEMIHOSTING as well as SPL_SEMIHOSTING >> config options as per Sean's comment. >> - arch/riscv/lib/interrupts.c: Check for post and pre instructions >> of the ebreak statement whether they are as per the RISCV >> semihosting specification. Only then do a disable_semihosting >> and epc += 4 and return. >> >> Compilation and test commands for SPL and S-mode configurations >> = >> >> U-Boot S-mode on QEMU virt >> >> // Compilation of S-mode u-boot >> ARCH=riscv >> CROSS_COMPILE=riscv64-unknown-linux-gnu- >> make qemu-riscv64_smode_defconfig >> make >> // Run riscv 64-bit u-boot with opensbi on qemu >> qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ >> opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ >> u-boot/u-boot.bin >> >> U-Boot SPL on QEMU virt >> >> // Compilation of u-boot-spl >> ARCH=riscv >> CROSS_COMPILE=riscv64-unknown-linux-gnu- >> make qemu-riscv64_spl_defconfig >> make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin >> // Run 64-bit u-boot-spl in qemu >> qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ >> u-boot/spl/u-boot-spl.bin -device\ >> loader,file=u-boot/u-boot.itb,addr=0x8020 >> Do you have instructions on how to actually test semihosting? Does it require a JTAG debugger? But I see you are using QEMU? Regards, Bin
Re: [PATCH v5 0/3] Add riscv semihosting support in u-boot
Hi, Can someone pick this patchset up ? It has been reviewed and there has been no comment on this in recent days. Thanks. On Fri, Sep 23, 2022 at 12:33 PM Kautuk Consul wrote: > Semihosting is a mechanism that enables code running on > a target to communicate and use the Input/Output > facilities on a host computer that is running a debugger. > This patchset adds support for semihosting in u-boot > for RISCV64 targets. > > CHANGES since v4: > - Check arch dependencies for SEMIHOSTING as well as SPL_SEMIHOSTING > config options as per Sean's comment. > - arch/riscv/lib/interrupts.c: Check for post and pre instructions > of the ebreak statement whether they are as per the RISCV > semihosting specification. Only then do a disable_semihosting > and epc += 4 and return. > > Compilation and test commands for SPL and S-mode configurations > = > > U-Boot S-mode on QEMU virt > > // Compilation of S-mode u-boot > ARCH=riscv > CROSS_COMPILE=riscv64-unknown-linux-gnu- > make qemu-riscv64_smode_defconfig > make > // Run riscv 64-bit u-boot with opensbi on qemu > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ > u-boot/u-boot.bin > > U-Boot SPL on QEMU virt > > // Compilation of u-boot-spl > ARCH=riscv > CROSS_COMPILE=riscv64-unknown-linux-gnu- > make qemu-riscv64_spl_defconfig > make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin > // Run 64-bit u-boot-spl in qemu > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > u-boot/spl/u-boot-spl.bin -device\ > loader,file=u-boot/u-boot.itb,addr=0x8020 > > Kautuk Consul (3): > lib: Add common semihosting library > arch/riscv: add semihosting support for RISC-V > board: qemu-riscv: enable semihosting > > arch/arm/Kconfig | 46 --- > arch/arm/lib/semihosting.c | 181 +- > arch/riscv/include/asm/spl.h | 1 + > arch/riscv/lib/Makefile | 2 + > arch/riscv/lib/interrupts.c | 25 > arch/riscv/lib/semihosting.c | 24 > configs/qemu-riscv32_defconfig | 4 + > configs/qemu-riscv32_smode_defconfig | 4 + > configs/qemu-riscv32_spl_defconfig | 7 + > configs/qemu-riscv64_defconfig | 4 + > configs/qemu-riscv64_smode_defconfig | 4 + > configs/qemu-riscv64_spl_defconfig | 7 + > include/semihosting.h| 11 ++ > lib/Kconfig | 47 +++ > lib/Makefile | 2 + > lib/semihosting.c| 186 +++ > 16 files changed, 329 insertions(+), 226 deletions(-) > create mode 100644 arch/riscv/lib/semihosting.c > create mode 100644 lib/semihosting.c > > -- > 2.34.1 > >
Re: [PATCH V3 2/2] spi: cadence_qspi: use STIG mode for small reads
On 25/11/22 11:29, Dhruva Gole wrote:
> Fix the issue where some flash chips like cypress S25HS256T return the
> value of the same register over and over in DAC mode.
>
> For example in the TI K3-AM62x Processors refer [0] Technical Reference
> Manual there is a layer of digital logic in front of the QSPI/OSPI
> Drive when used in DAC mode. This is part of the Flash Subsystem (FSS)
> which provides access to external Flash devices. This operates by
> default in a 32 bit mode causing it to always align all data to 4 bytes
> from a 4byte aligned address. In some flash chips like cypress for
> example if we try to read some regs in DAC mode then it keeps sending the
> value of the first register that was requested and inorder to read the
> next reg, we have to stop and re-initiate a new transaction.
>
> This causes wrong registers values to be read than what is desired when
> registers are read in DAC mode. Hence if the data.nbytes is very less
> then prefer STIG mode for such small reads.
>
> [0] https://www.ti.com/lit/ug/spruiv7a/spruiv7a.pdf
>
> Signed-off-by: Dhruva Gole
> ---
> drivers/spi/cadence_qspi.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index ab0a681c8376..5506f63ef078 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -307,7 +307,13 @@ static int cadence_spi_mem_exec_op(struct spi_slave *spi,
> priv->is_decoded_cs);
>
> if (op->data.dir == SPI_MEM_DATA_IN && op->data.buf.in) {
> - if (!op->addr.nbytes)
> + /*
> + * Performing reads in DAC mode forces to read minimum 4 bytes
> + * which is unsupported on some flash devices during register
> + * reads, prefer STIG mode for such small reads.
> + */
> + if (!op->addr.nbytes ||
> + op->data.nbytes < CQSPI_STIG_DATA_LEN_MAX)
> mode = CQSPI_STIG_READ;
For the series,
Tested-by: Vaishnav Achath
Erase-Write-Read back tested on s28hs512t, mt35xu512aba, mt25qu512a on J7200 and
J721E platforms.
> else
> mode = CQSPI_READ;
--
Regards,
Vaishnav
[PATCH] spi: Add Socionext F_OSPI SPI flash controller driver
Introduce Socionext F_OSPI controller driver. This controller is used to communicate with slave devices such as SPI flash memories. It supports 4 slave devices and up to 8-bit wide bus, but supports master mode only. This driver uses spi-mem framework for SPI flash memory access, and can only operate indirect access mode and single data rate mode. Signed-off-by: Kunihiko Hayashi --- drivers/spi/Kconfig | 8 + drivers/spi/Makefile| 1 + drivers/spi/spi-sn-f-ospi.c | 686 3 files changed, 695 insertions(+) create mode 100644 drivers/spi/spi-sn-f-ospi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index c6900f449d5f..ff68ffbc0e06 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -451,6 +451,14 @@ config SOFT_SPI Enable Soft SPI driver. This driver is to use GPIO simulate the SPI protocol. +config SPI_SN_F_OSPI + tristate "Socionext F_OSPI SPI flash controller" + depends on SPI_MEM + help + This enables support for the Socionext F_OSPI controller + for connecting an SPI flash memory over up to 8-bit wide bus. + It supports indirect access mode only. + config SPI_SUNXI bool "Allwinner SoC SPI controllers" default ARCH_SUNXI diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 674d81caae3b..95dba9ac4559 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -67,6 +67,7 @@ obj-$(CONFIG_ROCKCHIP_SFC) += rockchip_sfc.o obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o obj-$(CONFIG_SPI_SIFIVE) += spi-sifive.o +obj-$(CONFIG_SPI_SN_F_OSPI) += spi-sn-f-ospi.o obj-$(CONFIG_SPI_SUNXI) += spi-sunxi.o obj-$(CONFIG_SH_QSPI) += sh_qspi.o obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o diff --git a/drivers/spi/spi-sn-f-ospi.c b/drivers/spi/spi-sn-f-ospi.c new file mode 100644 index ..ebf2903d3ea7 --- /dev/null +++ b/drivers/spi/spi-sn-f-ospi.c @@ -0,0 +1,686 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Socionext SPI flash controller F_OSPI driver + * Copyright (C) 2021 Socionext Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Registers */ +#define OSPI_PROT_CTL_INDIR0x00 +#define OSPI_PROT_MODE_DATA_MASK GENMASK(31, 30) +#define OSPI_PROT_MODE_ALT_MASK GENMASK(29, 28) +#define OSPI_PROT_MODE_ADDR_MASK GENMASK(27, 26) +#define OSPI_PROT_MODE_CODE_MASK GENMASK(25, 24) +#define OSPI_PROT_MODE_SINGLE 0 +#define OSPI_PROT_MODE_DUAL1 +#define OSPI_PROT_MODE_QUAD2 +#define OSPI_PROT_MODE_OCTAL 3 +#define OSPI_PROT_DATA_RATE_DATA BIT(23) +#define OSPI_PROT_DATA_RATE_ALT BIT(22) +#define OSPI_PROT_DATA_RATE_ADDR BIT(21) +#define OSPI_PROT_DATA_RATE_CODE BIT(20) +#define OSPI_PROT_SDR 0 +#define OSPI_PROT_DDR 1 +#define OSPI_PROT_BIT_POS_DATA BIT(19) +#define OSPI_PROT_BIT_POS_ALTBIT(18) +#define OSPI_PROT_BIT_POS_ADDR BIT(17) +#define OSPI_PROT_BIT_POS_CODE BIT(16) +#define OSPI_PROT_SAMP_EDGE BIT(12) +#define OSPI_PROT_DATA_UNIT_MASK GENMASK(11, 10) +#define OSPI_PROT_DATA_UNIT_1B 0 +#define OSPI_PROT_DATA_UNIT_2B 1 +#define OSPI_PROT_DATA_UNIT_4B 3 +#define OSPI_PROT_TRANS_DIR_WRITEBIT(9) +#define OSPI_PROT_DATA_ENBIT(8) +#define OSPI_PROT_ALT_SIZE_MASK GENMASK(7, 5) +#define OSPI_PROT_ADDR_SIZE_MASK GENMASK(4, 2) +#define OSPI_PROT_CODE_SIZE_MASK GENMASK(1, 0) + +#define OSPI_CLK_CTL 0x10 +#define OSPI_CLK_CTL_BOOT_INT_CLK_EN BIT(16) +#define OSPI_CLK_CTL_PHA BIT(12) +#define OSPI_CLK_CTL_PHA_180 0 +#define OSPI_CLK_CTL_PHA_901 +#define OSPI_CLK_CTL_DIV GENMASK(9, 8) +#define OSPI_CLK_CTL_DIV_1 0 +#define OSPI_CLK_CTL_DIV_2 1 +#define OSPI_CLK_CTL_DIV_4 2 +#define OSPI_CLK_CTL_DIV_8 3 +#define OSPI_CLK_CTL_INT_CLK_EN BIT(0) + +#define OSPI_CS_CTL1 0x14 +#define OSPI_CS_CTL2 0x18 +#define OSPI_SSEL 0x20 +#define OSPI_CMD_IDX_INDIR 0x40 +#define OSPI_ADDR 0x50 +#define OSPI_ALT_INDIR 0x60 +#define OSPI_DMY_INDIR 0x70 +#define OSPI_DAT 0x80 +#define OSPI_DAT_SWP_INDIR 0x90 + +#define OSPI_DAT_SIZE_
Re: [PATCH] riscv: use imply instead of select for SPL_SEPARATE_BSS
On Mon, Nov 21, 2022 at 8:17 PM Zong Li wrote: > > On Mon, Nov 21, 2022 at 12:00 PM Sean Anderson wrote: > > > > On 11/16/22 02:08, Zong Li wrote: > > > Use imply instead of select, then it can still be disabled by > > > board-specific defconfig, or be set to n manually. > > > > > > Signed-off-by: Zong Li > > > --- > > > arch/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > > index ae39716697..102956d24c 100644 > > > --- a/arch/Kconfig > > > +++ b/arch/Kconfig > > > @@ -111,7 +111,7 @@ config RISCV > > > select SUPPORT_OF_CONTROL > > > select OF_CONTROL > > > select DM > > > - select SPL_SEPARATE_BSS if SPL > > > + imply SPL_SEPARATE_BSS if SPL > > > imply DM_SERIAL > > > imply DM_ETH > > > imply DM_EVENT > > > > Do you have an example of a board which does this? > > > > Hi Sean, > We'd like to disable 'SPL_SEPARATE_BSS' on our internal platforms that > don't exist in the mainline. It seems to me that using 'imply' might > be not only working on the mainline's board, but also making it > flexible to disable 'SPL_SEPARATE_BSS' by board-specific configuration > or disable it manually for debug purposes. Hope the idea is good to > you all. Thanks > Hi all, Thanks for your reviewing, could I know whether this patch makes sense to you? > > --Sean
Re: [PATCH v20 1/4] net: Add TCP protocol
Thank you all for taking this over the finish line. I Duncan Hare 714 931 7952DRE# 01350926 On Monday, November 28, 2022 at 11:52:23 AM PST, Tom Rini wrote: On Tue, Nov 08, 2022 at 02:17:28PM +0800, Ying-Chun Liu (PaulLiu) wrote: > From: "Ying-Chun Liu (PaulLiu)" > > Currently file transfers are done using tftp or NFS both > over udp. This requires a request to be sent from client > (u-boot) to the boot server. > > The current standard is TCP with selective acknowledgment. > > Signed-off-by: Duncan Hare > Signed-off-by: Duncan Hare > Signed-off-by: Ying-Chun Liu (PaulLiu) > Reviewed-by: Simon Glass > Cc: Christian Gmeiner > Cc: Joe Hershberger > Cc: Michal Simek > Cc: Ramon Fried > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v20 1/4] net: Add TCP protocol
On 28.11.2022 20:52, Tom Rini wrote: On Tue, Nov 08, 2022 at 02:17:28PM +0800, Ying-Chun Liu (PaulLiu) wrote: From: "Ying-Chun Liu (PaulLiu)" Currently file transfers are done using tftp or NFS both over udp. This requires a request to be sent from client (u-boot) to the boot server. The current standard is TCP with selective acknowledgment. Signed-off-by: Duncan Hare Signed-off-by: Duncan Hare Signed-off-by: Ying-Chun Liu (PaulLiu) Reviewed-by: Simon Glass Cc: Christian Gmeiner Cc: Joe Hershberger Cc: Michal Simek Cc: Ramon Fried Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! Thanks for your work on this feature and congratulations on getting it through the review process! It's really nice to see official TCP support.
Re: [PATCH] phy: add driver for Intel XWAY PHY
On Thu, Nov 17, 2022 at 01:27:09PM -0800, Tim Harvey wrote: > Add a driver for the Intel XWAY GbE PHY: > - configure RGMII using dt phy-mode and standard delay properties > - use genphy_config > > Signed-off-by: Tim Harvey Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: macb: Fix race caused by flushing unwanted descriptors
On Thu, Nov 10, 2022 at 07:31:34PM +0200, Yaron Micher wrote: > The rx descriptor list is in cached memory, and there may be multiple > descriptors per cache-line. After reclaim_rx_buffers marks a descriptor > as unused it does a cache flush, which causes the entire cache-line to > be written to memory, which may override other descriptors in the same > cache-line that the controller may have written to. > > The fix skips freeing descriptors that are not the last in a cache-line, > and if the freed descriptor is the last one in a cache-line, it marks > all the descriptors in the cache-line as unused. > This is similarly to what is done in drivers/net/fec_mxc.c > > In my case this bug caused tftpboot to fail some times when other > packets are sent to u-boot in addition to the ongoing tftp (e.g. ping). > The driver would stop receiving new packets because it is waiting > on a descriptor that is marked unused, when in reality the descriptor > contains a new unprocessed packet but while freeing the previous buffer > descriptor & flushing the cache, the driver accidentally marked the > descriptor as unused. > > Signed-off-by: Yaron Micher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v20 4/4] test: cmd: add test for wget command.
On Tue, Nov 08, 2022 at 02:17:31PM +0800, Ying-Chun Liu (PaulLiu) wrote: > From: "Ying-Chun Liu (PaulLiu)" > > Simulate a TCP HTTP server's response for testing wget command. > > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Christian Gmeiner > Cc: Joe Hershberger > Cc: Michal Simek > Cc: Ramon Fried > Cc: Simon Glass > Reviewed-by: Simon Glass > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v20 3/4] doc: cmd: wget: add documentation
On Tue, Nov 08, 2022 at 02:17:30PM +0800, Ying-Chun Liu (PaulLiu) wrote: > From: "Ying-Chun Liu (PaulLiu)" > > Add documentation for the wget command. > > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Christian Gmeiner > Cc: Joe Hershberger > Cc: Michal Simek > Cc: Ramon Fried > Cc: Simon Glass > Reviewed-by: Simon Glass > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v20 2/4] net: Add wget application
On Tue, Nov 08, 2022 at 02:17:29PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> This commit adds a simple wget command that can download files
> from http server.
>
> The command syntax is
> wget ${loadaddr}
>
> Signed-off-by: Duncan Hare
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Reviewed-by: Simon Glass
> Cc: Christian Gmeiner
> Cc: Joe Hershberger
> Cc: Michal Simek
> Cc: Ramon Fried
> Reviewed-by: Ramon Fried
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v20 1/4] net: Add TCP protocol
On Tue, Nov 08, 2022 at 02:17:28PM +0800, Ying-Chun Liu (PaulLiu) wrote: > From: "Ying-Chun Liu (PaulLiu)" > > Currently file transfers are done using tftp or NFS both > over udp. This requires a request to be sent from client > (u-boot) to the boot server. > > The current standard is TCP with selective acknowledgment. > > Signed-off-by: Duncan Hare > Signed-off-by: Duncan Hare > Signed-off-by: Ying-Chun Liu (PaulLiu) > Reviewed-by: Simon Glass > Cc: Christian Gmeiner > Cc: Joe Hershberger > Cc: Michal Simek > Cc: Ramon Fried > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] drivers: net: aquantia: fix typos
On Thu, Nov 03, 2022 at 02:44:22PM -0700, Tim Harvey wrote: > Fix a couple of typos: > - s/Acquantia/Aquantia/ > - s/firmare/firmware/ > > Signed-off-by: Tim Harvey > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/6] net: deal with fragment-overlapping-two-holes case
On Mon, Oct 17, 2022 at 09:52:51AM +0200, Rasmus Villemoes wrote: > With a suitable sequence of malicious packets, it's currently possible > to get a hole descriptor to contain arbitrary attacker-controlled > contents, and then with one more packet to use that as an arbitrary > write vector. > > While one could possibly change the algorithm so we instead loop over > all holes, and in each hole puts as much of the current fragment as > belongs there (taking care to carefully update the hole list as > appropriate), it's not worth the complexity: In real, non-malicious > scenarios, one never gets overlapping fragments, and certainly not > fragments that would be supersets of one another. > > So instead opt for this simple protection: Simply don't allow the > eventual memcpy() to write beyond the last_byte of the current hole. > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 6/6] net: tftp: sanitize tftp block size, especially for TX
On Fri, Oct 14, 2022 at 07:43:42PM +0200, Rasmus Villemoes wrote: > U-Boot does not support IP fragmentation on TX (and unless > CONFIG_IP_DEFRAG is set, neither on RX). So the blocks we send must > fit in a single ethernet packet. > > Currently, if tftpblocksize is set to something like 5000 and I > tftpput a large enough file, U-Boot crashes because we overflow > net_tx_packet (which only has room for 1500 bytes plus change). > > Similarly, if tftpblocksize is set to something larger than what we > can actually receive (e.g. 5, with NET_MAXDEFRAG being 16384), any > tftp get just hangs because we never receive any packets. > > Signed-off-by: Rasmus Villemoes > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/6] net: tftp: use IS_ENABLED(CONFIG_NET_TFTP_VARS) instead of #if
On Fri, Oct 14, 2022 at 07:43:41PM +0200, Rasmus Villemoes wrote: > Nothing inside this block depends on NET_TFTP_VARS to be set to parse > correctly. Switch to C if() in preparation for adding code before > this (to avoid a declaration-after-statement warning). > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/6] net: fix ip_len in reassembled IP datagram
On Fri, Oct 14, 2022 at 07:43:40PM +0200, Rasmus Villemoes wrote: > For some reason, the ip_len field in a reassembled IP datagram is set > to just the size of the payload, but it should be set to the value it > would have had if the datagram had never been fragmented in the first > place, i.e. size of payload plus size of IP header. > > That latter value is currently returned correctly via the "len" > variable. And before entering net_defragment(), len does have the > value ntohs(ip->ip_len), so if we're not dealing with a > fragment (so net_defragment leaves *len alone), that relationship of > course also holds after the net_defragment() call. > > The only use I can find of ip->ip_len after the net_defragment call is > the ntohs(ip->udp_len) > ntohs(ip->ip_len) sanity check - none of the > functions that are passed the "ip" pointer themselves inspect ->ip_len > but instead use the passed len. > > But that sanity check is a bit odd, since the RHS really should be > "ntohs(ip->ip_len) - 20", i.e. the IP payload size. > > Now that we've fixed things so that len == ntohs(ip->ip_len) in all > cases, change that sanity check to use len-20 as the RHS. > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/6] net: (actually/better) deal with CVE-2022-{30790,30552}
On Fri, Oct 14, 2022 at 07:43:39PM +0200, Rasmus Villemoes wrote:
> I hit a strange problem with v2022.10: Sometimes my tftp transfer
> would seemingly just hang. It only happened for some files. Moreover,
> changing tftpblocksize from 65464 to 65460 or 65000 made it work again
> for all the files I tried. So I started suspecting it had something to
> do with the file sizes and in particular the way the tftp blocks get
> fragmented and reassembled.
>
> v2022.01 showed no problems with any of the files or any value of
> tftpblocksize.
>
> Looking at what had changed in net.c or tftp.c since January showed
> only one remotely interesting thing, b85d130ea0ca.
>
> So I fired up wireshark on my host to see if somehow one of the
> packets would be too small. But no, with both v2022.01 and v2022.10,
> the exact same sequence of packets were sent, all but the last of size
> 1500, and the last being 1280 bytes.
>
> But then it struck me that 1280 is 5*256, so one of the two bytes
> on-the-wire is 0 and the other is 5, and when then looking at the code
> again the lack of endianness conversion becomes obvious. [ntohs is
> both applied to ip->ip_off just above, as well as to ip->ip_len just a
> little further down when the "len" is actually computed].
>
> IOWs the current code would falsely reject any packet which happens to
> be a multiple of 256 bytes in size, breaking tftp transfers somewhat
> randomly, and if it did get one of those "malicious" packets with
> ip_len set to, say, 27, it would be seen by this check as being 6912
> and hence not rejected.
>
>
>
> Now, just adding the missing ntohs() would make my initial problem go
> away, in that I can now download the file where the last fragment ends
> up being 1280 bytes. But there's another bug in the code and/or
> analysis: The right-hand side is too strict, in that it is ok for the
> last fragment not to have a multiple of 8 bytes as payload - it really
> must be ok, because nothing in the IP spec says that IP datagrams must
> have a multiple of 8 bytes as payload. And comments in the code also
> mention this.
>
> To fix that, replace the comparison with <= IP_HDR_SIZE and add
> another check that len is actually a multiple of 8 when the "more
> fragments" bit is set - which it necessarily is for the case where
> offset8 ends up being 0, since we're only called when
>
> (ip_off & (IP_OFFS | IP_FLAGS_MFRAG)).
>
>
>
> So, does this fix CVE-2022-30790 for real? It certainly correctly
> rejects the POC code which relies on sending a packet of size 27 with
> the MFRAG flag set. Can the attack be carried out with a size 27
> packet that doesn't set MFRAG (hence must set a non-zero fragment
> offset)? I dunno. If we get a packet without MFRAG, we update
> h->last_byte in the hole we've found to be start+len, hence we'd enter
> one of
>
> if ((h >= thisfrag) && (h->last_byte <= start + len)) {
>
> or
>
> } else if (h->last_byte <= start + len) {
>
> and thus won't reach any of the
>
> /* overlaps with initial part of the hole: move this hole */
> newh = thisfrag + (len / 8);
>
> /* fragment sits in the middle: split the hole */
> newh = thisfrag + (len / 8);
>
> IOW these division are now guaranteed to be exact, and thus I think
> the scenario in CVE-2022-30790 cannot happen anymore.
>
>
>
> However, there's a big elephant in the room, which has always been
> spelled out in the comments, and which makes me believe that one can
> still cause mayhem even with packets whose payloads are all 8-byte
> aligned:
>
> This code doesn't deal with a fragment that overlaps with two
> different holes (thus being a superset of a previously-received
> fragment).
>
> Suppose each character below represents 8 bytes, with D being already
> received data, H being a hole descriptor (struct hole), h being
> non-populated chunks, and P representing where the payload of a just
> received packet should go:
>
> DDDHHhhh
> P
>
> I'm pretty sure in this case we'd end up with h being the first hole,
> enter the simple
>
> } else if (h->last_byte <= start + len) {
> /* overlaps with final part of the hole: shorten this hole */
> h->last_byte = start;
>
> case, and thus in the memcpy happily overwrite the second H with our
> chosen payload. This is probably worth fixing...
>
> Signed-off-by: Rasmus Villemoes
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/6] net: improve check for no IP options
On Fri, Oct 14, 2022 at 07:43:37PM +0200, Rasmus Villemoes wrote: > There's no reason we should accept an IP packet with a malformed IHL > field. So ensure that it is exactly 5, not just <= 5. > > Signed-off-by: Rasmus Villemoes > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/6] net: compare received length to sizeof(ip_hdr), not sizeof(ip_udp_hdr)
On Fri, Oct 14, 2022 at 07:43:38PM +0200, Rasmus Villemoes wrote: > While the code mostly/only handles UDP packets, it's possible for the > last fragment of a fragmented UDP packet to be smaller than 28 bytes; > it can be as small as 21 bytes (an IP header plus one byte of > payload). So until we've performed the defragmentation step and thus > know whether we're now holding a full packet, we should only check for > the existence of the fields in the ip header, i.e. that there are at > least 20 bytes present. > > In practice, we always seem to be handed a "len" of minimum 60 from the > device layer, i.e. minimal ethernet frame length minus FCS, so this is > mostly theoretical. > > After we've fetched the header's claimed length and used that to > update the len variable, check that the header itself claims to be the > minimal possible length. > > This is probably how CVE-2022-30552 should have been dealt with in the > first place, because net_defragment() is not the only place that wants > to know the size of the IP datagram payload: If we receive a > non-fragmented ICMP packet, we pass "len" to receive_icmp() which in > turn may pass it to ping_receive() which does > > compute_ip_checksum(icmph, len - IP_HDR_SIZE) > > and due to the signature of compute_ip_checksum(), that would then > lead to accessing ~4G of address space, very likely leading to a > crash. > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] net: dwc_eth_qos: Add support for bulk RX descriptor cleaning
On Sun, Oct 09, 2022 at 05:51:46PM +0200, Marek Vasut wrote: > Add new desc_per_cacheline property which lets a platform run RX descriptor > cleanup after every power-of-2 - 1 received packets instead of every packet. > This is useful on platforms where (axi_bus_width EQOS_AXI_WIDTH_n * DMA DSL > inter-descriptor word skip count + DMA descriptor size) is less than cache > line size, which necessitates packing multiple DMA descriptors into single > cache line. > > In case of TX descriptors, this is not a problem, since the driver always > does synchronous TX, i.e. the TX descriptor is always written, flushed and > polled for completion in eqos_send(). > > In case of RX descriptors, it is necessary to update their status in bulk, > i.e. after the entire cache line worth of RX descriptors has been used up > to receive data. > > Signed-off-by: Marek Vasut > Reviewed-by: Patrice Chotard > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] net: dwc_eth_qos: Split TX and RX DMA rings
On Sun, Oct 09, 2022 at 05:51:45PM +0200, Marek Vasut wrote: > Separate TX and RX DMA rings to make their handling slightly clearer. > This is a preparatory patch for bulk RX descriptor flushing. > > Signed-off-by: Marek Vasut > Reviewed-by: Patrice Chotard > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] liteeth: LiteX Ethernet device
On Mon, Sep 26, 2022 at 03:35:58PM +0930, Joel Stanley wrote: > LiteX is a soft system-on-chip that targets FPGAs. LiteETH is a basic > network device that is commonly used in LiteX designs. > > Signed-off-by: Joel Stanley > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] dfu: Call backend specific dfu_fill_*() only if enabled
The dfu_fill_*() functions are available only if the matching backend is
enabled. Add missing CONFIG_IS_ENABLED() guard for each backend to prevent
build errors, in case such a backend is enabled in U-Boot and not in SPL
or vice versa.
Signed-off-by: Marek Vasut
---
Cc: Lukasz Majewski
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
drivers/dfu/dfu.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 516dda61796..f9679d5ee52 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -529,22 +529,22 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char
*s, int alt,
dfu->free_entity = NULL;
/* Specific for mmc device */
- if (strcmp(interface, "mmc") == 0) {
+ if (CONFIG_IS_ENABLED(DFU_MMC) && !strcmp(interface, "mmc")) {
if (dfu_fill_entity_mmc(dfu, devstr, argv, argc))
return -1;
- } else if (strcmp(interface, "mtd") == 0) {
+ } else if (CONFIG_IS_ENABLED(DFU_MTD) && !strcmp(interface, "mtd")) {
if (dfu_fill_entity_mtd(dfu, devstr, argv, argc))
return -1;
- } else if (strcmp(interface, "nand") == 0) {
+ } else if (CONFIG_IS_ENABLED(DFU_NAND) && !strcmp(interface, "nand")) {
if (dfu_fill_entity_nand(dfu, devstr, argv, argc))
return -1;
- } else if (strcmp(interface, "ram") == 0) {
+ } else if (CONFIG_IS_ENABLED(DFU_RAM) && !strcmp(interface, "ram")) {
if (dfu_fill_entity_ram(dfu, devstr, argv, argc))
return -1;
- } else if (strcmp(interface, "sf") == 0) {
+ } else if (CONFIG_IS_ENABLED(DFU_SF) && !strcmp(interface, "sf")) {
if (dfu_fill_entity_sf(dfu, devstr, argv, argc))
return -1;
- } else if (strcmp(interface, "virt") == 0) {
+ } else if (CONFIG_IS_ENABLED(DFU_VIRT) && !strcmp(interface, "virt")) {
if (dfu_fill_entity_virt(dfu, devstr, argv, argc))
return -1;
} else {
--
2.35.1
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
Hi all
On Mon, 28 Nov 2022 at 18:22, Rob Herring wrote:
>
> On Fri, Nov 25, 2022 at 3:18 PM Simon Glass wrote:
> >
> > Hi Abdellatif,
> >
> > On Thu, 24 Nov 2022 at 06:21, Abdellatif El Khlifi
> > wrote:
> > >
> > > On Tue, Nov 22, 2022 at 07:09:16PM -0700, Simon Glass wrote:
> > > > should be called 'priov' and should beHi Abdellatif,
> > > >
> >
> > [..]
> >
> > > > > +/**
> > > > > + * ffa_device_get - create, bind and probe the arm_ffa device
> > > > > + * @pdev: the address of a device pointer (to be filled when the
> > > > > arm_ffa bus device is created
> > > > > + * successfully)
> > > > > + *
> > > > > + * This function makes sure the arm_ffa device is
> > > > > + * created, bound to this driver, probed and ready to use.
> > > > > + * Arm FF-A transport is implemented through a single U-Boot
> > > > > + * device managing the FF-A bus (arm_ffa).
> > > > > + *
> > > > > + * Return:
> > > > > + *
> > > > > + * 0 on success. Otherwise, failure
> > > > > + */
> > > > > +int ffa_device_get(struct udevice **pdev)
> > > > > +{
> > > > > + int ret;
> > > > > + struct udevice *dev = NULL;
> > > > > +
> > > > > + ret = device_bind(dm_root(), DM_DRIVER_GET(arm_ffa),
> > > > > FFA_DRV_NAME, NULL, ofnode_null(),
> > > > > + &dev);
> > > >
> > > > Please add a DT binding. Even if only temporary, we need something for
> > > > this.
> > >
> > > Thanks for the feedback. I'm happy to address all the comments.
> > >
> > > Regarding DT binding and FF-A discovery. We agreed with Linaro and Rob
> > > Herring
> > > about the following:
> > >
> > > - DT is only for what we failed to make discoverable. For hardware, we're
> > > stuck
> > > with it. We shouldn't repeat that for software interfaces. This
> > > approach is
> > > already applied in the FF-A kernel driver which comes with no DT
> > > support and
> > > discovers the bus with bus_register() API [1].
> >
> > This may be the UEFI view, but it is not how U-Boot works. This is not
> > something we are 'stuck' with. It is how we define what is present on a
> > device. This is how the PCI bus works in U-Boot. It is best practice in
> > U-Boot to use the device tree to make this things visible and configurable.
> > Unlike with Linux there is no other way to provide configuration needed by
> > these devices.
>
> Where do you get UEFI out of this?
>
> It is the discoverability of hardware that is fixed (and we are stuck
> with). We can't change hardware. The disoverability may be PCI
> VID/PID, USB device descriptors, or nothing. We only use DT when those
> are not sufficient. For a software interface, there is no reason to
> make them non-discoverable as the interface can be fixed (at least for
> new things like FF-A).
I'll agree with Rob here. In fact the first version of the patchset
*did* have this as a DT node. We explicitly asked Abdellatif to
change this, so u-boot and the linux kernel can have an identical
approach in discovering FF-A
Regards
/Ilias
>
> Rob
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
On Fri, Nov 25, 2022 at 3:18 PM Simon Glass wrote:
>
> Hi Abdellatif,
>
> On Thu, 24 Nov 2022 at 06:21, Abdellatif El Khlifi
> wrote:
> >
> > On Tue, Nov 22, 2022 at 07:09:16PM -0700, Simon Glass wrote:
> > > should be called 'priov' and should beHi Abdellatif,
> > >
>
> [..]
>
> > > > +/**
> > > > + * ffa_device_get - create, bind and probe the arm_ffa device
> > > > + * @pdev: the address of a device pointer (to be filled when the
> > > > arm_ffa bus device is created
> > > > + * successfully)
> > > > + *
> > > > + * This function makes sure the arm_ffa device is
> > > > + * created, bound to this driver, probed and ready to use.
> > > > + * Arm FF-A transport is implemented through a single U-Boot
> > > > + * device managing the FF-A bus (arm_ffa).
> > > > + *
> > > > + * Return:
> > > > + *
> > > > + * 0 on success. Otherwise, failure
> > > > + */
> > > > +int ffa_device_get(struct udevice **pdev)
> > > > +{
> > > > + int ret;
> > > > + struct udevice *dev = NULL;
> > > > +
> > > > + ret = device_bind(dm_root(), DM_DRIVER_GET(arm_ffa),
> > > > FFA_DRV_NAME, NULL, ofnode_null(),
> > > > + &dev);
> > >
> > > Please add a DT binding. Even if only temporary, we need something for
> > > this.
> >
> > Thanks for the feedback. I'm happy to address all the comments.
> >
> > Regarding DT binding and FF-A discovery. We agreed with Linaro and Rob
> > Herring
> > about the following:
> >
> > - DT is only for what we failed to make discoverable. For hardware, we're
> > stuck
> > with it. We shouldn't repeat that for software interfaces. This approach
> > is
> > already applied in the FF-A kernel driver which comes with no DT support
> > and
> > discovers the bus with bus_register() API [1].
>
> This may be the UEFI view, but it is not how U-Boot works. This is not
> something we are 'stuck' with. It is how we define what is present on a
> device. This is how the PCI bus works in U-Boot. It is best practice in
> U-Boot to use the device tree to make this things visible and configurable.
> Unlike with Linux there is no other way to provide configuration needed by
> these devices.
Where do you get UEFI out of this?
It is the discoverability of hardware that is fixed (and we are stuck
with). We can't change hardware. The disoverability may be PCI
VID/PID, USB device descriptors, or nothing. We only use DT when those
are not sufficient. For a software interface, there is no reason to
make them non-discoverable as the interface can be fixed (at least for
new things like FF-A).
Rob
Re: [PATCH 05/17] android: boot: add documentation for boot image header v3/v4 structure
On 11/26/22 11:59, Safae Ouajih wrote:
> [You don't often get email from soua...@baylibre.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> This was imported from [1], commit [2], file: include/bootimg/bootimg.h
> [1] https://android.googlesource.com/platform/system/tools/mkbootimg
> [2] cce5b1923e3cd2fcb765b512610bdc5c42bc501d
In general, downstream commits are not terribly useful. However, this is just
the current tip of that repo, not even the commit which this is imported from.
Please write your commit messages to describe what you are doing and why.
> Signed-off-by: Safae Ouajih
> ---
> include/android_image.h | 136 +++-
> 1 file changed, 135 insertions(+), 1 deletion(-)
>
> diff --git a/include/android_image.h b/include/android_image.h
> index ec36e6512ad6..62121e2a109b 100644
> --- a/include/android_image.h
> +++ b/include/android_image.h
> @@ -3,7 +3,7 @@
> * This is from the Android Project,
> * Repository:
> https://android.googlesource.com/platform/system/tools/mkbootimg
> * File: include/bootimg/bootimg.h
> - * Commit: e55998a0f2b61b685d5eb4a486ca3a0c680b1a2f
> + * Commit: cce5b1923e3cd2fcb765b512610bdc5c42bc501d
> *
> * Copyright (C) 2007 The Android Open Source Project
> */
> @@ -183,4 +183,138 @@ struct andr_boot_img_hdr_v0_v1_v2 {
> *else: jump to kernel_addr
> */
>
> +/* When the boot image header has a version of 3, the structure of the boot
> + * image is as follows:
> + *
> + * +-+
> + * | boot header | 4096 bytes
> + * +-+
> + * | kernel | m pages
> + * +-+
> + * | ramdisk | n pages
> + * +-+
> + *
> + * m = (kernel_size + 4096 - 1) / 4096
> + * n = (ramdisk_size + 4096 - 1) / 4096
> + *
> + * Note that in version 3 of the boot image header, page size is fixed at
> 4096 bytes.
> + *
> + * The structure of the vendor boot image (introduced with version 3 and
> + * required to be present when a v3 boot image is used) is as follows:
> + *
> + * +-+
> + * | vendor boot header | o pages
> + * +-+
> + * | vendor ramdisk | p pages
> + * +-+
> + * | dtb | q pages
> + * +-+
> + * o = (2112 + page_size - 1) / page_size
> + * p = (vendor_ramdisk_size + page_size - 1) / page_size
> + * q = (dtb_size + page_size - 1) / page_size
> + *
> + * 0. all entities in the boot image are 4096-byte aligned in flash, all
> + *entities in the vendor boot image are page_size (determined by the
> vendor
> + *and specified in the vendor boot image header) aligned in flash
> + * 1. kernel, ramdisk, vendor ramdisk, and DTB are required (size != 0)
> + * 2. load the kernel and DTB at the specified physical address (kernel_addr,
> + *dtb_addr)
> + * 3. load the vendor ramdisk at ramdisk_addr
> + * 4. load the generic ramdisk immediately following the vendor ramdisk in
> + *memory
> + * 5. set up registers for kernel entry as required by your architecture
> + * 6. if the platform has a second stage bootloader jump to it (must be
> + *contained outside boot and vendor boot partitions), otherwise
> + *jump to kernel_addr
> + */
> +
> +/* When the boot image header has a version of 4, the structure of the boot
> + * image is as follows:
> + *
> + * +-+
> + * | boot header | 4096 bytes
> + * +-+
> + * | kernel | m pages
> + * +-+
> + * | ramdisk | n pages
> + * +-+
> + * | boot signature | g pages
> + * +-+
> + *
> + * m = (kernel_size + 4096 - 1) / 4096
> + * n = (ramdisk_size + 4096 - 1) / 4096
> + * g = (signature_size + 4096 - 1) / 4096
> + *
> + * Note that in version 4 of the boot image header, page size is fixed at
> 4096
> + * bytes.
> + *
> + * The structure of the vendor boot image version 4, which is required to be
> + * present when a version 4 boot image is used, is as follows:
> + *
> + * ++
> + * | vendor boot header | o pages
> + * ++
> + * | vendor ramdisk section | p pages
> + * ++
> + * | dtb| q pages
> + * ++
> + * | vendor ramdisk table | r pages
> + * ++
> + * | bootconfig | s pages
> + * ++
> + *
> + * o = (2128 + page_size - 1) / page_size
> + * p = (vendor_ramdisk_size + page_size - 1) / page_size
> + * q = (dtb_size + page_size - 1) / page_size
> + * r = (vendor_ramdisk_table_size + page_size - 1) / page_size
> + * s = (vendor_bootconfig_size + page_size - 1) / page_size
> + *
> + * Note that in version 4 of the vendor boot image, multiple vendor ramdisks
> can
> + * be included in the vendor boot image. The bootloader can select a subset
Re: [PATCH 01/17] android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0_v1_v2
On 11/26/22 11:59, Safae Ouajih wrote:
> [You don't often get email from soua...@baylibre.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Android introduced boot header version 3 or 4.
> The header structure change with version 3 and 4 to support
> the new updates such as:
> - Introducing Vendor boot image: with a vendor ramdisk
> - Bootconfig feature (v4)
>
> To maintain support for version v0, v1 and v2 while introducing
> version 3 and 4, this struct name must change to refer to the header
> structure before v3.
>
> Signed-off-by: Safae Ouajih
> ---
> boot/image-android.c | 26 +-
> boot/image-fdt.c | 2 +-
> cmd/abootimg.c| 4 ++--
> drivers/fastboot/fb_mmc.c | 8
> include/android_image.h | 4 ++--
> include/image.h | 18 +-
> 6 files changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index 2628db374121..926d94ecbe8e 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -18,7 +18,7 @@
>
> static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE + 1];
>
> -static ulong android_image_get_kernel_addr(const struct andr_img_hdr *hdr)
> +static ulong android_image_get_kernel_addr(const struct
> andr_boot_img_hdr_v0_v1_v2 *hdr)
This line is too long. You will have to break it like
static ulong
android_image_get_kernel_addr(const struct andr_boot_img_hdr_v0_v1_v2 *hdr)
But really, this is because your struct name is too long. Can we use
something like andr_img_hdr_v0 instead? I would like to have only one
version in the struct name because then there is no urge to update the
name when e.g. v5 comes out with mostly the same format. And _boot adds
nothing.
--Sean
> {
> /*
> * All the Android tools that generate a boot.img use this
> @@ -59,7 +59,7 @@ static ulong android_image_get_kernel_addr(const struct
> andr_img_hdr *hdr)
> * Return: Zero, os start address and length on success,
> * otherwise on failure.
> */
> -int android_image_get_kernel(const struct andr_img_hdr *hdr, int verify,
> +int android_image_get_kernel(const struct andr_boot_img_hdr_v0_v1_v2 *hdr,
> int verify,
> ulong *os_data, ulong *os_len)
> {
> u32 kernel_addr = android_image_get_kernel_addr(hdr);
> @@ -122,12 +122,12 @@ int android_image_get_kernel(const struct andr_img_hdr
> *hdr, int verify,
> return 0;
> }
>
> -int android_image_check_header(const struct andr_img_hdr *hdr)
> +int android_image_check_header(const struct andr_boot_img_hdr_v0_v1_v2 *hdr)
> {
> return memcmp(ANDR_BOOT_MAGIC, hdr->magic, ANDR_BOOT_MAGIC_SIZE);
> }
>
> -ulong android_image_get_end(const struct andr_img_hdr *hdr)
> +ulong android_image_get_end(const struct andr_boot_img_hdr_v0_v1_v2 *hdr)
> {
> ulong end;
>
> @@ -150,12 +150,12 @@ ulong android_image_get_end(const struct andr_img_hdr
> *hdr)
> return end;
> }
>
> -ulong android_image_get_kload(const struct andr_img_hdr *hdr)
> +ulong android_image_get_kload(const struct andr_boot_img_hdr_v0_v1_v2 *hdr)
> {
> return android_image_get_kernel_addr(hdr);
> }
>
> -ulong android_image_get_kcomp(const struct andr_img_hdr *hdr)
> +ulong android_image_get_kcomp(const struct andr_boot_img_hdr_v0_v1_v2 *hdr)
> {
> const void *p = (void *)((uintptr_t)hdr + hdr->page_size);
>
> @@ -167,7 +167,7 @@ ulong android_image_get_kcomp(const struct andr_img_hdr
> *hdr)
> return image_decomp_type(p, sizeof(u32));
> }
>
> -int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
> +int android_image_get_ramdisk(const struct andr_boot_img_hdr_v0_v1_v2 *hdr,
> ulong *rd_data, ulong *rd_len)
> {
> if (!hdr->ramdisk_size) {
> @@ -186,7 +186,7 @@ int android_image_get_ramdisk(const struct andr_img_hdr
> *hdr,
> return 0;
> }
>
> -int android_image_get_second(const struct andr_img_hdr *hdr,
> +int android_image_get_second(const struct andr_boot_img_hdr_v0_v1_v2 *hdr,
> ulong *second_data, ulong *second_len)
> {
> if (!hdr->second_size) {
> @@ -226,7 +226,7 @@ int android_image_get_second(const struct andr_img_hdr
> *hdr,
> */
> bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size)
> {
> - const struct andr_img_hdr *hdr;
> + const struct andr_boot_img_hdr_v0_v1_v2 *hdr;
> ulong dtbo_img_addr;
> bool ret = true;
>
> @@ -275,7 +275,7 @@ exit:
> */
> static bool android_image_get_dtb_img_addr(ulong hdr_addr, ulong *addr)
> {
> - const struct andr_img_hdr *hdr;
> + const struct andr_boot_img_hdr_v0_v1_v2 *hdr;
> ulong dtb_img_addr;
> bool ret = true;
>
> @@ -328,7 +328,7 @@ exit:
> bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong *addr,
> u32 *size)
> {
Re: [PATCH 16/17] lib: support libxbc
On 11/26/22 11:59, Safae Ouajih wrote:
> [You don't often get email from soua...@baylibre.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> This adds support for libxbc used to support Bootconfig feature.
> Bootconfig documentation : [1]
> This was imported from [2], commit [3]
This should be written something like
This was adapted from downstream [2] commit 7af0a0506d4 ("shortlog
summary").
>
> [1]
> https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig
> [2] https://android.googlesource.com/platform/external/u-boot/
> [3] `7af0a0506d4de6f5ea147d10fb0664a8af07d326`
>
> Signed-off-by: Safae Ouajih
> ---
> include/xbc.h | 1 +
> lib/Kconfig | 12 +
> lib/Makefile| 1 +
> lib/libxbc/Makefile | 1 +
> lib/libxbc/libxbc.c | 112
> lib/libxbc/libxbc.h | 54 +
> 6 files changed, 181 insertions(+)
> create mode 100644 include/xbc.h
> create mode 100644 lib/libxbc/Makefile
> create mode 100644 lib/libxbc/libxbc.c
> create mode 100644 lib/libxbc/libxbc.h
I understand that you may want to import this "library" directly, but it
is really so short that I question the virtue of this. I think it would
be better to convert this to U-Boot style.
--Sean
> diff --git a/include/xbc.h b/include/xbc.h
> new file mode 100644
> index ..725e65ff6ad8
> --- /dev/null
> +++ b/include/xbc.h
> @@ -0,0 +1 @@
> +#include <../lib/libxbc/libxbc.h>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 6abe1d0a863b..eca752b7db79 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -417,6 +417,18 @@ config LIBAVB
>
> endmenu
>
> +menu "Android Boot Configuration"
> +config LIBXBC
> + bool "Android Boot Configuration support"
> + depends on ANDROID_BOOT_IMAGE
> + default n
> + help
> + This enables support of Boot Configuration which can be used
> + to pass boot configuration parameters to user space. These
> + parameters will show up in /proc/bootconfig similar to the kernel
> + parameters that show up in /proc/cmdline
> +endmenu
> +
> menu "Hashing Support"
>
> config BLAKE2
> diff --git a/lib/Makefile b/lib/Makefile
> index f2cfd1e42892..b0ad522ac116 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -87,6 +87,7 @@ obj-$(CONFIG_$(SPL_)LZ4) += lz4_wrapper.o
> obj-$(CONFIG_$(SPL_)LIB_RATIONAL) += rational.o
>
> obj-$(CONFIG_LIBAVB) += libavb/
> +obj-$(CONFIG_LIBXBC) += libxbc/
>
> obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += libfdt/
> obj-$(CONFIG_$(SPL_TPL_)OF_REAL) += fdtdec_common.o fdtdec.o
> diff --git a/lib/libxbc/Makefile b/lib/libxbc/Makefile
> new file mode 100644
> index ..7ac4cde05666
> --- /dev/null
> +++ b/lib/libxbc/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_LIBXBC) += libxbc.o
> diff --git a/lib/libxbc/libxbc.c b/lib/libxbc/libxbc.c
> new file mode 100644
> index ..129bffc7c628
> --- /dev/null
> +++ b/lib/libxbc/libxbc.c
> @@ -0,0 +1,112 @@
> +/*
> + * Copyright (C) 2021 The Android Open Source Project
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +#include "libxbc.h"
> +#define BOOTCONFIG_MAGIC "#BOOTCONFIG\n"
> +#define BOOTCONFIG_MAGIC_SIZE 12
> +#define BOOTCONFIG_SIZE_SIZE 4
> +#define BOOTCONFIG_CHECKSUM_SIZE 4
> +#define BOOTCONFIG_TRAILER_SIZE BOOTCONFIG_MAGIC_SIZE + \
> +BOOTCONFIG_SIZE_SIZE + \
> +BOOTCONFIG_CHECKSUM_SIZE
> +
> +/*
> + * Simple checksum for a buffer.
> + *
> + * @param addr pointer to the start of the buffer.
> + * @param size size of the buffer in bytes.
> + * @return check sum result.
> + */
> +static uint32_t checksum(const unsigned char* const buffer, uint32_t size) {
> +uint32_t sum = 0;
> +for (uint32_t i = 0; i < size; i++) {
> +sum += buffer[i];
> +}
> +return sum;
> +}
> +
> +/*
> + * Check if the bootconfig trailer is present within the bootconfig section.
> + *
> + * @param bootconfig_end_addr address of the end of the bootconfig section.
> If
> + *the trailer is present, it will be directly preceding this address.
> + * @return true if the trailer is present, false if not.
> + */
> +static bool isTrailerPresent(uint64_t bootconfig_end_addr) {
> +return !strncmp((char*)(bootconfig_end_addr - BOOTCONFIG_MAGIC_SIZE),
> +BOOTCONFIG_MAGIC, BOOTCONFIG_MAG
Re: [PATCH v8 4/8] net: dsa: allow rcv() and xmit() to be optional
On Thu, Oct 27, 2022 at 05:49:33PM -0700, Tim Harvey wrote: > Allow rcv() and xmit() dsa driver ops to be optional in case a driver > does not care to mangle a packet as in U-Boot only one network port is > enabled at a time and thus no packet mangling is necessary. > > Suggested-by: Vladimir Oltean > Signed-off-by: Tim Harvey > Reviewed-by: Vladimir Oltean > Reviewed-by: Fabio Estevam This causes: FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_dsa] - AssertionError: assert False In sandbox, and I don't know if the test or the code is wrong. -- Tom signature.asc Description: PGP signature
Re: Patch proposal - mkimage: fit: Support signed conf 'auto' FITs
On 11/22/22 21:09, Simon Glass wrote:
> Hi Pegorer,
>
> On Sat, 19 Nov 2022 at 11:01, Pegorer Massimo
> wrote:
>>
>> Commit 87b0af9317cb4105f3f29cb0a4c28c7cd87ea65f added support for signing
>> auto-generated (mkimage -f auto) FIT. Unfortunately, this signs 'images'
>> subnodes but not 'configurations' ones. Following patch is a proposal to
>> support also 'configurations' signing + 'images' hashing, as an alternative
>> to 'images' signing, with 'auto' FIT. For this purpose, a new optional
>> argument is added to mkimage '-r' option: any other better idea?
>>
>> =
>>
>> From 8c8c8f421d541cc2eccb50490a57e86b81dc8df2 Mon Sep 17 00:00:00 2001
>> From: Massimo Pegorer
>> Date: Sat, 19 Nov 2022 16:25:58 +0100
>> Subject: [PATCH] mkimage: fit: Support signed conf 'auto' FITs
>>
>> Extend support for signing in auto-generated FITs. Previously, it was
>> possible to sign 'images' subnodes in auto FIT, but not 'configurations'
>> subnodes. Consequently, usage with -K and -r options (i.e. write keys as
>> 'required' in a .dtb file) resulted in adding a signature node with
>> required = "image" property in the dtb.
>>
>> This patch allows usage of an optional argument with -r option to select
>> which subnodes, 'images' ones or 'configurations' ones, have to be signed
>> (in the second case 'images' subnodes are hashed): with '-r' or '-rimage'
>> the firsts are signed, while with '-rconf' the seconds; argument values
>> different than 'image' and 'conf' are invalid.
>>
>> Example to write a key with required = "conf" attribute into a dtb file:
>>
>> mkimage -f auto -rconf -d /dev/null -K -o \
>> -g -k
>>
>> Signed-off-by: Massimo Pegorer
>> ---
>> tools/fit_image.c | 25 +
>> tools/mkimage.c | 18 ++
Remember to update the man page for your next revision.
>> 2 files changed, 31 insertions(+), 12 deletions(-)
>>
>> diff --git a/tools/fit_image.c b/tools/fit_image.c
>> index 923a9755b7..c78d83d509 100644
>> --- a/tools/fit_image.c
>> +++ b/tools/fit_image.c
>> @@ -199,19 +199,22 @@ static void get_basename(char *str, int size, const
>> char *fname)
>> }
>>
>> /**
>> - * add_hash_node() - Add a hash or signature node
>> + * add_hash_or_sign_node() - Add a hash or signature node
>> *
>> * @params: Image parameters
>> * @fdt: Device tree to add to (in sequential-write mode)
>> + * @do_add_hash: true to add hash even if key name hint is provided
>> *
>> - * If there is a key name hint, try to sign the images. Otherwise, just add
>> a
>> - * CRC.
>> + * If do_add_hash is false (default) and there is a key name hint, try to
>> add
>> + * a sign node to parent. Otherwise, just add a CRC. Rationale: if conf have
>> + * to be signed, image/dt have to be hashed even if there is a key name
>> hint.
>> *
>> * Return: 0 on success, or -1 on failure
>> */
>> -static int add_hash_node(struct image_tool_params *params, void *fdt)
>> +static int add_hash_or_sig_node(struct image_tool_params *params, void *fdt,
>> + bool do_add_hash)
>> {
>> - if (params->keyname) {
>> + if (!do_add_hash && params->keyname) {
>> if (!params->algo_name) {
>> fprintf(stderr,
>> "%s: Algorithm name must be specified\n",
>> @@ -269,7 +272,7 @@ static int fit_write_images(struct image_tool_params
>> *params, char *fdt)
>> ret = fdt_property_file(params, fdt, FIT_DATA_PROP,
>> params->datafile);
>> if (ret)
>> return ret;
>> - ret = add_hash_node(params, fdt);
>> + ret = add_hash_or_sig_node(params, fdt, (params->require_keys == 2));
>> if (ret)
>> return ret;
>> fdt_end_node(fdt);
>> @@ -294,7 +297,8 @@ static int fit_write_images(struct image_tool_params
>> *params, char *fdt)
>>
>> genimg_get_arch_short_name(params->arch));
>> fdt_property_string(fdt, FIT_COMP_PROP,
>>
>> genimg_get_comp_short_name(IH_COMP_NONE));
>> - ret = add_hash_node(params, fdt);
>> + ret = add_hash_or_sig_node(params, fdt,
>> + (params->require_keys == 2));
>> if (ret)
>> return ret;
>> fdt_end_node(fdt);
>> @@ -314,7 +318,8 @@ static int fit_write_images(struct image_tool_params
>> *params, char *fdt)
>> params->fit_ramdisk);
>> if (ret)
>> return ret;
>> - ret = add_hash_node(params, fdt);
>> + ret = add_hash_or_sig_node(params, fdt,
>> + (params->require_keys == 2));
>> if (ret)
>> return ret;
>> fdt_end_node(fdt);
>> @@ -366,6 +371,8 @@ static void fit_write_configs(struct image_tool_
Re: [PATCH v4 00/17] IPv6 support
On Thu, Sep 08, 2022 at 02:58:48PM +0300, Viacheslav Mitrofanov wrote: > This patch set adds basic IPv6 support to U-boot. > It is based on Chris's Packham patches > (https://lists.denx.de/pipermail/u-boot/2017-January/279366.html) > Chris's patches were taken as base. There were efforts to launch it on > HiFive SiFive Unmatched board but the board didn't work well. The code was > refactored, fixed some bugs as CRC for little-endian, some parts were > implemented in > our own way, something was taken from Linux. Finally we did manual tests and > the > board worked well. > > Testing was done on HiFive SiFive Unmatched board (RISC-V) > > Signed-off-by: Viacheslav Mitrofanov > --- > Changes in v2: > - Split big patches into smaller > - If an address in tftpboot is IPv6 than use IPv6 to boot > - Add tests > > Changes in v3: > - Added functions and structures description in whole patch-series > - Removed memory allocation in on_ip6addr() > - Some functions got return code from errno.h > - Add to string_to_ip6() length parameter to avoid obligatory null > termination > - Add a lot of small decorative cnages > > Changes in v4: > - Fixed funcs and structures style description > - Added omitted tags Testing this locally in sandbox I see: FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_csum_ipv6_magic] - AssertionError: as... FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_ip6_addr_in_subnet] - AssertionError:... FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_ip6_make_lladdr] - assert False FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_ip6_make_snma] - assert False FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_string_to_ip6] - AssertionError: asse... and this happens in CI as well: https://source.denx.de/u-boot/u-boot/-/pipelines/14245 https://dev.azure.com/u-boot/u-boot/_build/results?buildId=5432&view=results If you can't replicate the failures locally you should be able to trigger CI: https://u-boot.readthedocs.io/en/latest/develop/ci_testing.html Thanks for pushing this along! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Mon, Nov 28, 2022 at 12:19:02PM +0100, Marek Vasut wrote: > The following changes since commit 27c415ae8b743710e412ef408b52894af68141c6: > > Merge branch '2022-11-23-assorted-fixes' (2022-11-24 16:31:02 -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to db5bace4f6cb37251a5863efe4c0c1547d1334bd: > > usb: dwc3: Drop support for "snps, ref-clock-period-ns" DT property > (2022-11-27 15:34:56 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND PATCH v2 0/3] net: fm: Add support for loading firmware from filesystem
On Sun, Nov 27, 2022 at 12:47:37AM +0200, Ramon Fried wrote: > On Thu, Nov 17, 2022 at 11:29 PM Sean Anderson wrote: > > > > On 8/14/22 16:48, Ramon Fried wrote: > > > On Sat, Aug 13, 2022 at 9:15 AM Sean Anderson > > > wrote: > > >> > > >> On 4/22/22 1:30 PM, Sean Anderson wrote: > > >> > This adds support for loading Fman firmware from a filesystem using the > > >> > firmware loader subsystem. It was originally part of [1], but has been > > >> > split off because it is conceptually separate. > > >> > > > >> > [1] > > >> > https://lore.kernel.org/u-boot/20220324182306.2037094-1-sean.ander...@seco.com/ > > >> > > > >> > Changes in v2: > > >> > - Split series into two > > >> > > > >> > Sean Anderson (3): > > >> >misc: fs_loader: Add function to get the chosen loader > > >> >net: fm: Add firmware name parameter > > >> >net: fm: Support loading firmware from a filesystem > > >> > > > >> > arch/arm/mach-k3/common.c | 2 +- > > >> > arch/arm/mach-omap2/boot-common.c | 2 +- > > >> > drivers/fpga/socfpga_arria10.c| 24 ++- > > >> > drivers/misc/fs_loader.c | 27 + > > >> > drivers/net/fm/fm.c | 40 > > >> > +++ > > >> > drivers/net/fm/fm.h | 2 +- > > >> > drivers/net/fm/init.c | 4 ++-- > > >> > drivers/qe/Kconfig| 4 > > >> > include/fs_loader.h | 12 ++ > > >> > 9 files changed, 86 insertions(+), 31 deletions(-) > > >> > > > >> > > >> ping > > > Pong, sorry, was lost in the mailbox. > > > > ping again > > > > Looks like this got reviewed but never applied. Does it still apply > > cleanly? If not I can rebase and resend. > Tom ? I don't see a problem with this. I see in patchwork it's assigned to Marek and "Under Review", which I don't recall doing, so, are you looking at these currently Marek? -- Tom signature.asc Description: PGP signature
Re: [u-boot][PATCH 06/14] mtd: rawnand: nand_base: Allow base driver to be used in SPL without nand_bbt
Hi
On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote:
>
> nand_bbt.c is not being built with the nand_base driver during SPL
> build. This results in build failures if we try to access any nand_bbt
> related functions.
>
> Don't use any nand_bbt functions for SPL build.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/mtd/nand/raw/nand_base.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 4b09a11288..826ae633ce 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -447,7 +447,10 @@ static int nand_default_block_markbad(struct mtd_info
> *mtd, loff_t ofs)
> static int nand_block_markbad_lowlevel(struct mtd_info *mtd, loff_t ofs)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> - int res, ret = 0;
> + int ret = 0;
> +#ifndef CONFIG_SPL_BUILD
> + int res;
> +#endif
>
> if (!(chip->bbt_options & NAND_BBT_NO_OOB_BBM)) {
> struct erase_info einfo;
> @@ -465,12 +468,14 @@ static int nand_block_markbad_lowlevel(struct mtd_info
> *mtd, loff_t ofs)
> nand_release_device(mtd);
> }
>
> +#ifndef CONFIG_SPL_BUILD
> /* Mark block bad in BBT */
> if (chip->bbt) {
> res = nand_markbad_bbt(mtd, ofs);
> if (!ret)
> ret = res;
> }
> +#endif
>
> if (!ret)
> mtd->ecc_stats.badblocks++;
> @@ -517,7 +522,11 @@ static int nand_block_isreserved(struct mtd_info *mtd,
> loff_t ofs)
> if (!chip->bbt)
> return 0;
> /* Return info from the table */
> +#ifndef CONFIG_SPL_BUILD
> return nand_isreserved_bbt(mtd, ofs);
> +#else
> + return 0;
> +#endif
> }
>
> /**
> @@ -543,7 +552,11 @@ static int nand_block_checkbad(struct mtd_info *mtd,
> loff_t ofs, int allowbbt)
> return chip->block_bad(mtd, ofs);
>
> /* Return info from the table */
> +#ifndef CONFIG_SPL_BUILD
> return nand_isbad_bbt(mtd, ofs, allowbbt);
> +#else
> + return 0;
> +#endif
> }
Can you please send me the config that let this fail?
Michael
>
> /**
> @@ -3752,8 +3765,11 @@ static void nand_set_defaults(struct nand_chip *chip,
> int busw)
> chip->write_byte = busw ? nand_write_byte16 : nand_write_byte;
> if (!chip->read_buf || chip->read_buf == nand_read_buf)
> chip->read_buf = busw ? nand_read_buf16 : nand_read_buf;
> +
> +#ifndef CONFIG_SPL_BUILD
> if (!chip->scan_bbt)
> chip->scan_bbt = nand_default_bbt;
> +#endif
>
> if (!chip->controller) {
> chip->controller = &chip->hwcontrol;
> --
> 2.17.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [u-boot][PATCH 08/14] mtd: rawnand: omap_gpmc: Reduce .bss usage
Hi
On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote:
>
> Allocate omap_ecclayout on the heap as we have
> limited .bss space on AM64 R5 SPL configuration.
>
> Reduces .bss usage by 2984 bytes.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/mtd/nand/raw/omap_gpmc.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> b/drivers/mtd/nand/raw/omap_gpmc.c
> index b5ad66ad49..e772a914c8 100644
> --- a/drivers/mtd/nand/raw/omap_gpmc.c
> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> @@ -40,7 +40,6 @@ static u8 bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09,
> 0xed, 0x93, 0x9a, 0xc2,
> 0x97, 0x79, 0xe5, 0x24, 0xb5};
> #endif
> static uint8_t cs_next;
> -static __maybe_unused struct nand_ecclayout omap_ecclayout;
>
> #if defined(CONFIG_NAND_OMAP_GPMC_WSCFG)
> static const int8_t wscfg[CONFIG_SYS_MAX_NAND_DEVICE] =
> @@ -874,7 +873,7 @@ static void __maybe_unused omap_free_bch(struct mtd_info
> *mtd)
> static int omap_select_ecc_scheme(struct nand_chip *nand,
> enum omap_ecc ecc_scheme, unsigned int pagesize, unsigned int
> oobsize) {
> struct omap_nand_info *info =
> nand_get_controller_data(nand);
> - struct nand_ecclayout *ecclayout = &omap_ecclayout;
> + struct nand_ecclayout *ecclayout = nand->ecc.layout;
> int eccsteps = pagesize / SECTOR_BYTES;
> int i;
>
> @@ -1167,7 +1166,9 @@ int board_nand_init(struct nand_chip *nand)
> nand->cmd_ctrl = omap_nand_hwcontrol;
> nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
> nand->chip_delay = 100;
> - nand->ecc.layout = &omap_ecclayout;
> + nand->ecc.layout = kzalloc(sizeof(*nand->ecc.layout), GFP_KERNEL);
> + if (!nand->ecc.layout)
> + return -ENOMEM;
>
> /* configure driver and controller based on NAND device bus-width */
> gpmc_config = readl(&gpmc_cfg->cs[cs].config1);
> --
> 2.17.1
>
Reviewed-By: Michael Trimarchi
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [u-boot][PATCH 05/14] mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
Hi Roger
On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote:
>
> The BCH detection hardware can generate ECC bytes for multiple
> sectors in one go. Use that feature.
>
> correct() only corrects one sector at a time so we need to call it
> repeatedly for each sector.
>
Reviewed-by: Michael Trimarchi
> Signed-off-by: Roger Quadros
> ---
> drivers/mtd/nand/raw/omap_gpmc.c | 325 +--
> 1 file changed, 223 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> b/drivers/mtd/nand/raw/omap_gpmc.c
> index b36fe762b3..b5ad66ad49 100644
> --- a/drivers/mtd/nand/raw/omap_gpmc.c
> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> @@ -27,6 +27,9 @@
>
> #define BADBLOCK_MARKER_LENGTH 2
> #define SECTOR_BYTES 512
> +#define ECCSIZE0_SHIFT 12
> +#define ECCSIZE1_SHIFT 22
> +#define ECC1RESULTSIZE 0x1
> #define ECCCLEAR (0x1 << 8)
> #define ECCRESULTREG1 (0x1 << 0)
> /* 4 bit padding to make byte aligned, 56 = 52 + 4 */
> @@ -187,72 +190,35 @@ static int __maybe_unused omap_correct_data(struct
> mtd_info *mtd, uint8_t *dat,
> __maybe_unused
> static void omap_enable_hwecc(struct mtd_info *mtd, int32_t mode)
> {
> - struct nand_chip*nand = mtd_to_nand(mtd);
> - struct omap_nand_info *info = nand_get_controller_data(nand);
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct omap_nand_info *info = nand_get_controller_data(nand);
> unsigned int dev_width = (nand->options & NAND_BUSWIDTH_16) ? 1 : 0;
> - unsigned int ecc_algo = 0;
> - unsigned int bch_type = 0;
> - unsigned int eccsize1 = 0x00, eccsize0 = 0x00, bch_wrapmode = 0x00;
> - u32 ecc_size_config_val = 0;
> - u32 ecc_config_val = 0;
> - int cs = info->cs;
> + u32 val;
>
> - /* configure GPMC for specific ecc-scheme */
> - switch (info->ecc_scheme) {
> - case OMAP_ECC_HAM1_CODE_SW:
> - return;
> - case OMAP_ECC_HAM1_CODE_HW:
> - ecc_algo = 0x0;
> - bch_type = 0x0;
> - bch_wrapmode = 0x00;
> - eccsize0 = 0xFF;
> - eccsize1 = 0xFF;
> + /* Clear ecc and enable bits */
> + writel(ECCCLEAR | ECCRESULTREG1, &gpmc_cfg->ecc_control);
> +
> + /* program ecc and result sizes */
> + val = nand->ecc.size >> 1) - 1) << ECCSIZE1_SHIFT) |
> + ECC1RESULTSIZE);
> + writel(val, &gpmc_cfg->ecc_size_config);
> +
> + switch (mode) {
> + case NAND_ECC_READ:
> + case NAND_ECC_WRITE:
> + writel(ECCCLEAR | ECCRESULTREG1, &gpmc_cfg->ecc_control);
> break;
> - case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
> - case OMAP_ECC_BCH8_CODE_HW:
> - ecc_algo = 0x1;
> - bch_type = 0x1;
> - if (mode == NAND_ECC_WRITE) {
> - bch_wrapmode = 0x01;
> - eccsize0 = 0; /* extra bits in nibbles per sector */
> - eccsize1 = 28; /* OOB bits in nibbles per sector */
> - } else {
> - bch_wrapmode = 0x01;
> - eccsize0 = 26; /* ECC bits in nibbles per sector */
> - eccsize1 = 2; /* non-ECC bits in nibbles per sector
> */
> - }
> - break;
> - case OMAP_ECC_BCH16_CODE_HW:
> - ecc_algo = 0x1;
> - bch_type = 0x2;
> - if (mode == NAND_ECC_WRITE) {
> - bch_wrapmode = 0x01;
> - eccsize0 = 0; /* extra bits in nibbles per sector */
> - eccsize1 = 52; /* OOB bits in nibbles per sector */
> - } else {
> - bch_wrapmode = 0x01;
> - eccsize0 = 52; /* ECC bits in nibbles per sector */
> - eccsize1 = 0; /* non-ECC bits in nibbles per sector
> */
> - }
> + case NAND_ECC_READSYN:
> + writel(ECCCLEAR, &gpmc_cfg->ecc_control);
> break;
> default:
> - return;
> + printf("%s: error: unrecognized Mode[%d]!\n", __func__, mode);
> + break;
> }
> - /* Clear ecc and enable bits */
> - writel(ECCCLEAR | ECCRESULTREG1, &gpmc_cfg->ecc_control);
> - /* Configure ecc size for BCH */
> - ecc_size_config_val = (eccsize1 << 22) | (eccsize0 << 12);
> - writel(ecc_size_config_val, &gpmc_cfg->ecc_size_config);
> -
> - /* Configure device details for BCH engine */
> - ecc_config_val = ((ecc_algo << 16) | /* HAM1 | BCHx */
> - (bch_type << 12)| /* BCH4/BCH8/BCH16 */
> - (bch_wrapmode << 8) | /* wrap mode */
> - (dev_width << 7)| /* bus width */
> - (0x0 << 4)
Re: [PATCH] usb: gadget: dfu: Fix the unchecked length field
On 11/21/22 18:34, Tom Rini wrote: On Thu, Nov 03, 2022 at 09:37:48AM +0530, Venkatesh Yadav Abbarapu wrote: DFU implementation does not bound the length field in USB DFU download setup packets, and it does not verify that the transfer direction. Fixing the length and transfer direction. CVE-2022-2347 Signed-off-by: Venkatesh Yadav Abbarapu Reviewed-by: Marek Vasut Applied to u-boot/master, thanks! So this breaks DFU support in SPL as I just found out. Any idea why ?
[PATCH 1/1] configs: imx8mp_evk: revert to old ram settings
The 'commit 864ac2cf383e ("board: imx8mp: Add Engicam
i.Core MX8M Plus EDIMM2.2 Starter Kit")' has changed the imx8mp evk ram
settings from 6GB ram to 2GB.
This changeset reverts the above change.
Signed-off-by: Manoj Sai
Reported-by : Peter Bergin
---
include/configs/imx8mp_evk.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
index 1b533e2c14..d8db83cad8 100644
--- a/include/configs/imx8mp_evk.h
+++ b/include/configs/imx8mp_evk.h
@@ -54,9 +54,11 @@
#define CONFIG_SYS_INIT_RAM_SIZE 0x8
-/* Totally 2GB DDR */
+/* Totally 6GB DDR */
#define CONFIG_SYS_SDRAM_BASE 0x4000
#define PHYS_SDRAM 0x4000
-#define PHYS_SDRAM_SIZE0x8000
+#define PHYS_SDRAM_SIZE0xC000 /* 3 GB */
+#define PHYS_SDRAM_2 0x1
+#define PHYS_SDRAM_2_SIZE 0xC000 /* 3 GB */
#endif
--
2.25.1
[PATCH 0/1] configs: imx8mp_evk: revert to old ram settings
revert the ram settings of imx8mp evk which are changed with
commit id : 864ac2cf383e ("board: imx8mp: Add Engicam i.Core
MX8M Plus EDIMM2.2 Starter Kit")
Manoj Sai (1):
configs: imx8mp_evk: revert to old ram settings
include/configs/imx8mp_evk.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.25.1
Re: [PATCH v2 3/3] board: imx8mp: Add Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit
On Mon, Nov 28, 2022 at 1:37 PM Peter Bergin wrote: > > > On 2022-08-26 14:33, Manoj Sai wrote: > > diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h > > index 388f3bc9ff..140eba3d1c 100644 > > --- a/include/configs/imx8mp_evk.h > > +++ b/include/configs/imx8mp_evk.h > > @@ -55,11 +55,9 @@ > > #define CONFIG_SYS_INIT_RAM_SIZE0x8 > > > > > > -/* Totally 6GB DDR */ > > +/* Totally 2GB DDR */ > > #define CONFIG_SYS_SDRAM_BASE 0x4000 > > #define PHYS_SDRAM 0x4000 > > -#define PHYS_SDRAM_SIZE 0xC000 /* 3 GB */ > > -#define PHYS_SDRAM_2 0x1 > > -#define PHYS_SDRAM_2_SIZE0xC000 /* 3 GB */ > > +#define PHYS_SDRAM_SIZE 0x8000 > > > > #endif > > This patch is applied on master branch since a while, commit > 864ac2cf383e4b8008f09db2e7e53318093c431e. Why does it change RAM size > for NXP's i.Mx8mp EVK from 6GB->2GB? The patch is aimed to add a new > board not to change an existing one. Hi Peter, Thanks for pointing that out. The Mistake is from my side, sent the undesired change. I will revert this change ASAP. Best regards, Manoj sai A > > Best regards, > /Peter >
[PATCH v2 5/5] doc:eficonfig: add description for UEFI Secure Boot Configuration
This commits add the description for the UEFI Secure Boot Configuration through the eficonfig menu. Signed-off-by: Masahisa Kojima --- Newly created in v2 doc/usage/cmd/eficonfig.rst | 22 ++ 1 file changed, 22 insertions(+) diff --git a/doc/usage/cmd/eficonfig.rst b/doc/usage/cmd/eficonfig.rst index 340ebc80db..67c859964f 100644 --- a/doc/usage/cmd/eficonfig.rst +++ b/doc/usage/cmd/eficonfig.rst @@ -31,6 +31,9 @@ Change Boot Order Delete Boot Option Delete the UEFI Boot Option +Secure Boot Configuration +Edit UEFI Secure Boot Configuration + Configuration - @@ -44,6 +47,16 @@ U-Boot console. In this case, bootmenu can be used to invoke "eficonfig":: CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="setenv bootmenu_0 UEFI Maintenance Menu=eficonfig" +UEFI specification requires that UEFI Secure Boot Configuration (especially +for PK and KEK) is stored in non-volatile storage which is tamper resident. +CONFIG_EFI_MM_COMM_TEE is mandatory to provide the secure storage in U-Boot. +UEFI Secure Boot Configuration menu entry is enabled when the following +options are enabled:: + +CONFIG_EFI_SECURE_BOOT=y +CONFIG_EFI_MM_COMM_TEE=y + + How to boot the system with newly added UEFI Boot Option @@ -66,6 +79,15 @@ add "bootefi bootmgr" entry as a default or first bootmenu entry:: CONFIG_PREBOOT="setenv bootmenu_0 UEFI Boot Manager=bootefi bootmgr; setenv bootmenu_1 UEFI Maintenance Menu=eficonfig" +UEFI Secure Boot Configuration +'' + +User can enroll PK, KEK, db and dbx by selecting file. +"eficonfig" command only accepts the signed EFI Signature List(s) +with an authenticated header, typically ".auth" file. +To clear the PK, KEK, db and dbx, user needs to enroll the null key +signed by PK or KEK. + See also * :doc:`bootmenu` provides a simple mechanism for creating menus with different boot items -- 2.17.1
[PATCH v2 4/5] eficonfig: use efi_get_next_variable_name_int()
eficonfig command reads all possible UEFI load options
from 0x to 0x to construct the menu. This takes too much
time in some environment.
This commit uses efi_get_next_variable_name_int() to read all
existing UEFI load options to significantlly reduce the count of
efi_get_var() call.
Signed-off-by: Masahisa Kojima
---
v1->v2:
- totaly change the implemention, remove new Kconfig introduced in v1.
- use efi_get_next_variable_name_int() to read the all existing
UEFI variables, then enumerate the "Boot" variables
- this commit does not provide the common function to enumerate
all "Boot" variables. I think common function does not
simplify the implementation, because caller of
efi_get_next_variable_name_int()
needs to remember original buffer size, new buffer size and buffer address
and it is a bit complicated when we consider to create common function.
cmd/eficonfig.c | 141 +++-
1 file changed, 117 insertions(+), 24 deletions(-)
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 88d507d04c..394ae67cce 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1683,7 +1683,8 @@ static efi_status_t
eficonfig_show_boot_selection(unsigned int *selected)
u32 i;
u16 *bootorder;
efi_status_t ret;
- efi_uintn_t num, size;
+ u16 *var_name16 = NULL, *p;
+ efi_uintn_t num, size, buf_size;
struct efimenu *efi_menu;
struct list_head *pos, *n;
struct eficonfig_entry *entry;
@@ -1707,14 +1708,43 @@ static efi_status_t
eficonfig_show_boot_selection(unsigned int *selected)
}
/* list the remaining load option not included in the BootOrder */
- for (i = 0; i <= 0x; i++) {
- /* If the index is included in the BootOrder, skip it */
- if (search_bootorder(bootorder, num, i, NULL))
- continue;
+ buf_size = 128;
+ var_name16 = malloc(buf_size);
+ if (!var_name16)
+ return EFI_OUT_OF_RESOURCES;
- ret = eficonfig_add_boot_selection_entry(efi_menu, i, selected);
- if (ret != EFI_SUCCESS)
- goto out;
+ var_name16[0] = 0;
+ for (;;) {
+ int index;
+ efi_guid_t guid;
+
+ size = buf_size;
+ ret = efi_get_next_variable_name_int(&size, var_name16, &guid);
+ if (ret == EFI_NOT_FOUND)
+ break;
+ if (ret == EFI_BUFFER_TOO_SMALL) {
+ buf_size = size;
+ p = realloc(var_name16, buf_size);
+ if (!p) {
+ free(var_name16);
+ return EFI_OUT_OF_RESOURCES;
+ }
+ var_name16 = p;
+ ret = efi_get_next_variable_name_int(&size, var_name16,
&guid);
+ }
+ if (ret != EFI_SUCCESS) {
+ free(var_name16);
+ return ret;
+ }
+ if (efi_varname_is_load_option(var_name16, &index)) {
+ /* If the index is included in the BootOrder, skip it */
+ if (search_bootorder(bootorder, num, index, NULL))
+ continue;
+
+ ret = eficonfig_add_boot_selection_entry(efi_menu,
index, selected);
+ if (ret != EFI_SUCCESS)
+ goto out;
+ }
if (efi_menu->count >= EFICONFIG_ENTRY_NUM_MAX - 1)
break;
@@ -1732,6 +1762,8 @@ out:
}
eficonfig_destroy(efi_menu);
+ free(var_name16);
+
return ret;
}
@@ -1994,6 +2026,8 @@ static efi_status_t
eficonfig_create_change_boot_order_entry(struct efimenu *efi
u32 i;
char *title;
efi_status_t ret;
+ u16 *var_name16 = NULL, *p;
+ efi_uintn_t size, buf_size;
/* list the load option in the order of BootOrder variable */
for (i = 0; i < num; i++) {
@@ -2006,17 +2040,45 @@ static efi_status_t
eficonfig_create_change_boot_order_entry(struct efimenu *efi
}
/* list the remaining load option not included in the BootOrder */
- for (i = 0; i < 0x; i++) {
+ buf_size = 128;
+ var_name16 = malloc(buf_size);
+ if (!var_name16)
+ return EFI_OUT_OF_RESOURCES;
+
+ var_name16[0] = 0;
+ for (;;) {
+ int index;
+ efi_guid_t guid;
+
if (efi_menu->count >= EFICONFIG_ENTRY_NUM_MAX - 2)
break;
- /* If the index is included in the BootOrder, skip it */
- if (search_bootorder(bootorder, num, i, NULL))
- continue;
-
- ret = eficonfig_add_change_boot_order_entry(efi_menu, i, false);
+
[PATCH v2 3/5] efi_loader: utility function to check the variable name is "Boot####"
Some commands need to enumerate the existing UEFI load
option variable("Boot"). This commit transfers some code
from cmd/efidebug.c to lib/efi_loder/, then exposes u16_tohex() and
efi_varname_is_load_option() function to check whether the
UEFI variable name is "Boot".
Signed-off-by: Masahisa Kojima
---
Newly created in v2
cmd/efidebug.c | 23 +--
include/efi_loader.h| 2 ++
lib/efi_loader/efi_helper.c | 33 +
3 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index ef239bb34b..ceb3aa5cee 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -1010,17 +1010,6 @@ static void show_efi_boot_opt(u16 *varname16)
}
}
-static int u16_tohex(u16 c)
-{
- if (c >= '0' && c <= '9')
- return c - '0';
- if (c >= 'A' && c <= 'F')
- return c - 'A' + 10;
-
- /* not hexadecimal */
- return -1;
-}
-
/**
* show_efi_boot_dump() - dump all UEFI load options
*
@@ -1041,7 +1030,6 @@ static int do_efi_boot_dump(struct cmd_tbl *cmdtp, int
flag,
u16 *var_name16, *p;
efi_uintn_t buf_size, size;
efi_guid_t guid;
- int id, i, digit;
efi_status_t ret;
if (argc > 1)
@@ -1074,16 +1062,7 @@ static int do_efi_boot_dump(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_FAILURE;
}
- if (memcmp(var_name16, u"Boot", 8))
- continue;
-
- for (id = 0, i = 0; i < 4; i++) {
- digit = u16_tohex(var_name16[4 + i]);
- if (digit < 0)
- break;
- id = (id << 4) + digit;
- }
- if (i == 4 && !var_name16[8])
+ if (efi_varname_is_load_option(var_name16, NULL))
show_efi_boot_opt(var_name16);
}
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0c6c95ba46..b1ded811e7 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -707,6 +707,8 @@ int algo_to_len(const char *algo);
int efi_link_dev(efi_handle_t handle, struct udevice *dev);
int efi_unlink_dev(efi_handle_t handle);
+int u16_tohex(u16 c);
+bool efi_varname_is_load_option(u16 *var_name16, int *index);
/**
* efi_size_in_pages() - convert size in bytes to size in pages
diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
index c71e87d118..8a7afcc381 100644
--- a/lib/efi_loader/efi_helper.c
+++ b/lib/efi_loader/efi_helper.c
@@ -190,3 +190,36 @@ int efi_unlink_dev(efi_handle_t handle)
return 0;
}
+
+int u16_tohex(u16 c)
+{
+ if (c >= '0' && c <= '9')
+ return c - '0';
+ if (c >= 'A' && c <= 'F')
+ return c - 'A' + 10;
+
+ /* not hexadecimal */
+ return -1;
+}
+
+bool efi_varname_is_load_option(u16 *var_name16, int *index)
+{
+ int id, i, digit;
+
+ if (memcmp(var_name16, u"Boot", 8))
+ return false;
+
+ for (id = 0, i = 0; i < 4; i++) {
+ digit = u16_tohex(var_name16[4 + i]);
+ if (digit < 0)
+ break;
+ id = (id << 4) + digit;
+ }
+ if (i == 4 && !var_name16[8]) {
+ if (index)
+ *index = id;
+ return true;
+ }
+
+ return false;
+}
--
2.17.1
[PATCH v2 2/5] eficonfig: use u16_strsize() to get u16 string buffer size
Use u16_strsize() to simplify the u16 string buffer size calculation. Signed-off-by: Masahisa Kojima Reviewed-by: Heinrich Schuchardt --- No update since v1. cmd/eficonfig.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c index 5529edc85e..88d507d04c 100644 --- a/cmd/eficonfig.c +++ b/cmd/eficonfig.c @@ -452,8 +452,7 @@ struct efi_device_path *eficonfig_create_device_path(struct efi_device_path *dp_ struct efi_device_path *dp; struct efi_device_path_file_path *fp; - fp_size = sizeof(struct efi_device_path) + - ((u16_strlen(current_path) + 1) * sizeof(u16)); + fp_size = sizeof(struct efi_device_path) + u16_strsize(current_path); buf = calloc(1, fp_size + sizeof(END)); if (!buf) return NULL; -- 2.17.1
[PATCH v2 1/5] eficonfig: fix going one directory up issue
The directory name in eficonfig menu entry contains the
'\' separator. strcmp() argument ".." is wrong and one directory
up handling does not work correctly. strcmp() argument must
include '\' separator.
Signed-off-by: Masahisa Kojima
---
No change since v1
cmd/eficonfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 97d35597a2..5529edc85e 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -488,7 +488,7 @@ static efi_status_t eficonfig_file_selected(void *data)
if (!info)
return EFI_INVALID_PARAMETER;
- if (!strcmp(info->file_name, "..")) {
+ if (!strcmp(info->file_name, "..\\")) {
struct eficonfig_filepath_info *iter;
struct list_head *pos, *n;
int is_last;
--
2.17.1
[PATCH v2 0/5] miscellaneous fixes of eficonfig
This series includes bugfix, refactoring and documentation updates. Masahisa Kojima (5): eficonfig: fix going one directory up issue eficonfig: use u16_strsize() to get u16 string buffer size efi_loader: utility function to check the variable name is "Boot" eficonfig: use efi_get_next_variable_name_int() doc:eficonfig: add description for UEFI Secure Boot Configuration cmd/eficonfig.c | 146 +--- cmd/efidebug.c | 23 +- doc/usage/cmd/eficonfig.rst | 22 ++ include/efi_loader.h| 2 + lib/efi_loader/efi_helper.c | 33 5 files changed, 177 insertions(+), 49 deletions(-) -- 2.17.1
Re: [PATCH] xilinx: Add option to select SC id instead of DUT id for SC support
st 23. 11. 2022 v 12:49 odesílatel Michal Simek napsal:
>
> Reading MAC address from on board EEPROM requires different type for System
> Controller (SC).
>
> Signed-off-by: Michal Simek
> ---
>
> 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_OFFSET4
> #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_FIELDS5
> 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
>
Applied.
M
--
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 ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] xilinx: Remove unused ZYNQ_MAC_IN_EEPROM/ZYNQ_GEM_I2C_MAC_OFFSET entries
st 23. 11. 2022 v 9:27 odesílatel Michal Simek napsal:
>
> 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
> ---
>
> 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=0x800
> 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=0x20
> 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=0x1E8
> 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=0x800
> --
> 2.36.1
>
Applied.
M
--
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 ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] spi: zynqmp_qspi: Add support for 64-bit read/write
pá 25. 11. 2022 v 15:00 odesílatel Venkatesh Yadav Abbarapu
napsal:
>
> 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
> ---
>
> 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
>
Applied.
M
--
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 ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] arm64: versal: Enable REMAKE_ELF for mini_ospi/mini_qspi
pá 25. 11. 2022 v 15:00 odesílatel Venkatesh Yadav Abbarapu
napsal:
>
> 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
> ---
>
> 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=0x800
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xFFFE
> # 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=0x800
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xFFFE
> # 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
>
Applied.
M
--
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 ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PULL] u-boot-usb/master
The following changes since commit 27c415ae8b743710e412ef408b52894af68141c6: Merge branch '2022-11-23-assorted-fixes' (2022-11-24 16:31:02 -0500) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to db5bace4f6cb37251a5863efe4c0c1547d1334bd: usb: dwc3: Drop support for "snps, ref-clock-period-ns" DT property (2022-11-27 15:34:56 +0100) Balaji Prakash J (1): usb: dwc3: reference clock period configuration Marek Vasut (3): usb: Expand buffer size in usb_find_and_bind_driver() usb: dwc3: Cache ref_clk pointer in struct dwc3 usb: dwc3: Drop support for "snps, ref-clock-period-ns" DT property Sean Anderson (2): usb: dwc3: Calculate REFCLKPER based on reference clock usb: dwc3: Program GFLADJ drivers/usb/dwc3/core.c | 75 +++ drivers/usb/dwc3/core.h | 12 drivers/usb/dwc3/dwc3-generic.c | 9 + drivers/usb/host/usb-uclass.c | 2 +- 4 files changed, 97 insertions(+), 1 deletion(-)
Re: [Uboot-stm32] [PATCH] dfu: mtd: mark bad the MTD block on erase error
Hi Patrick
On 11/28/22 10:22, Patrick Delaunay wrote:
> In the MTD DFU backend, it is needed to mark the NAND block bad when the
> erase failed with the -EIO error, as it is done in UBI and JFFS2 code.
>
> This operation is not done in the MTD framework, but the bad block
> tag (in BBM or in BBT) is required to avoid to write data on this block
> in the next DFU_OP_WRITE loop in mtd_block_op(): the code skip the bad
> blocks, tested by mtd_block_isbad().
>
> Without this patch, when the NAND block become bad on DFU write operation
> - low probability on new NAND - the DFU write operation will always failed
> because the failing block is never marked bad.
>
> This patch also adds a test to avoid to request an erase operation on a
> block already marked bad; this test is not performed in MTD framework
> in mtd_erase().
>
> Signed-off-by: Patrick Delaunay
> ---
>
> drivers/dfu/dfu_mtd.c | 26 ++
> 1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
> index c7075f12eca9..4fb02c4c806c 100644
> --- a/drivers/dfu/dfu_mtd.c
> +++ b/drivers/dfu/dfu_mtd.c
> @@ -91,22 +91,32 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity
> *dfu,
> return -EIO;
> }
>
> + /* Skip the block if it is bad, don't erase it again */
> + if (mtd_block_isbad(mtd, off)) {
> + erase_op.addr += mtd->erasesize;
> + continue;
> + }
> +
> ret = mtd_erase(mtd, &erase_op);
>
> if (ret) {
> - /* Abort if its not a bad block error */
> - if (ret != -EIO) {
> - printf("Failure while erasing at offset
> 0x%llx\n",
> -erase_op.fail_addr);
> - return 0;
> + /* If this is not -EIO, we have no idea what to
> do. */
> + if (ret == -EIO) {
> + printf("Marking bad block at 0x%08llx
> (%d)\n",
> +erase_op.fail_addr, ret);
> + ret = mtd_block_markbad(mtd,
> erase_op.addr);
> + }
> + /* Abort if it is not -EIO or can't mark bad */
> + if (ret) {
> + printf("Failure while erasing at offset
> 0x%llx (%d)\n",
> +erase_op.fail_addr, ret);
> + return ret;
> }
> - printf("Skipping bad block at 0x%08llx\n",
> -erase_op.addr);
> } else {
> remaining -= mtd->erasesize;
> }
>
> - /* Continue erase behind bad block */
> + /* Continue erase behind the current block */
> erase_op.addr += mtd->erasesize;
> }
> }
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH] Prevent buffer overflow on USB control endpoint
On 11/28/22 10:21, Szymon Heidrich wrote:
On 20/11/2022 16:29, Szymon Heidrich wrote:
On 20/11/2022 15:43, Marek Vasut wrote:
On 11/17/22 12:50, Fabio Estevam wrote:
[Adding Lukasz and Marek]
On Thu, Nov 17, 2022 at 6:50 AM Szymon Heidrich
wrote:
Assure that the control endpoint buffer of size USB_BUFSIZ (4096)
can not be overflown during handling of USB control transfer
requests with wLength greater than USB_BUFSIZ.
Signed-off-by: Szymon Heidrich
---
drivers/usb/gadget/composite.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 2a309e624e..cb89f6dca9 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1019,6 +1019,17 @@ composite_setup(struct usb_gadget *gadget, const struct
usb_ctrlrequest *ctrl)
u8 endp;
struct usb_configuration *c;
+ if (w_length > USB_BUFSIZ) {
+ if (ctrl->bRequestType & USB_DIR_IN) {
+ /* Cast away the const, we are going to overwrite on
purpose. */
+ __le16 *temp = (__le16 *)&ctrl->wLength;
+ *temp = cpu_to_le16(USB_BUFSIZ);
+ w_length = USB_BUFSIZ;
Won't this end up sending corrupted packets in case they are longer than
USB_BUFSIZ ?
Where do such long packets come from ?
What is the test-case ?
The USB host will not attempt to retrieve more than wLenght bytes during
transfer phase.
If the device would erroneously attempt to provide more data it would result in
an unexpected state.
In case of most implementations the buffer for endpoint 0 along with max
control transfer is limited to 4096 bytes (USB_BUFSIZ for U-Boot and Linux
kernel).
Still according to the USB specification wLength is two bytes an the device may
receive requests with wLength larger than 4096 bytes e.g. in case of a
custom/malicious USB host.
For example one may build libusb with MAX_CTRL_BUFFER_LENGTH altered to 0x
and this will allow the host to send requests with wLength up to 0x.
In this case the original implementation may result in buffer overflows as in
multiple locations a value directly derived from wLength is set as the transfer
phase length.
With the change applied IN requests with wLength larger than USB_BUFSIZ will be
trimmed to USB_BUFSIZ, otherwise the host would read wLength-USB_BUFSIZ past
cdev->req->buf.
I am not aware of any cases where more than USB_BUFSIZ would be provided from a
buffer other than cdev->req->buf. In case I missed such case please let me know.
Is there anything additional required from my side?
Sorry for the delay, I am still processing outstanding email.
Re: [PATCH 2/2] adc: stm32mp15: add support of generic channels binding
Hi,
On 11/23/22 16:20, Olivier Moysan wrote:
Add support of generic IIO channels binding:
./devicetree/bindings/iio/adc/adc.yaml
Keep support of st,adc-channels for backward compatibility.
Signed-off-by: Olivier Moysan
---
drivers/adc/stm32-adc.c | 51 -
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/adc/stm32-adc.c b/drivers/adc/stm32-adc.c
index 1250385fbb92..85efc119dbf1 100644
--- a/drivers/adc/stm32-adc.c
+++ b/drivers/adc/stm32-adc.c
@@ -200,24 +200,63 @@ static int stm32_adc_legacy_chan_init(struct udevice
*dev, unsigned int num_chan
return ret;
}
+static int stm32_adc_generic_chan_init(struct udevice *dev, unsigned int num_channels)
+{
+ struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
+ struct stm32_adc *adc = dev_get_priv(dev);
+ ofnode child;
+ int val, ret;
+
+ ofnode_for_each_subnode(child, dev_ofnode(dev)) {
+ ret = ofnode_read_u32(child, "reg", &val);
+ if (ret) {
+ dev_err(dev, "Missing channel index %d\n", ret);
+ return ret;
+ }
+
+ if (val >= adc->cfg->max_channels) {
+ dev_err(dev, "Invalid channel %d\n", val);
+ return -EINVAL;
+ }
+
+ uc_pdata->channel_mask |= 1 << val;
+ }
+
+ return 0;
+}
+
static int stm32_adc_chan_of_init(struct udevice *dev)
{
struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
struct stm32_adc *adc = dev_get_priv(dev);
unsigned int num_channels;
int ret;
-
- ret = stm32_adc_get_legacy_chan_count(dev);
- if (ret < 0)
- return ret;
- num_channels = ret;
+ bool legacy = false;
+
+ num_channels = dev_get_child_count(dev);
+ /* If no channels have been found, fallback to channels legacy
properties. */
+ if (!num_channels) {
+ legacy = true;
+
+ ret = stm32_adc_get_legacy_chan_count(dev);
+ if (!ret) {
+ dev_err(dev, "No channel found\n");
+ return -ENODATA;
+ } else if (ret < 0) {
+ return ret;
+ }
+ num_channels = ret;
+ }
if (num_channels > adc->cfg->max_channels) {
dev_err(dev, "too many st,adc-channels: %d\n", num_channels);
return -EINVAL;
}
- ret = stm32_adc_legacy_chan_init(dev, num_channels);
+ if (legacy)
+ ret = stm32_adc_legacy_chan_init(dev, num_channels);
+ else
+ ret = stm32_adc_generic_chan_init(dev, num_channels);
if (ret < 0)
return ret;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 1/2] adc: stm32mp15: split channel init into several routines
Hi,
On 11/23/22 16:20, Olivier Moysan wrote:
Split stm32_adc_chan_of_init channel initialization function into
several routines to increase readability and prepare channel
generic binding handling.
Signed-off-by: Olivier Moysan
---
drivers/adc/stm32-adc.c | 44 +++--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/adc/stm32-adc.c b/drivers/adc/stm32-adc.c
index ad8d1a32cdba..1250385fbb92 100644
--- a/drivers/adc/stm32-adc.c
+++ b/drivers/adc/stm32-adc.c
@@ -162,12 +162,8 @@ static int stm32_adc_channel_data(struct udevice *dev, int
channel,
return 0;
}
-static int stm32_adc_chan_of_init(struct udevice *dev)
+static int stm32_adc_get_legacy_chan_count(struct udevice *dev)
{
- struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
- struct stm32_adc *adc = dev_get_priv(dev);
- u32 chans[STM32_ADC_CH_MAX];
- unsigned int i, num_channels;
int ret;
/* Retrieve single ended channels listed in device tree */
@@ -176,12 +172,16 @@ static int stm32_adc_chan_of_init(struct udevice *dev)
dev_err(dev, "can't get st,adc-channels: %d\n", ret);
return ret;
}
- num_channels = ret / sizeof(u32);
- if (num_channels > adc->cfg->max_channels) {
- dev_err(dev, "too many st,adc-channels: %d\n", num_channels);
- return -EINVAL;
- }
+ return (ret / sizeof(u32));
+}
+
+static int stm32_adc_legacy_chan_init(struct udevice *dev, unsigned int
num_channels)
+{
+ struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
+ struct stm32_adc *adc = dev_get_priv(dev);
+ u32 chans[STM32_ADC_CH_MAX];
+ int i, ret;
ret = dev_read_u32_array(dev, "st,adc-channels", chans, num_channels);
if (ret < 0) {
@@ -197,6 +197,30 @@ static int stm32_adc_chan_of_init(struct udevice *dev)
uc_pdata->channel_mask |= 1 << chans[i];
}
+ return ret;
+}
+
+static int stm32_adc_chan_of_init(struct udevice *dev)
+{
+ struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
+ struct stm32_adc *adc = dev_get_priv(dev);
+ unsigned int num_channels;
+ int ret;
+
+ ret = stm32_adc_get_legacy_chan_count(dev);
+ if (ret < 0)
+ return ret;
+ num_channels = ret;
+
+ if (num_channels > adc->cfg->max_channels) {
+ dev_err(dev, "too many st,adc-channels: %d\n", num_channels);
+ return -EINVAL;
+ }
+
+ ret = stm32_adc_legacy_chan_init(dev, num_channels);
+ if (ret < 0)
+ return ret;
+
uc_pdata->data_mask = (1 << adc->cfg->num_bits) - 1;
uc_pdata->data_format = ADC_DATA_FORMAT_BIN;
uc_pdata->data_timeout_us = 10;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 00/17] Support android boot image v3/v4
On Sat, Nov 26, 2022 at 17:59, Safae Ouajih wrote: > Hello everyone, > > * This is based on Roman Stratiienko's work to support boot image header > version 3 and 4. > > * This supports the new boot image headers v3, v4 and bootconfig feature. > https://source.android.com/docs/core/architecture/bootloader/boot-image-header > https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig > > - Tested on Amlogic Khadas vim3l, a reference board for Android Open Source > Project > https://www.khadas.com/vim3l > > And on AM625 Texas Instruments board with 5.10 linux kernel > > Main changes : > - New partition : vendor boot, with a specific vendor ramdisk > - DTB is stored in the vendor boot partition > - The generic ramdisk is placed after the vendor ramdisk > - Bootconfig feature support > > > Here is a link to see the related android boot flow changes on KHADAS vim3l > as an example: > https://gitlab.baylibre.com/baylibre/amlogic/atv/u-boot/-/commits/souajih/BootImagev4/ Tested the whole series on Khadas vim3l board with boot header v2. Tested-by: Mattijs Korpershoek > > Safae Ouajih (17): > android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0_v1_v2 > android: boot: support vendor boot image in abootimg > android: boot: replace android_image_check_header > android: boot: add boot image header v3 and v4 structures > android: boot: add documentation for boot image header v3/v4 structure > android: boot: kcomp: support andr_image_data > android: boot: move to andr_image_data structure > android: boot: content print is not supported for v3,v4 header version > android: boot: boot image header v3,v4 do not support recovery DTBO > android: boot: add vendor boot image to prepare for v3,v4 support > android: boot: update android_image_get_data to support v3,v4 > android: boot: ramdisk: support vendor ramdisk > android: boot: support extra command line > drivers: fastboot: zImage flashing is not supported for v3,v4 > android: boot: support boot image header version 3 and 4 > lib: support libxbc > android: boot: support bootconfig > > boot/bootm.c | 29 ++- > boot/image-android.c | 367 ++ > boot/image-board.c| 15 +- > boot/image-fdt.c | 5 +- > cmd/abootimg.c| 66 --- > drivers/fastboot/fb_mmc.c | 19 +- > include/android_image.h | 220 ++- > include/image.h | 37 ++-- > include/xbc.h | 1 + > lib/Kconfig | 12 ++ > lib/Makefile | 1 + > lib/libxbc/Makefile | 1 + > lib/libxbc/libxbc.c | 112 > lib/libxbc/libxbc.h | 54 ++ > 14 files changed, 806 insertions(+), 133 deletions(-) > create mode 100644 include/xbc.h > create mode 100644 lib/libxbc/Makefile > create mode 100644 lib/libxbc/libxbc.c > create mode 100644 lib/libxbc/libxbc.h > > -- > 2.25.1
[PATCH] dfu: mtd: mark bad the MTD block on erase error
In the MTD DFU backend, it is needed to mark the NAND block bad when the
erase failed with the -EIO error, as it is done in UBI and JFFS2 code.
This operation is not done in the MTD framework, but the bad block
tag (in BBM or in BBT) is required to avoid to write data on this block
in the next DFU_OP_WRITE loop in mtd_block_op(): the code skip the bad
blocks, tested by mtd_block_isbad().
Without this patch, when the NAND block become bad on DFU write operation
- low probability on new NAND - the DFU write operation will always failed
because the failing block is never marked bad.
This patch also adds a test to avoid to request an erase operation on a
block already marked bad; this test is not performed in MTD framework
in mtd_erase().
Signed-off-by: Patrick Delaunay
---
drivers/dfu/dfu_mtd.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
index c7075f12eca9..4fb02c4c806c 100644
--- a/drivers/dfu/dfu_mtd.c
+++ b/drivers/dfu/dfu_mtd.c
@@ -91,22 +91,32 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity
*dfu,
return -EIO;
}
+ /* Skip the block if it is bad, don't erase it again */
+ if (mtd_block_isbad(mtd, off)) {
+ erase_op.addr += mtd->erasesize;
+ continue;
+ }
+
ret = mtd_erase(mtd, &erase_op);
if (ret) {
- /* Abort if its not a bad block error */
- if (ret != -EIO) {
- printf("Failure while erasing at offset
0x%llx\n",
- erase_op.fail_addr);
- return 0;
+ /* If this is not -EIO, we have no idea what to
do. */
+ if (ret == -EIO) {
+ printf("Marking bad block at 0x%08llx
(%d)\n",
+ erase_op.fail_addr, ret);
+ ret = mtd_block_markbad(mtd,
erase_op.addr);
+ }
+ /* Abort if it is not -EIO or can't mark bad */
+ if (ret) {
+ printf("Failure while erasing at offset
0x%llx (%d)\n",
+ erase_op.fail_addr, ret);
+ return ret;
}
- printf("Skipping bad block at 0x%08llx\n",
- erase_op.addr);
} else {
remaining -= mtd->erasesize;
}
- /* Continue erase behind bad block */
+ /* Continue erase behind the current block */
erase_op.addr += mtd->erasesize;
}
}
--
2.25.1
Re: [PATCH] Prevent buffer overflow on USB control endpoint
On 20/11/2022 16:29, Szymon Heidrich wrote:
> On 20/11/2022 15:43, Marek Vasut wrote:
>> On 11/17/22 12:50, Fabio Estevam wrote:
>>> [Adding Lukasz and Marek]
>>>
>>> On Thu, Nov 17, 2022 at 6:50 AM Szymon Heidrich
>>> wrote:
Assure that the control endpoint buffer of size USB_BUFSIZ (4096)
can not be overflown during handling of USB control transfer
requests with wLength greater than USB_BUFSIZ.
Signed-off-by: Szymon Heidrich
---
drivers/usb/gadget/composite.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c
index 2a309e624e..cb89f6dca9 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1019,6 +1019,17 @@ composite_setup(struct usb_gadget *gadget, const
struct usb_ctrlrequest *ctrl)
u8 endp;
struct usb_configuration *c;
+ if (w_length > USB_BUFSIZ) {
+ if (ctrl->bRequestType & USB_DIR_IN) {
+ /* Cast away the const, we are going to overwrite
on purpose. */
+ __le16 *temp = (__le16 *)&ctrl->wLength;
+ *temp = cpu_to_le16(USB_BUFSIZ);
+ w_length = USB_BUFSIZ;
>>
>> Won't this end up sending corrupted packets in case they are longer than
>> USB_BUFSIZ ?
>>
>> Where do such long packets come from ?
>>
>> What is the test-case ?
>
> The USB host will not attempt to retrieve more than wLenght bytes during
> transfer phase.
> If the device would erroneously attempt to provide more data it would result
> in an unexpected state.
> In case of most implementations the buffer for endpoint 0 along with max
> control transfer is limited to 4096 bytes (USB_BUFSIZ for U-Boot and Linux
> kernel).
> Still according to the USB specification wLength is two bytes an the device
> may receive requests with wLength larger than 4096 bytes e.g. in case of a
> custom/malicious USB host.
> For example one may build libusb with MAX_CTRL_BUFFER_LENGTH altered to
> 0x and this will allow the host to send requests with wLength up to
> 0x.
> In this case the original implementation may result in buffer overflows as in
> multiple locations a value directly derived from wLength is set as the
> transfer phase length.
> With the change applied IN requests with wLength larger than USB_BUFSIZ will
> be trimmed to USB_BUFSIZ, otherwise the host would read wLength-USB_BUFSIZ
> past cdev->req->buf.
> I am not aware of any cases where more than USB_BUFSIZ would be provided from
> a buffer other than cdev->req->buf. In case I missed such case please let me
> know.
Is there anything additional required from my side?
Re: [PATCH] patman: Switch to setuptools
On Mon, 28 Nov 2022 at 10:55, Sean Anderson wrote: > > distutils is about to meet its demise [1]. Switch to setuptools. > > [1] https://peps.python.org/pep-0632/ > > Signed-off-by: Sean Anderson > --- > > tools/patman/setup.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
[PATCH v5 1/1] u-boot-initial-env: rework make target
From: Max Krummenacher
With LTO enabled the U-Boot initial environment is no longer stored
in an easy accessible section in env/common.o. I.e. the section name
changes from build to build, its content maybe compressed and it is
annotated with additional data.
Drop trying to read the initial env with elf tools from the compiler
specific object file in favour of adding and using a host tool with
the only functionality of printing the initial env to stdout.
See also:
https://lore.kernel.org/all/927b122e-1f62-e790-f5ca-30bae4332...@foss.st.com/
Signed-off-by: Max Krummenacher
Acked-by: Pali Rohár
---
Changes in v5:
- don't build the printinitialenv tool unconditionally but build it
only as part of the u-boot-initial-env target.
This no longer fails the 'make tools-only_defconfig tools-only'
use-case which is reported by Tom Rini.
Adding the $(env_h) dependencies to the tools target might give
circular dependencies issues with some future tool.
- add Acked-by: Pali Rohár
Changes in v4:
- add '(objtree)/' when calling the tool. Suggested by Pali Rohár.
- renamed patch, as more than just the Makefile has changes
Changes in v3:
- moved the tool from scripts/ to tools/. Suggested by Tom Rini
- changed the dependencies to '$(env_h)' and 'tools'.
Suggested by Tom Rini and Pali Rohár.
- removed the sed rule which replaces \x00 with \x0A as this is already
done by the tool. Suggested by Pali Rohár.
Changes in v2:
- reworked to build a host tool which prints the configured
environment as proposed by Pali Rohár
https://lore.kernel.org/u-boot/20221018174827.1393211-1-max.oss...@gmail.com/
- renamed patch, v1 used "Makefile: fix u-boot-initial-env target if lto is
enabled"
Makefile| 10 ++
tools/.gitignore| 1 +
tools/Makefile | 4
tools/printinitialenv.c | 44 +
4 files changed, 55 insertions(+), 4 deletions(-)
create mode 100644 tools/printinitialenv.c
diff --git a/Makefile b/Makefile
index 2d24ac3959f..32e4bef10f5 100644
--- a/Makefile
+++ b/Makefile
@@ -2439,11 +2439,13 @@ endif
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
quiet_cmd_genenv = GENENV $@
-cmd_genenv = $(OBJCOPY) --dump-section .rodata.default_environment=$@
env/common.o; \
- sed --in-place -e 's/\x00/\x0A/g' $@; sed --in-place -e '/^\s*$$/d' $@;
\
- sort --field-separator== -k1,1 --stable $@ -o $@
+cmd_genenv = \
+ $(objtree)/tools/printinitialenv | \
+ sed -e '/^\s*$$/d' | \
+ sort --field-separator== -k1,1 --stable -o $@
-u-boot-initial-env: u-boot.bin
+u-boot-initial-env: $(env_h) FORCE
+ $(Q)$(MAKE) $(build)=tools $(objtree)/tools/printinitialenv
$(call if_changed,genenv)
# Consistency checks
diff --git a/tools/.gitignore b/tools/.gitignore
index d3a93ff294a..28e8ce2a07a 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -28,6 +28,7 @@
/mxsboot
/ncb
/prelink-riscv
+/printinitialenv
/proftool
/relocate-rela
/spl_size_limit
diff --git a/tools/Makefile b/tools/Makefile
index 26be0a7ba2e..80bc62befcb 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -275,6 +275,10 @@ clean-dirs := lib common
always := $(hostprogs-y)
+# Host tool to dump the currently configured default environment,
+# build it on demand, i.e. not add it to 'always'.
+hostprogs-y += printinitialenv
+
# Generated LCD/video logo
LOGO_H = $(objtree)/include/bmp_logo.h
LOGO_DATA_H = $(objtree)/include/bmp_logo_data.h
diff --git a/tools/printinitialenv.c b/tools/printinitialenv.c
new file mode 100644
index 000..c58b234d679
--- /dev/null
+++ b/tools/printinitialenv.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Max Krummenacher, Toradex
+ *
+ * Snippets taken from tools/env/fw_env.c
+ *
+ * This prints the list of default environment variables as currently
+ * configured.
+ *
+ */
+
+#include
+
+/* Pull in the current config to define the default environment */
+#include
+
+#ifndef __ASSEMBLY__
+#define __ASSEMBLY__ /* get only #defines from config.h */
+#include
+#undef __ASSEMBLY__
+#else
+#include
+#endif
+
+#define DEFAULT_ENV_INSTANCE_STATIC
+#include
+#include
+
+int main(void)
+{
+ char *env, *nxt;
+
+ for (env = default_environment; *env; env = nxt + 1) {
+ for (nxt = env; *nxt; ++nxt) {
+ if (nxt >=
&default_environment[sizeof(default_environment)]) {
+ fprintf(stderr, "## Error: environment not
terminated\n");
+ return -1;
+ }
+ }
+ printf("%s\n", env);
+ }
+ return 0;
+}
--
2.35.3
[PATCH v5 0/1] Makefile: rework u-boot-initial-env target
From: Max Krummenacher With CONFIG_LTO enabled the current way of extracting the configured environment no longer works, i.e. the object file content changes due to LTO. Build a host tool which prints the configured environment instead of using objcopy and friends to achive the same. The code and Makefile changes were mostly stolen from tools/env/ i.e. the target userspace tools to access the environment. Changes in v5: - don't build the printinitialenv tool unconditionally but build it only as part of the u-boot-initial-env target. This no longer fails the 'make tools-only_defconfig tools-only' use-case which is reported by Tom Rini. Adding the $(env_h) dependencies to the tools target might give circular dependencies issues with some future tool. - add Acked-by: Pali Rohár Changes in v4: - add '(objtree)/' when calling the tool. Suggested by Pali Rohár. - renamed patch, as more than just the Makefile has changes Changes in v3: - moved the tool from scripts/ to tools/. Suggested by Tom Rini - changed the dependencies to '$(env_h)' and 'tools'. Suggested by Tom Rini and Pali Rohár. - removed the sed rule which replaces \x00 with \x0A as this is already done by the tool. Suggested by Pali Rohár. Changes in v2: - reworked to build a host tool which prints the configured environment as proposed by Pali Rohár https://lore.kernel.org/u-boot/20221018174827.1393211-1-max.oss...@gmail.com/ - renamed patch, v1 used "Makefile: fix u-boot-initial-env target if lto is enabled" Max Krummenacher (1): u-boot-initial-env: rework make target Makefile| 10 ++ tools/.gitignore| 1 + tools/Makefile | 4 tools/printinitialenv.c | 44 + 4 files changed, 55 insertions(+), 4 deletions(-) create mode 100644 tools/printinitialenv.c -- 2.35.3
Re: [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments
Hi Rafal, mich...@walle.cc wrote on Mon, 28 Nov 2022 08:35:24 +0100: > Am 2022-11-28 07:59, schrieb Rafał Miłecki: > > From: Rafał Miłecki > > > > 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. Michael's series brings read_post_process, isn't what you need here? > > > > 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 > > --- > > 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-mich...@walle.cc/ > > > > 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. Yeah, I guess since Michael's series has been out for 2 years and we finally agreed on the bindings plus some implementation points, I would expect it to be merged very soon (I don't know if Srinivas still plans to take it for this release or for the next?) unless someone speaks up against it. > As yours should be easily added on top of my series. I've showed that > providing a global post process hook is bad because that way you need > to have *all* cells of your device read-only. > > -michael Thanks, Miquèl
Re: [PATCH 0/6] broken CVE fix (b85d130ea0ca)
On 17/11/2022 01.32, Fabio Estevam wrote: > On Mon, Nov 14, 2022 at 10:04 AM Tom Rini wrote: >> >> On Mon, Nov 14, 2022 at 10:35:51AM +0100, Rasmus Villemoes wrote: >>> On 14/10/2022 19.43, Rasmus Villemoes wrote: tl;dr: b85d130ea0ca didn't fix the CVE(s), but did break tftp of certain file sizes - which is somewhat lucky, since that's how I noticed in the first place. >>> >>> At this point it seems unlikely that any more comments or reviews will >>> come, so perhaps its time to get these (all 7) merged to master, so that >>> they will get some wider testing before the January release? >> >> Yes, I'd like to see a net PR with this and perhaps a few other mature >> things? > > Ramon, Joe? Ping. If those two CVEs and the tftp brokenness are to get fixed in 2023.01, now is the time to pull in these patches, or provide a viable alternative.
Re: [PATCH v2 3/3] board: imx8mp: Add Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit
On 2022-08-26 14:33, Manoj Sai wrote: diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h index 388f3bc9ff..140eba3d1c 100644 --- a/include/configs/imx8mp_evk.h +++ b/include/configs/imx8mp_evk.h @@ -55,11 +55,9 @@ #define CONFIG_SYS_INIT_RAM_SIZE 0x8 -/* Totally 6GB DDR */ +/* Totally 2GB DDR */ #define CONFIG_SYS_SDRAM_BASE 0x4000 #define PHYS_SDRAM0x4000 -#define PHYS_SDRAM_SIZE0xC000 /* 3 GB */ -#define PHYS_SDRAM_2 0x1 -#define PHYS_SDRAM_2_SIZE 0xC000 /* 3 GB */ +#define PHYS_SDRAM_SIZE0x8000 #endif This patch is applied on master branch since a while, commit 864ac2cf383e4b8008f09db2e7e53318093c431e. Why does it change RAM size for NXP's i.Mx8mp EVK from 6GB->2GB? The patch is aimed to add a new board not to change an existing one. Best regards, /Peter
