Re: [PATCH v2 1/3] efi_loader: Add SPI I/O protocol support
On 9/12/22 18:14, Paul Barker wrote: Hi Heinrich, I'm sending a ping on this as there were a few questions in my response to your feedback and I'd like to move this forward. I've highlighted the key items with further comments below. On 25/08/2022 11:58, Paul Barker wrote: Hi Henrich, Many thanks for your review on this patch. I've responded to things inline below. I'm also available on IRC (paulbarker) if you want to discuss further. On 13/08/2022 20:20, Heinrich Schuchardt wrote: On 8/4/22 12:34, Paul Barker wrote: This addition allows UEFI applications running under u-boot to access peripherals on SPI busses. It is based on the UEFI Platform Initialization (PI) Specification, Version 1.7 Errata A (April 2020). Only the core functionality required to discover SPI peripherals and communicate with them is currently implemented. Other functionality such as the legacy SPI controller interface and the ability to update the SPI peripheral object associated with a particular SPI I/O protocol object is currently unimplemented. Since there are no open source implementations of this protocol to use as an example, educated guesses/hacks have been made in cases where the UEFI PI specification is unclear and these are documented in comments. This implementation has been tested on the SanCloud BBE Lite and allowed a UEFI test application to successfully communicate with a Micron Authenta flash device connected via the SPI bus. It has also been tested with the sandbox target using the included efi_selftest case. The commit message should describe which protocols are actually implemented. I'll add this to the commit message in v3. I still have no clue why any PI protocol should be implemented U-Boot. You neither descibe it here nor in the cover-letter. Implementing the SPI I/O protocol allows a UEFI application running under u-boot to enumerate and communicate with devices on the SPI bus. This protocol fulfils the same purpose as the "SD MMC Pass Thru Protocol" and "NVM Express Pass Through Protocol" described in the main UEFI spec, I'm unsure why SPI bus access was deferred to the PI spec. If these patches are accepted we plan to also implement the SD/MMC and NVMe I/O protocols. The broader goal here is to support better encapsulation of "pre-boot" application code which needs to communicate with a SPI, MMC or NVMe devices before Linux is booted. This pre-boot application can then run on both embedded devices running u-boot and PC-like devices running a UEFI BIOS. In our case the application will interact with the Authenta flash security features to verify integrity and to generate ephemeral keys based on the flash contents. Our application links against mbedtls and so it would be non-trivial (in terms of both implementation and licensing) to integrate this directly into u-boot. We have previously explored using the "standalone" application support (e.g. in examples/standalone in the u-boot source) but as that is not well maintained we have moved to a UEFI implementation. Let me know if you need any more info than that. Once you're happy with the explanation I'll add it to the cover letter in v3. Could you let me know if this is sufficient? Thanks to linking this to Authenta flash, cf. https://www.micron.com/-/media/client/global/documents/products/product-flyer/authenta_technology_solutions_brief.pdf The other answers where also helpfule to better undestand this patch. Please, send v3 and the we can add this functionality. Best regards Heinrich I would expect capsule updates to be used to update the SPI flash. Our application is not intended to perform firmware or capsule updates or to make any writes to the flash. Signed-off-by: Paul Barker --- MAINTAINERS | 7 + arch/sandbox/dts/test.dts | 8 + include/efi_loader.h | 4 + include/efi_spi_protocol.h | 158 + lib/efi_loader/Kconfig | 8 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_setup.c | 6 + lib/efi_loader/efi_spi_protocol.c | 614 +++ lib/efi_selftest/Makefile | 1 + lib/efi_selftest/efi_selftest_spi_protocol.c | 237 +++ 10 files changed, 1044 insertions(+) create mode 100644 include/efi_spi_protocol.h create mode 100644 lib/efi_loader/efi_spi_protocol.c create mode 100644 lib/efi_selftest/efi_selftest_spi_protocol.c diff --git a/MAINTAINERS b/MAINTAINERS index 4d1930f76e44..1b5d9c37576b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -856,6 +856,13 @@ F: tools/efivar.py F: tools/file2include.c F: tools/mkeficapsule.c +EFI SPI SUPPORT +M: Paul Barker +S: Maintained +F: include/efi_spi_protocol.h +F: lib/efi_loader/efi_spi_protocol.c +F: lib/efi_selftest/efi_selftest_spi_protocol.c + EFI VARIABLES VIA OP-TEE M: Ilias Apalodimas S: Ma
Re: [PATCH] imx8mq_evk: enlarge SYS_MALLOC_F_LEN
Hi, Am Mi., 14. Sept. 2022 um 06:12 Uhr schrieb Heiko Thiery : > > Hi, > > Am Mi., 14. Sept. 2022 um 03:38 Uhr schrieb Peng Fan (OSS) > : > > > > From: Peng Fan > > > > There is "alloc space exhausted" with DEBUG_UART enabled with the > > options enabled. I don't think the explanation is right. The alloc problem is also there if you don't enable DEBUG_UART. But only with enabled DEBUG_UART you can see the output message(s). > > > > CONFIG_DEBUG_UART_BASE=0x3086 # for uart1 > > CONFIG_DEBUG_UART_CLOCK=2400 > > > > It is because CONFIG_SYS_MALLOC_F_LEN is too small, enlarge it. And set > > CONFIG_SPL_STACK to 0x188000 to not waste the top 16bytes. > > When changing these values on the kontron_pitx_imx8m_defconfig this > board also works again. > Maybe it could be a good idea to change these values for all imx8mq boards. > > > > > Reported-by: Heiko Thiery > > Signed-off-by: Peng Fan > > Tested-by: Heiko Thiery > > > --- > > configs/imx8mq_evk_defconfig | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig > > index cf207295e54..d877a1290f9 100644 > > --- a/configs/imx8mq_evk_defconfig > > +++ b/configs/imx8mq_evk_defconfig > > @@ -2,6 +2,8 @@ CONFIG_ARM=y > > CONFIG_ARCH_IMX8M=y > > CONFIG_SYS_TEXT_BASE=0x4020 > > CONFIG_SYS_MALLOC_LEN=0x60 > > +CONFIG_SYS_MALLOC_F_LEN=0x1 > > +CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 > > CONFIG_SPL_GPIO=y > > CONFIG_SPL_LIBCOMMON_SUPPORT=y > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > @@ -36,7 +38,7 @@ CONFIG_SPL_BSS_START_ADDR=0x18 > > CONFIG_SPL_BSS_MAX_SIZE=0x2000 > > CONFIG_SPL_BOARD_INIT=y > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > > -CONFIG_SPL_STACK=0x187ff0 > > +CONFIG_SPL_STACK=0x188000 > > CONFIG_SYS_SPL_MALLOC=y > > CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y > > CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220 > > -- > > 2.36.0 > > > > Thank you > -- > Heiko
Re: [PATCH v2 09/24] blk: Rename HAVE_BLOCK_DEVICE
On 9/14/22 03:42, AKASHI Takahiro wrote: On Thu, Aug 11, 2022 at 07:34:48PM -0600, Simon Glass wrote: This option is fact really related to SPL. For U-Boot proper we always use driver model for block devices, so CONFIG_BLK is enabled if block devices are in use. It is only for SPL that we have two cases: - SPL_BLK is enabled, in which case we use driver model and blk-uclass.c - SPL_BLK is not enabled, in which case (if we need block devices) we must use blk_legacy.c Rename the symbol to SPL_LEGACY_BLOCK to make this clear. This is different enough from BLK and SPL_BLK that there should be no confusion. Signed-off-by: Simon Glass --- (no changes since v1) common/spl/Kconfig | 4 ++-- configs/axm_defconfig | 2 +- configs/bcm968380gerg_ram_defconfig| 2 +- configs/gardena-smart-gateway-mt7688_defconfig | 2 +- configs/nsim_hs38_defconfig| 2 +- configs/qemu-ppce500_defconfig | 2 +- disk/Makefile | 4 ++-- disk/disk-uclass.c | 3 +-- doc/develop/driver-model/migration.rst | 2 +- drivers/Makefile | 2 +- drivers/ata/Kconfig| 2 +- drivers/block/Kconfig | 8 drivers/block/Makefile | 2 +- drivers/mmc/Kconfig| 2 +- drivers/nvme/Kconfig | 2 +- drivers/scsi/Kconfig | 2 +- drivers/xen/Kconfig| 2 +- include/blk.h | 2 +- lib/efi_loader/Kconfig | 2 +- 19 files changed, 24 insertions(+), 25 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index ee98810e9e9..4c3e74ae5eb 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -792,7 +792,7 @@ config SPL_DM_MAILBOX config SPL_MMC bool "Support MMC" depends on MMC - select HAVE_BLOCK_DEVICE + select SPL_LEGACY_BLOCK help Enable support for MMC (Multimedia Card) within SPL. This enables the MMC protocol implementation and allows any enabled drivers to @@ -1318,7 +1318,7 @@ config SPL_THERMAL config SPL_USB_HOST bool "Support USB host drivers" - select HAVE_BLOCK_DEVICE + select SPL_LEGACY_BLOCK help Enable access to USB (Universal Serial Bus) host devices so that SPL can load U-Boot from a connected USB peripheral, such as a USB diff --git a/configs/axm_defconfig b/configs/axm_defconfig index a5f60bd8d0c..c42fb37d6c9 100644 --- a/configs/axm_defconfig +++ b/configs/axm_defconfig @@ -80,7 +80,7 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SPL_DM=y CONFIG_BLK=y -CONFIG_HAVE_BLOCK_DEVICE=y +CONFIG_SPL_LEGACY_BLOCK=y CONFIG_CLK=y CONFIG_CLK_AT91=y CONFIG_AT91_GPIO=y diff --git a/configs/bcm968380gerg_ram_defconfig b/configs/bcm968380gerg_ram_defconfig index 0475535e991..246add6029c 100644 --- a/configs/bcm968380gerg_ram_defconfig +++ b/configs/bcm968380gerg_ram_defconfig @@ -42,7 +42,7 @@ CONFIG_CMD_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y # CONFIG_NET is not set # CONFIG_DM_DEVICE_REMOVE is not set -CONFIG_HAVE_BLOCK_DEVICE=y +CONFIG_SPL_LEGACY_BLOCK=y CONFIG_BCM6345_GPIO=y CONFIG_LED=y CONFIG_LED_BCM6328=y diff --git a/configs/gardena-smart-gateway-mt7688_defconfig b/configs/gardena-smart-gateway-mt7688_defconfig index b9ee281be9f..fdfab14d53e 100644 --- a/configs/gardena-smart-gateway-mt7688_defconfig +++ b/configs/gardena-smart-gateway-mt7688_defconfig @@ -78,7 +78,7 @@ CONFIG_VERSION_VARIABLE=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y # CONFIG_DM_DEVICE_REMOVE is not set -CONFIG_HAVE_BLOCK_DEVICE=y +CONFIG_SPL_LEGACY_BLOCK=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_LED=y CONFIG_LED_BLINK=y diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig index 3c3d1812a79..3f23fc4189f 100644 --- a/configs/nsim_hs38_defconfig +++ b/configs/nsim_hs38_defconfig @@ -30,7 +30,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="uImage" CONFIG_BLK=y -CONFIG_HAVE_BLOCK_DEVICE=y +CONFIG_SPL_LEGACY_BLOCK=y CONFIG_DM_ETH=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 034f7e6935b..3241f5520eb 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -40,7 +40,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SIMPLE_BUS_CORRECT_RANGE=y CONFIG_BLK=y -CONFIG_HAVE_BLOCK_DEVICE=y +CONFIG_SPL_LEGACY_BLOCK=y CONFIG_LBA48=y CONFIG_CHIP_SELECTS_PER_CTRL=0 CONFIG_MPC8XXX_GPIO=y diff --git a/disk/Makefile b/disk/Makefile index 458e21e3fb7..45588cf66e4 100644 --- a/disk/Makefile +++ b/disk/Makefile @@ -10,8 +10,8 @@ ifdef CONFIG_$(SPL_TPL_)BLK obj-$(CONFIG_$(SPL_T
Re: [PATCH v2 22/24] blk: Drop if_type
On 9/14/22 04:08, AKASHI Takahiro wrote: On Tue, Sep 13, 2022 at 06:27:37PM +0200, Heinrich Schuchardt wrote: On 8/12/22 03:35, Simon Glass wrote: Use the uclass ID instead. Signed-off-by: Simon Glass --- (no changes since v1) cmd/blk_common.c | 2 +- drivers/block/blk-uclass.c | 34 +++ drivers/block/blk_legacy.c | 20 +-- include/blk.h | 41 ++ include/efi_loader.h | 2 +- 5 files changed, 48 insertions(+), 51 deletions(-) diff --git a/cmd/blk_common.c b/cmd/blk_common.c index 4e442f2918b..369c5ae4bbe 100644 --- a/cmd/blk_common.c +++ b/cmd/blk_common.c @@ -12,7 +12,7 @@ #include #include -int blk_common_cmd(int argc, char *const argv[], enum if_type if_type, +int blk_common_cmd(int argc, char *const argv[], enum uclass_id if_type, int *cur_devnump) { const char *if_name = blk_get_if_type_name(if_type); diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c index 436af764f91..a9a85aa37f3 100644 --- a/drivers/block/blk-uclass.c +++ b/drivers/block/blk-uclass.c @@ -34,7 +34,7 @@ static struct { { UCLASS_PVBLOCK, "pvblock" }, }; -static enum if_type if_typename_to_iftype(const char *if_typename) +static enum uclass_id if_typename_to_iftype(const char *if_typename) { int i; @@ -46,7 +46,7 @@ static enum if_type if_typename_to_iftype(const char *if_typename) return UCLASS_INVALID; } -static enum uclass_id if_type_to_uclass_id(enum if_type if_type) +static enum uclass_id if_type_to_uclass_id(enum uclass_id if_type) { /* * This strange adjustment is used because we use UCLASS_MASS_STORAGE @@ -71,7 +71,7 @@ static enum uclass_id if_type_to_uclass_id(enum if_type if_type) return if_type; } -const char *blk_get_if_type_name(enum if_type if_type) +const char *blk_get_if_type_name(enum uclass_id if_type) { int i; @@ -83,7 +83,7 @@ const char *blk_get_if_type_name(enum if_type if_type) return "(none)"; } -struct blk_desc *blk_get_devnum_by_type(enum if_type if_type, int devnum) +struct blk_desc *blk_get_devnum_by_type(enum uclass_id if_type, int devnum) { struct blk_desc *desc; struct udevice *dev; @@ -105,7 +105,7 @@ struct blk_desc *blk_get_devnum_by_type(enum if_type if_type, int devnum) struct blk_desc *blk_get_devnum_by_typename(const char *if_typename, int devnum) { enum uclass_id uclass_id; - enum if_type type; + enum uclass_id type; struct udevice *dev; struct uclass *uc; int ret; @@ -185,7 +185,7 @@ struct blk_desc *blk_get_by_device(struct udevice *dev) * with a higher device number, -ENOENT if there is no such device but there * is one with a higher number, or other -ve on other error. */ -static int get_desc(enum if_type if_type, int devnum, struct blk_desc **descp) +static int get_desc(enum uclass_id if_type, int devnum, struct blk_desc **descp) { bool found_more = false; struct udevice *dev; @@ -218,7 +218,7 @@ static int get_desc(enum if_type if_type, int devnum, struct blk_desc **descp) return found_more ? -ENOENT : -ENODEV; } -int blk_select_hwpart_devnum(enum if_type if_type, int devnum, int hwpart) +int blk_select_hwpart_devnum(enum uclass_id if_type, int devnum, int hwpart) { struct udevice *dev; int ret; @@ -230,7 +230,7 @@ int blk_select_hwpart_devnum(enum if_type if_type, int devnum, int hwpart) return blk_select_hwpart(dev, hwpart); } -int blk_list_part(enum if_type if_type) +int blk_list_part(enum uclass_id if_type) { struct blk_desc *desc; int devnum, ok; @@ -255,7 +255,7 @@ int blk_list_part(enum if_type if_type) return 0; } -int blk_print_part_devnum(enum if_type if_type, int devnum) +int blk_print_part_devnum(enum uclass_id if_type, int devnum) { struct blk_desc *desc; int ret; @@ -270,7 +270,7 @@ int blk_print_part_devnum(enum if_type if_type, int devnum) return 0; } -void blk_list_devices(enum if_type if_type) +void blk_list_devices(enum uclass_id if_type) { struct blk_desc *desc; int ret; @@ -289,7 +289,7 @@ void blk_list_devices(enum if_type if_type) } } -int blk_print_device_num(enum if_type if_type, int devnum) +int blk_print_device_num(enum uclass_id if_type, int devnum) { struct blk_desc *desc; int ret; @@ -303,7 +303,7 @@ int blk_print_device_num(enum if_type if_type, int devnum) return 0; } -int blk_show_device(enum if_type if_type, int devnum) +int blk_show_device(enum uclass_id if_type, int devnum) { struct blk_desc *desc; int ret; @@ -324,7 +324,7 @@ int blk_show_device(enum if_type if_type, int devnum) return 0; } -ulong blk_read_devnum(enum if_type if_type, int devnum, lbaint_t start, +ulong blk_read_d
[PATCH] kontron_pitx_imx8m: enlarge SYS_MALLOC_F_LEN
There is "alloc space exhausted" that can be seen with DEBUG_UART options enabled and leeds to an non-functional board. CONFIG_DEBUG_UART_BASE=0x3088 # for serial3 CONFIG_DEBUG_UART_CLOCK=2400 It is because CONFIG_SYS_MALLOC_F_LEN is too small, enlarge it. And set CONFIG_SPL_STACK to 0x188000 to not waste the top 16bytes. Signed-off-by: Heiko Thiery --- configs/kontron_pitx_imx8m_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/kontron_pitx_imx8m_defconfig b/configs/kontron_pitx_imx8m_defconfig index 284aa6d6b8..a57b5cf552 100644 --- a/configs/kontron_pitx_imx8m_defconfig +++ b/configs/kontron_pitx_imx8m_defconfig @@ -2,6 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_IMX8M=y CONFIG_SYS_TEXT_BASE=0x4020 CONFIG_SYS_MALLOC_LEN=0x60 +CONFIG_SYS_MALLOC_F_LEN=0x1 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y @@ -35,7 +36,7 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x18 CONFIG_SPL_BSS_MAX_SIZE=0x2000 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x187ff0 +CONFIG_SPL_STACK=0x188000 CONFIG_SYS_SPL_MALLOC=y CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220 -- 2.30.2
Re: [PATCH v2 22/24] blk: Drop if_type
On Wed, Sep 14, 2022 at 09:45:47AM +0200, Heinrich Schuchardt wrote: > On 9/14/22 04:08, AKASHI Takahiro wrote: > > On Tue, Sep 13, 2022 at 06:27:37PM +0200, Heinrich Schuchardt wrote: > > > On 8/12/22 03:35, Simon Glass wrote: > > > > Use the uclass ID instead. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > (no changes since v1) > > > > > > > >cmd/blk_common.c | 2 +- > > > >drivers/block/blk-uclass.c | 34 +++ > > > >drivers/block/blk_legacy.c | 20 +-- > > > >include/blk.h | 41 > > > > ++ > > > >include/efi_loader.h | 2 +- > > > >5 files changed, 48 insertions(+), 51 deletions(-) > > > > > > > > diff --git a/cmd/blk_common.c b/cmd/blk_common.c > > > > index 4e442f2918b..369c5ae4bbe 100644 > > > > --- a/cmd/blk_common.c > > > > +++ b/cmd/blk_common.c > > > > @@ -12,7 +12,7 @@ > > > >#include > > > >#include > > > > > > > > -int blk_common_cmd(int argc, char *const argv[], enum if_type if_type, > > > > +int blk_common_cmd(int argc, char *const argv[], enum uclass_id > > > > if_type, > > > >int *cur_devnump) > > > >{ > > > > const char *if_name = blk_get_if_type_name(if_type); > > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c > > > > index 436af764f91..a9a85aa37f3 100644 > > > > --- a/drivers/block/blk-uclass.c > > > > +++ b/drivers/block/blk-uclass.c > > > > @@ -34,7 +34,7 @@ static struct { > > > > { UCLASS_PVBLOCK, "pvblock" }, > > > >}; > > > > > > > > -static enum if_type if_typename_to_iftype(const char *if_typename) > > > > +static enum uclass_id if_typename_to_iftype(const char *if_typename) > > > >{ > > > > int i; > > > > > > > > @@ -46,7 +46,7 @@ static enum if_type if_typename_to_iftype(const char > > > > *if_typename) > > > > return UCLASS_INVALID; > > > >} > > > > > > > > -static enum uclass_id if_type_to_uclass_id(enum if_type if_type) > > > > +static enum uclass_id if_type_to_uclass_id(enum uclass_id if_type) > > > >{ > > > > /* > > > > * This strange adjustment is used because we use > > > > UCLASS_MASS_STORAGE > > > > @@ -71,7 +71,7 @@ static enum uclass_id if_type_to_uclass_id(enum > > > > if_type if_type) > > > > return if_type; > > > >} > > > > > > > > -const char *blk_get_if_type_name(enum if_type if_type) > > > > +const char *blk_get_if_type_name(enum uclass_id if_type) > > > >{ > > > > int i; > > > > > > > > @@ -83,7 +83,7 @@ const char *blk_get_if_type_name(enum if_type if_type) > > > > return "(none)"; > > > >} > > > > > > > > -struct blk_desc *blk_get_devnum_by_type(enum if_type if_type, int > > > > devnum) > > > > +struct blk_desc *blk_get_devnum_by_type(enum uclass_id if_type, int > > > > devnum) > > > >{ > > > > struct blk_desc *desc; > > > > struct udevice *dev; > > > > @@ -105,7 +105,7 @@ struct blk_desc *blk_get_devnum_by_type(enum > > > > if_type if_type, int devnum) > > > >struct blk_desc *blk_get_devnum_by_typename(const char *if_typename, > > > > int devnum) > > > >{ > > > > enum uclass_id uclass_id; > > > > - enum if_type type; > > > > + enum uclass_id type; > > > > struct udevice *dev; > > > > struct uclass *uc; > > > > int ret; > > > > @@ -185,7 +185,7 @@ struct blk_desc *blk_get_by_device(struct udevice > > > > *dev) > > > > * with a higher device number, -ENOENT if there is no such device > > > > but there > > > > * is one with a higher number, or other -ve on other error. > > > > */ > > > > -static int get_desc(enum if_type if_type, int devnum, struct blk_desc > > > > **descp) > > > > +static int get_desc(enum uclass_id if_type, int devnum, struct > > > > blk_desc **descp) > > > >{ > > > > bool found_more = false; > > > > struct udevice *dev; > > > > @@ -218,7 +218,7 @@ static int get_desc(enum if_type if_type, int > > > > devnum, struct blk_desc **descp) > > > > return found_more ? -ENOENT : -ENODEV; > > > >} > > > > > > > > -int blk_select_hwpart_devnum(enum if_type if_type, int devnum, int > > > > hwpart) > > > > +int blk_select_hwpart_devnum(enum uclass_id if_type, int devnum, int > > > > hwpart) > > > >{ > > > > struct udevice *dev; > > > > int ret; > > > > @@ -230,7 +230,7 @@ int blk_select_hwpart_devnum(enum if_type if_type, > > > > int devnum, int hwpart) > > > > return blk_select_hwpart(dev, hwpart); > > > >} > > > > > > > > -int blk_list_part(enum if_type if_type) > > > > +int blk_list_part(enum uclass_id if_type) > > > >{ > > > > struct blk_desc *desc; > > > > int devnum, ok; > > > > @@ -255,7 +255,7 @@ int blk_list_part(enum if_type if_type) > > > > return 0; > > > >} > > > > > > > > -int blk_print_part_devnum(enum if_type if_type, i
RE: [PATCH 07/12] rockchip: puma-rk3399: load environment from same medium as one used to load U-Boot proper
Hi, ST Restricted > -Original Message- > From: U-Boot On Behalf Of Quentin Schulz > Sent: mardi 6 septembre 2022 11:23 > To: Kever Yang ; Quentin Schulz > > Cc: s...@chromium.org; philipp.toms...@vrull.eu; klaus.goger@theobroma- > systems.com; knaerz...@gmail.com; u-boot@lists.denx.de > Subject: Re: [PATCH 07/12] rockchip: puma-rk3399: load environment from same > medium as one used to load U-Boot proper > > Hi Kever, > > On 9/4/22 13:49, Kever Yang wrote: > > Hi Quentin, > > > > The Kconfig from env/Kconfig > > > > config ENV_IS_NOWHERE > > bool "Environment is not stored" > > default y if !ENV_IS_IN_EEPROM && !ENV_IS_IN_EXT4 && \ > > !ENV_IS_IN_FAT && !ENV_IS_IN_FLASH && \ > > !ENV_IS_IN_MMC && !ENV_IS_IN_NAND && \ > > !ENV_IS_IN_NVRAM && !ENV_IS_IN_ONENAND && \ > > !ENV_IS_IN_REMOTE && !ENV_IS_IN_SPI_FLASH && \ > > !ENV_IS_IN_UBI > > > > I think the logic is the env parameter is stored on some kind of > > storage, or NOWHERE. > > > > It's *default* to yes if none is defined. It's not a requirement. > > > And what you want to do is to load from the same medium as SPL boot > > device(location of U-Boot proper), > > > > this could not be NOWHERE. > > > > This can be nowhere in case the proper config option is not selected. > E.g. we're booting from SPI-NOR but the ENV_IS_IN_SPI_FLASH is not set. > How does one handle this scenario? Since we don't want fallbacks, it needs to > be > "nowhere". What you're suggesting is to let the user run a broken build and > have it > cryptically crash with the following error: > > initcall sequence 002866c0 failed at call 00256b34 (err=-19) > > Instead, I suggest to more gracefully error out at runtime by letting the > user know > that the option is not compiled in but U-Boot is still usable. > > If you have another way to forbid fallbacks but not crash U-Boot in case the > option > is not selected, let me know. > For information : It is exactly that I do to stm32mp15 platform See board/st/stm32mp1/stm32mp1.c::env_get_location() ENV_IS_NOWHERE = use the default environment, embedded in U-Boot and env It is the fallback if environment not activated ENV_IS_IN_* for the boot device, even it is not the case by default in stm32mp15_defconfig. And it is why , I change Kconfig to allow activation of any ENV_IS_IN_* and ENV_IS_NOWHERE Patrick > Cheers, > Quentin > > > > Thanks, > > > > - Kever > > > > On 2022/9/1 21:13, Quentin Schulz wrote: > >> Hi Kever > >> > >> On 9/1/22 15:03, Kever Yang wrote: > >>> Hi Quentin, > >>> > >>> On 2022/7/23 00:06, Quentin Schulz wrote: > From: Quentin Schulz > > Chances are when one boots U-Boot proper from a given storage > medium, they want the same medium to be used to load and store the > environment. > > This basically allows to have completely separate U-Boot > (TPL/SPL/U-Boot > proper/environment) per storage medium which is convenient when > working with recovery from SD-Card as one would just need to insert > a properly configured SD-Card into the device to have access to > their whole debug setup. > > No fallback mechanism is provided as to not dirty other storage > medium environment by mistake. However, since > arch_env_get_location() is called by env_init() which is part of > the pre-relocation process, a valid, non-ENVL_UNKNOWN, value shall > be returned otherwise the relocation fails with the following > message: > initcall sequence 002866c0 failed at call 00256b34 > (err=-19) > > This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which > requires > to always select CONFIG_ENV_IS_NOWHERE otherwise this work-around > does not work. > > Cc: Quentin Schulz > Signed-off-by: Quentin Schulz > > --- > > Depends on > https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.or > g_u-2Dboot_20220715151552.953654-2D1-2Dfoss-2Buboot-400leil.net_&d= > > DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSq > HGq8 > yBP6m6qZZ4njZguQhZhkI_- > 172IIy1t&m=TZndtGz1ePTd2Il6YcEjqzo9oXv73RCWH > > IRVSiFVsnp2OzyCJEDzZ2KPz56AcWdn&s=wgEMbr3EjeCtvcWU_UoXqNOwQula > VN-0Q > b2yL2ysaOs&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.or > g_u-2Dboot_20220715151552.953654-2D2-2Dfoss-2Buboot-400leil.net_&d= > > DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSq > HGq8 > yBP6m6qZZ4njZguQhZhkI_- > 172IIy1t&m=TZndtGz1ePTd2Il6YcEjqzo9oXv73RCWH > > IRVSiFVsnp2OzyCJEDzZ2KPz56AcWdn&s=PKwYBMB7r8ekIPV1ZG7xkj7vF60YN > FlYX > QRrvaVgJR8&e= > .../puma_rk3399/puma-rk3399.c | 37 > +++ > configs/puma-rk3399_defconfig | 1 + > 2 files changed, 38
[PATCH v3 0/3] rockpi4: Add capsule update support
Add capsule update support for the RockPi4B and RockPi4C boards. Support is being added for updating the idbloader.img and u-boot.itb firmware images on configurations with the firmware images stored on GPT partitioned uSD card device. Changes since V2: * Use rockchip in the commit message summary instead of rockpi * Use num_image_type_guids instead of ROCKPI4_UPDATABLE_IMAGES macro * Move the board specific code out of this file into evb_rk3399.c * Add a function rockchip_capsule_update_board_setup() for setting up the board specific part needed for capsule updates Sughosh Ganu (3): rockchip: capsule: Add functions for supporting capsule updates rockpi4: board: Add firmware image information for capsule updates rockpi4: capsule: Enable UEFI capsule update on RockPi4 boards arch/arm/include/asm/arch-rockchip/misc.h | 1 + arch/arm/mach-rockchip/Kconfig| 1 + arch/arm/mach-rockchip/board.c| 152 ++ board/rockchip/evb_rk3399/evb-rk3399.c| 55 +++- configs/rock-pi-4-rk3399_defconfig| 8 ++ configs/rock-pi-4c-rk3399_defconfig | 8 ++ include/configs/rk3399_common.h | 16 +++ 7 files changed, 240 insertions(+), 1 deletion(-) -- 2.34.1
[PATCH v3 1/3] rockchip: capsule: Add functions for supporting capsule updates
Add functions needed to support the UEFI capsule update feature on rockchip boards. Currently, the feature is being enabled on the RockPi4 boards with firmware images residing on GPT partitioned storage media. Signed-off-by: Sughosh Ganu --- Changes since V2: * Use rockchip in the commit message summary instead of rockpi * Use num_image_type_guids instead of ROCKPI4_UPDATABLE_IMAGES macro * Move the board specific code out of this file into evb_rk3399.c arch/arm/mach-rockchip/Kconfig | 1 + arch/arm/mach-rockchip/board.c | 152 + 2 files changed, 153 insertions(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index b46cea2f91..619899ff68 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -246,6 +246,7 @@ config ROCKCHIP_RK3399 select DM_PMIC select DM_REGULATOR_FIXED select BOARD_LATE_INIT + imply PARTITION_TYPE_GUID imply PRE_CONSOLE_BUFFER imply ROCKCHIP_COMMON_BOARD imply ROCKCHIP_SDRAM_COMMON diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c index cbe00d646c..0c806243e3 100644 --- a/arch/arm/mach-rockchip/board.c +++ b/arch/arm/mach-rockchip/board.c @@ -6,11 +6,15 @@ #include #include #include +#include #include #include #include +#include +#include #include #include +#include #include #include #include @@ -22,8 +26,156 @@ DECLARE_GLOBAL_DATA_PTR; +#if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION) + +#define DFU_ALT_BUF_LENSZ_1K + +extern struct efi_fw_image fw_images[]; + +static bool updatable_image(struct disk_partition *info) +{ + int i; + bool ret = false; + efi_guid_t image_type_guid; + + uuid_str_to_bin(info->type_guid, image_type_guid.b, + UUID_STR_FORMAT_GUID); + + for (i = 0; i < num_image_type_guids; i++) { + if (!guidcmp(&fw_images[i].image_type_id, &image_type_guid)) { + ret = true; + break; + } + } + + return ret; +} + +static void set_image_index(struct disk_partition *info, int index) +{ + int i; + efi_guid_t image_type_guid; + + uuid_str_to_bin(info->type_guid, image_type_guid.b, + UUID_STR_FORMAT_GUID); + + for (i = 0; i < num_image_type_guids; i++) { + if (!guidcmp(&fw_images[i].image_type_id, &image_type_guid)) { + fw_images[i].image_index = index; + break; + } + } +} + +static int get_mmc_desc(struct blk_desc **desc) +{ + int ret; + struct mmc *mmc; + struct udevice *dev; + + /* +* For now the firmware images are assumed to +* be on the SD card +*/ + ret = uclass_get_device(UCLASS_MMC, 1, &dev); + if (ret) + return -1; + + mmc = mmc_get_mmc_dev(dev); + if (!mmc) + return -ENODEV; + + if ((ret = mmc_init(mmc))) + return ret; + + *desc = mmc_get_blk_desc(mmc); + if (!*desc) + return -1; + + return 0; +} + +void set_dfu_alt_info(char *interface, char *devstr) +{ + const char *name; + bool first = true; + int p, len, devnum, ret; + char buf[DFU_ALT_BUF_LEN]; + struct disk_partition info; + struct blk_desc *desc = NULL; + + ret = get_mmc_desc(&desc); + if (ret) { + log_err("Unable to get mmc desc\n"); + return; + } + + memset(buf, 0, sizeof(buf)); + name = blk_get_if_type_name(desc->if_type); + devnum = desc->devnum; + len = strlen(buf); + + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, +"%s %d=", name, devnum); + + for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) { + if (part_get_info(desc, p, &info)) + continue; + + /* Add entry to dfu_alt_info only for updatable images */ + if (updatable_image(&info)) { + if (!first) + len += snprintf(buf + len, + DFU_ALT_BUF_LEN - len, ";"); + + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, + "%s%d_%s part %d %d", + name, devnum, info.name, devnum, p); + first = false; + } + } + + log_debug("dfu_alt_info => %s\n", buf); + env_set("dfu_alt_info", buf); +} + +static void gpt_capsule_update_setup(void) +{ + int p, i, ret; + struct disk_partition info; + struct blk_desc *desc = NULL; + + rockchip_capsule_update_board_setup(); + + ret = get_mmc_desc(&desc); + if (ret) { + log_err("Unable
[PATCH v3 2/3] rockpi4: board: Add firmware image information for capsule updates
Add information that will be needed for enabling the UEFI capsule update feature on the RockPi4 boards. With the feature enabled, it would be possible to update the idbloader and u-boot.itb images on the RockPi4B and RockPi4C variants. Signed-off-by: Sughosh Ganu --- Changes since V2: * Add a function rockchip_capsule_update_board_setup() for setting up the board specific part needed for capsule updates arch/arm/include/asm/arch-rockchip/misc.h | 1 + board/rockchip/evb_rk3399/evb-rk3399.c| 55 ++- include/configs/rk3399_common.h | 16 +++ 3 files changed, 71 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-rockchip/misc.h b/arch/arm/include/asm/arch-rockchip/misc.h index b6b03c934e..4155af8c3b 100644 --- a/arch/arm/include/asm/arch-rockchip/misc.h +++ b/arch/arm/include/asm/arch-rockchip/misc.h @@ -11,3 +11,4 @@ int rockchip_cpuid_from_efuse(const u32 cpuid_offset, u8 *cpuid); int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length); int rockchip_setup_macaddr(void); +void rockchip_capsule_update_board_setup(void); diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c b/board/rockchip/evb_rk3399/evb-rk3399.c index abb76585cf..769d374f86 100644 --- a/board/rockchip/evb_rk3399/evb-rk3399.c +++ b/board/rockchip/evb_rk3399/evb-rk3399.c @@ -5,11 +5,25 @@ #include #include +#include #include #include #include +#include #include +#define ROCKPI4_UPDATABLE_IMAGES 2 + +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT) +struct efi_fw_image fw_images[ROCKPI4_UPDATABLE_IMAGES] = {0}; + +struct efi_capsule_update_info update_info = { + .images = fw_images, +}; + +u8 num_image_type_guids = ARRAY_SIZE(fw_images); +#endif + #ifndef CONFIG_SPL_BUILD int board_early_init_f(void) { @@ -29,4 +43,43 @@ int board_early_init_f(void) out: return 0; } -#endif + +#if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION) +static bool board_is_rockpi_4b(void) +{ + return CONFIG_IS_ENABLED(TARGET_EVB_RK3399) && + of_machine_is_compatible("radxa,rockpi4b"); +} + +static bool board_is_rockpi_4c(void) +{ + return CONFIG_IS_ENABLED(TARGET_EVB_RK3399) && + of_machine_is_compatible("radxa,rockpi4c"); +} + +void rockchip_capsule_update_board_setup(void) +{ + if (board_is_rockpi_4b()) { + efi_guid_t idbldr_image_type_guid = + ROCKPI_4B_IDBLOADER_IMAGE_GUID; + efi_guid_t uboot_image_type_guid = ROCKPI_4B_UBOOT_IMAGE_GUID; + + guidcpy(&fw_images[0].image_type_id, &idbldr_image_type_guid); + guidcpy(&fw_images[1].image_type_id, &uboot_image_type_guid); + + fw_images[0].fw_name = u"ROCKPI4B-IDBLOADER"; + fw_images[1].fw_name = u"ROCKPI4B-UBOOT"; + } else if (board_is_rockpi_4c()) { + efi_guid_t idbldr_image_type_guid = + ROCKPI_4C_IDBLOADER_IMAGE_GUID; + efi_guid_t uboot_image_type_guid = ROCKPI_4C_UBOOT_IMAGE_GUID; + + guidcpy(&fw_images[0].image_type_id, &idbldr_image_type_guid); + guidcpy(&fw_images[1].image_type_id, &uboot_image_type_guid); + + fw_images[0].fw_name = u"ROCKPI4C-IDBLOADER"; + fw_images[1].fw_name = u"ROCKPI4C-UBOOT"; + } +} +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT && CONFIG_EFI_PARTITION */ +#endif /* !CONFIG_SPL_BUILD */ diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h index 2f9aee5819..f0a9ab8f83 100644 --- a/include/configs/rk3399_common.h +++ b/include/configs/rk3399_common.h @@ -24,6 +24,22 @@ #define CONFIG_SYS_SDRAM_BASE 0 #define SDRAM_MAX_SIZE 0xf800 +#define ROCKPI_4B_IDBLOADER_IMAGE_GUID \ + EFI_GUID(0x02f4d760, 0xcfd5, 0x43bd, 0x8e, 0x2d, \ +0xa4, 0x2a, 0xcb, 0x33, 0xc6, 0x60) + +#define ROCKPI_4B_UBOOT_IMAGE_GUID \ + EFI_GUID(0x4ce292da, 0x1dd8, 0x428d, 0xa1, 0xc2, \ +0x77, 0x74, 0x3e, 0xf8, 0xb9, 0x6e) + +#define ROCKPI_4C_IDBLOADER_IMAGE_GUID \ + EFI_GUID(0xfd68510c, 0x12d3, 0x4f0a, 0xb8, 0xd3, \ +0xd8, 0x79, 0xe1, 0xd3, 0xa5, 0x40) + +#define ROCKPI_4C_UBOOT_IMAGE_GUID \ + EFI_GUID(0xb81fb4ae, 0xe4f3, 0x471b, 0x99, 0xb4, \ +0x0b, 0x3d, 0xa5, 0x49, 0xce, 0x13) + #ifndef CONFIG_SPL_BUILD #define ENV_MEM_LAYOUT_SETTINGS \ -- 2.34.1
[PATCH v3 3/3] rockpi4: capsule: Enable UEFI capsule update on RockPi4 boards
Enable the UEFI capsule update functionality on the RockPi4B and RockPi4C boards. Support is being enabled for updating the idbloader and u-boot firmware images residing on GPT partitioned uSD card storage device. Signed-off-by: Sughosh Ganu --- Changes since V2: None configs/rock-pi-4-rk3399_defconfig | 8 configs/rock-pi-4c-rk3399_defconfig | 8 2 files changed, 16 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index f8a57f6838..4e253196a3 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_TPL=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DFU=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y @@ -40,6 +41,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_DFU_MMC=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -84,3 +86,9 @@ CONFIG_VIDEO_ROCKCHIP=y CONFIG_DISPLAY_ROCKCHIP_HDMI=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y +CONFIG_CMD_NVEDIT_EFI=y +CONFIG_CMD_EFIDEBUG=y +CONFIG_TOOLS_MKEFICAPSULE=y +CONFIG_HEXDUMP=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y diff --git a/configs/rock-pi-4c-rk3399_defconfig b/configs/rock-pi-4c-rk3399_defconfig index 9aa7809bd0..ee500a7d58 100644 --- a/configs/rock-pi-4c-rk3399_defconfig +++ b/configs/rock-pi-4c-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_TPL=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DFU=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y @@ -40,6 +41,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_DFU_MMC=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -84,3 +86,9 @@ CONFIG_VIDEO_ROCKCHIP=y CONFIG_DISPLAY_ROCKCHIP_HDMI=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y +CONFIG_CMD_NVEDIT_EFI=y +CONFIG_CMD_EFIDEBUG=y +CONFIG_TOOLS_MKEFICAPSULE=y +CONFIG_HEXDUMP=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y -- 2.34.1
Re: [PATCH] kontron_pitx_imx8m: enlarge SYS_MALLOC_F_LEN
Hi Heiko, On Wed, Sep 14, 2022 at 5:02 AM Heiko Thiery wrote: > > There is "alloc space exhausted" that can be seen with DEBUG_UART > options enabled and leeds to an non-functional board. > > CONFIG_DEBUG_UART_BASE=0x3088 # for serial3 > CONFIG_DEBUG_UART_CLOCK=2400 > > It is because CONFIG_SYS_MALLOC_F_LEN is too small, enlarge it. And set > CONFIG_SPL_STACK to 0x188000 to not waste the top 16bytes. > > Signed-off-by: Heiko Thiery Reviewed-by: Fabio Estevam
Re: [PATCH] imx8mq_evk: enlarge SYS_MALLOC_F_LEN
On Wed, Sep 14, 2022 at 1:12 AM Heiko Thiery wrote: > When changing these values on the kontron_pitx_imx8m_defconfig this > board also works again. > Maybe it could be a good idea to change these values for all imx8mq boards. Yes, agreed. It would be great if someone could align these values for all imx8mq boards.
[PATCH] armv8: cache_v8: Fix pgtables setup when MMU is already enabled
When MMU is already enabled then dcache_enable() does not call mmu_setup() and so setup_all_pgtables() is also never called. In this situation when some driver calls mmu_set_region_dcache_behaviour() function then U-Boot crashes with error message: Emergency page table not setup. Fix this issue by explicitly calling setup_all_pgtables() in dcache_enable() function near condition for mmu_setup(). This change fixes chainloading U-Boot from U-Boot on Turris Mox board which uses mvneta ethernet driver which calls mmu_set_region_dcache_behaviour(). Signed-off-by: Pali Rohár --- arch/arm/cpu/armv8/cache_v8.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index e4736e564366..2a226fd0633d 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -503,6 +503,10 @@ void dcache_enable(void) mmu_setup(); } + /* Set up page tables only once (it is done also by mmu_setup()) */ + if (!gd->arch.tlb_fillptr) + setup_all_pgtables(); + set_sctlr(get_sctlr() | CR_C); } -- 2.20.1
Re: [PATCH] imx8mq_evk: enlarge SYS_MALLOC_F_LEN
Hi, Am Mi., 14. Sept. 2022 um 13:34 Uhr schrieb Fabio Estevam : > > On Wed, Sep 14, 2022 at 1:12 AM Heiko Thiery wrote: > > > When changing these values on the kontron_pitx_imx8m_defconfig this > > board also works again. > > Maybe it could be a good idea to change these values for all imx8mq boards. > > Yes, agreed. It would be great if someone could align these values for > all imx8mq boards. Strange thing is, that we already had the value of 0x1 (introduced by 545eceb52062cdc995c45b9581174b7ae66b0e6f and reverted by b598957206e541b3f8876ae34a15fac6da90dcef) and Peng said that the MALLOC BASE address of the IMX8MQ is set to OCRAM_S amd has 32kB [1]. [1] https://lore.kernel.org/u-boot/718b5b97-2b53-06f0-540b-70dd45f39...@oss.nxp.com/ -- Heiko
Re: [PATCH] gpio: uclass: Introduce gpio-hog-optional property
Hi Nate, On Mon, 12 Sept 2022 at 14:57, Nate Drude wrote: > > Hi Simon and Fabio, > > On 9/12/22 3:16 PM, Simon Glass wrote: > > Hi, > > > > On Mon, 12 Sept 2022 at 12:48, Fabio Estevam wrote: > >> > >> Hi Nate and Simon, > >> > >> On Mon, Sep 12, 2022 at 2:55 PM Nate Drude wrote: > >>> > >>> gpio_hog_probe_all is invoked by init_sequence_r in board_r.c. > >>> If device_probe fails for any gpio-hog, boot hangs with the following > >>> error: > >>> > initcall sequence fffc8e18 failed at call 4023b320 > (err=-121) > ### ERROR ### Please RESET the board ### > >>> > >>> gpio-hog-optional allows the boot sequence to continue if device_probe > >>> fails for optional gpio-hog(s). > >>> > >>> Signed-off-by: Nate Drude > >>> --- > >>> doc/device-tree-bindings/gpio/gpio.txt | 1 + > >>> drivers/gpio/gpio-uclass.c | 4 +++- > >>> 2 files changed, 4 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/doc/device-tree-bindings/gpio/gpio.txt > >>> b/doc/device-tree-bindings/gpio/gpio.txt > >>> index 1481ed607d..02d296316b 100644 > >>> --- a/doc/device-tree-bindings/gpio/gpio.txt > >>> +++ b/doc/device-tree-bindings/gpio/gpio.txt > >>> @@ -189,6 +189,7 @@ gpio-controller's driver probe function. > >>> Each GPIO hog definition is represented as a child node of the GPIO > >>> controller. > >>> Required properties: > >>> - gpio-hog: A property specifying that this child node represents a > >>> GPIO hog. > >>> +- gpio-hog-optional: A property specifying to continue boot when > >>> device_probe fails in gpio_hog_probe_all > >> > >> gpio-hog-optional property does not exist in Linux. > >> > >> If this property is introduced then U-Boot and Linux devicetrees will > >> not be in sync. > >> > >> Can this be fixed differently? > > > > Nate, can you send a patch to Linux with the binding update? > > > > Regards, > > Simon > > Thanks for your responses and feedback. > > I don't think gpio-hog-optional is relevant to Linux. Sure, but Linux is (for better or worse) the main repo for the device tree bindings. > > The problem is if gpio_hog_probe_all returns an error, board_init_r will > hang() > > See: > - https://github.com/u-boot/u-boot/blob/v2022.07/common/board_r.c#L824-L825 > - https://github.com/u-boot/u-boot/blob/v2022.07/common/board_r.c#L763 > - > https://github.com/u-boot/u-boot/blob/v2022.07/drivers/gpio/gpio-uclass.c#L330-L332 > > A practical example of how this may occur is when an i2c gpio expander > (e.g. nxp,pca9534) uses gpio-hog, but the gpio expander is depopulated. > > Arguably, the best solution is to use a different device tree when the > gpio expander is not populated. This patch allows the gpio-hog to fail > gracefully and continue booting if gpio-hog-optional is used. > > Do you have any suggestions for a better approach? Does it make sense > for gpio_hog_probe_all to cause a fatal error when the gpio hog probe > fails (most devices, including the gpio-expander, will not cause a hang > if they fail to probe)? I think your approach is fine as is. Regards, Simon
Re: [PATCH v2] binman: Get futility by building it
Hi Quentin, On Tue, 13 Sept 2022 at 02:55, Quentin Schulz wrote: > > Hi Simon, > > On 9/12/22 15:35, Simon Glass wrote: > > A binary download is not great, since it depends on libraries being > > present in the system. Build futility from source instead. > > > > Note that this requires two patches to the source repo which are in > > progress: > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__issuetracker.google.com_issues_245993083-3Fpli-3D1&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=aZRnLGuudyF3wf57Yf7GAac-g9Rgf3zQuq1O9GJPIdIhZ_w2XDHpPsZGFQAIMFT9&s=j0aTJGKOhRncvmyFptYpT_Y9Qb3U3CDUiqG2jO_7hAQ&e= > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Pull from github instead, to avoid needing to login / gitcookies > > > > tools/binman/bintool.py| 17 + > > tools/binman/btool/futility.py | 12 > > 2 files changed, 21 insertions(+), 8 deletions(-) > > > > diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py > > index 032179a99de..52ec0030590 100644 > > --- a/tools/binman/bintool.py > > +++ b/tools/binman/bintool.py > > @@ -319,7 +319,8 @@ class Bintool: > > return result.stdout > > > > @classmethod > > -def build_from_git(cls, git_repo, make_target, bintool_path): > > +def build_from_git(cls, git_repo, make_target, bintool_path, > > flags=None, > > + branch=None): > > """Build a bintool from a git repo > > > > This clones the repo in a temporary directory, builds it with > > 'make', > > @@ -330,6 +331,8 @@ class Bintool: > > make_target (str): Target to pass to 'make' to build the tool > > bintool_path (str): Relative path of the tool in the repo, > > after > > build is complete > > +flags (list of str): Flags or variables to pass to make, or > > None > > +branch (str): Branch to build, None for the default > > > > Returns: > > tuple: > > @@ -339,10 +342,16 @@ class Bintool: > > """ > > tmpdir = tempfile.mkdtemp(prefix='binmanf.') > > print(f"- clone git repo '{git_repo}' to '{tmpdir}'") > > -tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir) > > +args = ['git', 'clone', '--depth', '1'] > > +if branch: > > +args += ['-b', branch] > > I don't like branches too much, a commit hash would probably be better > for reproducibility, we would need a git checkout command though since > git clone command does not allow for commit hashes AFAIR. Up to you I guess. Well I plan land the required patch upstream so will be able to use the master branch. It's a shame that Chromium git requires an account. > > > +tools.run(*args, git_repo, tmpdir) > > print(f"- build target '{make_target}'") > > -tools.run('make', '-C', tmpdir, '-j', > > f'{multiprocessing.cpu_count()}', > > - make_target) > > +cmd = ['make', '-C', tmpdir, '-j', > > f'{multiprocessing.cpu_count()}', > > + make_target] > > +if flags: > > +cmd += flags > +tools.run(*cmd) > > fname = os.path.join(tmpdir, bintool_path) > > if not os.path.exists(fname): > > print(f"- File '{fname}' was not produced") > > diff --git a/tools/binman/btool/futility.py b/tools/binman/btool/futility.py > > index 75a05c2ac66..121a366830b 100644 > > --- a/tools/binman/btool/futility.py > > +++ b/tools/binman/btool/futility.py > > @@ -160,8 +160,12 @@ class Bintoolfutility(bintool.Bintool): > > Raises: > > Valuerror: Fetching could not be completed > > """ > > -if method != bintool.FETCH_BIN: > > +if method != bintool.FETCH_BUILD: > > return None > > -fname, tmpdir = self.fetch_from_drive( > > -'1hdsInzsE4aJbmBeJ663kYgjOQyW1I-E0') > > -return fname, tmpdir > > +result = self.build_from_git( > > + > > 'https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sjg20_vboot-5Freference.git&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=aZRnLGuudyF3wf57Yf7GAac-g9Rgf3zQuq1O9GJPIdIhZ_w2XDHpPsZGFQAIMFT9&s=4I4vh_QaOw3S9ET9XnKHOHUkf7Qu3SGMGfUKNe5Uxe4&e= > > ', > > +'all', > > +'build/futility/futility', > > +flags=['USE_FLASHROM=0'], > > +branch='fut') > > +return result > > Seems to be doing the job, it fetches and builds the futility binary. > Having some hard time figuring out how to test it produces a valid > binary it seems most of the calls to futility in ftest.py are faked/mocked? Yes I think they all are. It would be easy enough to have a test which generates a real GBB and vblock and is skipped if futility is missing. > > Also, would be great to h
Re: [PATCH v6 0/8] Add support for cyclic function execution infrastruture
On Fri, 2 Sep 2022 13:57:46 +0200, Stefan Roese wrote: > This patchset adds the basic infrastructure to periodically execute > code, e.g. all 100ms. Examples for such functions might be LED blinking > etc. The functions that are hooked into this cyclic list should be > small timewise as otherwise the execution of the other code that relies > on a high frequent polling (e.g. UART rx char ready check) might be > delayed too much. This patch also adds the Kconfig option > CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time > for such a cyclic function. If it's execution time exceeds this time, > this cyclic function will get removed from the cyclic list. > > [...] For the series, applied to u-boot/next, thanks! -- Tom
[PATCH] Makefile: Add missing CONFIG_BOARD_SIZE_LIMIT check for u-boot-spl.kwb
Currently CONFIG_BOARD_SIZE_LIMIT check is ignored for u-boot-spl.kwb target. Fix it by adding missing $(BOARD_SIZE_CHECK) macro. Signed-off-by: Pali Rohár --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 65aca6e3e79b..3818107b2cbb 100644 --- a/Makefile +++ b/Makefile @@ -1472,6 +1472,7 @@ endif u-boot-spl.kwb: u-boot.bin spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) + $(BOARD_SIZE_CHECK) u-boot.sha1: u-boot.bin tools/ubsha1 u-boot.bin -- 2.20.1
[PATCH] arm: mvebu: turris_omnia: Add CONFIG_BOARD_SIZE_LIMIT
Maximal size of u-boot kwb image binary is $CONFIG_ENV_OFFSET which is 0xF = 983040 bytes. So add missing CONFIG_BOARD_SIZE_LIMIT definition to ensure that u-boot binary does not overflow to the u-boot env storage. Signed-off-by: Pali Rohár --- configs/turris_omnia_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index ba635feb44b2..6698f2313550 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -28,6 +28,8 @@ CONFIG_SYS_MEMTEST_END=0x00ff CONFIG_DISTRO_DEFAULTS=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff +CONFIG_HAS_BOARD_SIZE_LIMIT=y +CONFIG_BOARD_SIZE_LIMIT=983040 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y -- 2.20.1
Re: [PATCH] gpio: uclass: Introduce gpio-hog-optional property
Hi Simon, On 9/14/22 7:49 AM, Simon Glass wrote: Hi Nate, On Mon, 12 Sept 2022 at 14:57, Nate Drude wrote: Hi Simon and Fabio, On 9/12/22 3:16 PM, Simon Glass wrote: Hi, On Mon, 12 Sept 2022 at 12:48, Fabio Estevam wrote: Hi Nate and Simon, On Mon, Sep 12, 2022 at 2:55 PM Nate Drude wrote: gpio_hog_probe_all is invoked by init_sequence_r in board_r.c. If device_probe fails for any gpio-hog, boot hangs with the following error: initcall sequence fffc8e18 failed at call 4023b320 (err=-121) ### ERROR ### Please RESET the board ### gpio-hog-optional allows the boot sequence to continue if device_probe fails for optional gpio-hog(s). Signed-off-by: Nate Drude --- doc/device-tree-bindings/gpio/gpio.txt | 1 + drivers/gpio/gpio-uclass.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/device-tree-bindings/gpio/gpio.txt b/doc/device-tree-bindings/gpio/gpio.txt index 1481ed607d..02d296316b 100644 --- a/doc/device-tree-bindings/gpio/gpio.txt +++ b/doc/device-tree-bindings/gpio/gpio.txt @@ -189,6 +189,7 @@ gpio-controller's driver probe function. Each GPIO hog definition is represented as a child node of the GPIO controller. Required properties: - gpio-hog: A property specifying that this child node represents a GPIO hog. +- gpio-hog-optional: A property specifying to continue boot when device_probe fails in gpio_hog_probe_all gpio-hog-optional property does not exist in Linux. If this property is introduced then U-Boot and Linux devicetrees will not be in sync. Can this be fixed differently? Nate, can you send a patch to Linux with the binding update? Regards, Simon Thanks for your responses and feedback. I don't think gpio-hog-optional is relevant to Linux. Sure, but Linux is (for better or worse) the main repo for the device tree bindings. I am not understanding the action. I think you're suggesting I update the Linux device tree bindings so they stay aligned with U-Boot, adding a property gpio-hog-optional after this line: https://github.com/torvalds/linux/blob/v6.0-rc5/Documentation/devicetree/bindings/gpio/gpio.txt#L191 However, since it's not relevant to Linux, I think it will be confusing since it will have no effect and won't be be used in any Linux code. Can you please advise what description I should use for the gpio-hog-optional property so that the Linux maintainers would accept such a patch? The problem is if gpio_hog_probe_all returns an error, board_init_r will hang() See: - https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu-boot%2Fblob%2Fv2022.07%2Fcommon%2Fboard_r.c%23L824-L825&data=05%7C01%7Cnate.d%40variscite.com%7C105f793941264d50bdad08da964f8a23%7C399ae6ac38f44ef094a8440b0ad581de%7C1%7C0%7C637987565614703613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wU%2Fz3uWE%2Bqj6jKzLeCx61Gfvyln7z60jRmONTN5Q46o%3D&reserved=0 - https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu-boot%2Fblob%2Fv2022.07%2Fcommon%2Fboard_r.c%23L763&data=05%7C01%7Cnate.d%40variscite.com%7C105f793941264d50bdad08da964f8a23%7C399ae6ac38f44ef094a8440b0ad581de%7C1%7C0%7C637987565614703613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b%2BtvcG21zH4WZqP39DFs%2FylUD9UOZp6tRZ%2BmeUwL2lc%3D&reserved=0 - https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu-boot%2Fblob%2Fv2022.07%2Fdrivers%2Fgpio%2Fgpio-uclass.c%23L330-L332&data=05%7C01%7Cnate.d%40variscite.com%7C105f793941264d50bdad08da964f8a23%7C399ae6ac38f44ef094a8440b0ad581de%7C1%7C0%7C637987565614859942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FwqsboWzGmSdUHrFUL48AwfTDbAPFpUmKbaQJEnprq0%3D&reserved=0 A practical example of how this may occur is when an i2c gpio expander (e.g. nxp,pca9534) uses gpio-hog, but the gpio expander is depopulated. Arguably, the best solution is to use a different device tree when the gpio expander is not populated. This patch allows the gpio-hog to fail gracefully and continue booting if gpio-hog-optional is used. Do you have any suggestions for a better approach? Does it make sense for gpio_hog_probe_all to cause a fatal error when the gpio hog probe fails (most devices, including the gpio-expander, will not cause a hang if they fail to probe)? I think your approach is fine as is. An alternate approach is to modify the default behavior so that gpio_hog_probe_all will not trigger a fatal error. Do you think this is better? Regards, Simon Thanks, Nate
Re: [PATCH] gpio: uclass: Introduce gpio-hog-optional property
Hi Nate, On Wed, Sep 14, 2022 at 11:00 AM Nate Drude wrote: > An alternate approach is to modify the default behavior so that > gpio_hog_probe_all will not trigger a fatal error. Do you think this is > better? IMHO that would be better, as we could keep using the same devicetree files from Linux. Thanks
Re: [PATCH] gpio: uclass: Introduce gpio-hog-optional property
On Wed, Sep 14, 2022 at 08:59:52AM -0500, Nate Drude wrote: > Hi Simon, > > On 9/14/22 7:49 AM, Simon Glass wrote: > > Hi Nate, > > > > On Mon, 12 Sept 2022 at 14:57, Nate Drude wrote: > > > > > > Hi Simon and Fabio, > > > > > > On 9/12/22 3:16 PM, Simon Glass wrote: > > > > Hi, > > > > > > > > On Mon, 12 Sept 2022 at 12:48, Fabio Estevam wrote: > > > > > > > > > > Hi Nate and Simon, > > > > > > > > > > On Mon, Sep 12, 2022 at 2:55 PM Nate Drude > > > > > wrote: > > > > > > > > > > > > gpio_hog_probe_all is invoked by init_sequence_r in board_r.c. > > > > > > If device_probe fails for any gpio-hog, boot hangs with the > > > > > > following error: > > > > > > > > > > > > > initcall sequence fffc8e18 failed at call > > > > > > > 4023b320 (err=-121) > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > gpio-hog-optional allows the boot sequence to continue if > > > > > > device_probe > > > > > > fails for optional gpio-hog(s). > > > > > > > > > > > > Signed-off-by: Nate Drude > > > > > > --- > > > > > >doc/device-tree-bindings/gpio/gpio.txt | 1 + > > > > > >drivers/gpio/gpio-uclass.c | 4 +++- > > > > > >2 files changed, 4 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/doc/device-tree-bindings/gpio/gpio.txt > > > > > > b/doc/device-tree-bindings/gpio/gpio.txt > > > > > > index 1481ed607d..02d296316b 100644 > > > > > > --- a/doc/device-tree-bindings/gpio/gpio.txt > > > > > > +++ b/doc/device-tree-bindings/gpio/gpio.txt > > > > > > @@ -189,6 +189,7 @@ gpio-controller's driver probe function. > > > > > >Each GPIO hog definition is represented as a child node of the > > > > > > GPIO controller. > > > > > >Required properties: > > > > > >- gpio-hog: A property specifying that this child node > > > > > > represents a GPIO hog. > > > > > > +- gpio-hog-optional: A property specifying to continue boot when > > > > > > device_probe fails in gpio_hog_probe_all > > > > > > > > > > gpio-hog-optional property does not exist in Linux. > > > > > > > > > > If this property is introduced then U-Boot and Linux devicetrees will > > > > > not be in sync. > > > > > > > > > > Can this be fixed differently? > > > > > > > > Nate, can you send a patch to Linux with the binding update? > > > > > > > > Regards, > > > > Simon > > > > > > Thanks for your responses and feedback. > > > > > > I don't think gpio-hog-optional is relevant to Linux. > > > > Sure, but Linux is (for better or worse) the main repo for the device > > tree bindings. > > I am not understanding the action. I think you're suggesting I update the > Linux device tree bindings so they stay aligned with U-Boot, adding a > property gpio-hog-optional after this line: > https://github.com/torvalds/linux/blob/v6.0-rc5/Documentation/devicetree/bindings/gpio/gpio.txt#L191 > > However, since it's not relevant to Linux, I think it will be confusing > since it will have no effect and won't be be used in any Linux code. > > Can you please advise what description I should use for the > gpio-hog-optional property so that the Linux maintainers would accept such a > patch? Yes, that would be one way to go about this, and there are other non-Linux bindings in the Linux kernel tree, but this might be the first property of an existing binding, so that might also be a bit challenging to get accepted, or find out what the preferred solution is. [snip] > > > Do you have any suggestions for a better approach? Does it make sense > > > for gpio_hog_probe_all to cause a fatal error when the gpio hog probe > > > fails (most devices, including the gpio-expander, will not cause a hang > > > if they fail to probe)? > > > > I think your approach is fine as is. > > An alternate approach is to modify the default behavior so that > gpio_hog_probe_all will not trigger a fatal error. Do you think this is > better? This too would be acceptable. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] sunxi: Kconfig: use SoC-wide values for some symbols
On Wed, 14 Sep 2022 10:04:44 -0400 Tom Rini wrote: Hi Tom, > On Wed, Sep 14, 2022 at 12:32:16AM +0100, Andre Przywara wrote: > > > Some configuration symbols formerly defined in header files were > > recently converted to Kconfig symbols. This moved their value definition > > into *every* defconfig file, even though those values are hardly board > > choices. > > Use the new Kconfig option to define per-SoC default values, in just one > > place, which makes the definition in each defconfig file redundant. > > > > We refrain from setting a sunxi specific value for CONFIG_SYS_BOOTM_LEN, > > so this defaults to a much better 64MB for uncompressed arm64 kernels. > > > > Signed-off-by: Andre Przywara > > Note that you forgot to CC the U-Boot list on this series. > > Reviewed-by: Tom Rini Many thanks! And yeah, I realised that missing CC: afterwards, and sent it again, just to the list this time. CC:ing now to record your tag. Cheers, Andre
Re: [PATCH v6 0/8] Add support for cyclic function execution infrastruture
On 14.09.22 14:58, Tom Rini wrote: On Fri, 2 Sep 2022 13:57:46 +0200, Stefan Roese wrote: This patchset adds the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. [...] For the series, applied to u-boot/next, thanks! Thanks Tom. This patch series should not introduce any functional changes. The next one though, which migrates the WATCHDOG_RESET into the cyclic function execution IF needs a quite some testing. Perhaps it makes sense to pull this other series as well quite early in the release cycle, so that it receives a lot of "attention"? So that we have time to fix potential problems here. What do you think? Thanks, Stefan
Re: [PATCH] gpio: uclass: Introduce gpio-hog-optional property
Hi All, On 9/14/22 9:16 AM, Tom Rini wrote: On Wed, Sep 14, 2022 at 08:59:52AM -0500, Nate Drude wrote: Hi Simon, On 9/14/22 7:49 AM, Simon Glass wrote: Hi Nate, On Mon, 12 Sept 2022 at 14:57, Nate Drude wrote: Hi Simon and Fabio, On 9/12/22 3:16 PM, Simon Glass wrote: Hi, On Mon, 12 Sept 2022 at 12:48, Fabio Estevam wrote: Hi Nate and Simon, On Mon, Sep 12, 2022 at 2:55 PM Nate Drude wrote: gpio_hog_probe_all is invoked by init_sequence_r in board_r.c. If device_probe fails for any gpio-hog, boot hangs with the following error: initcall sequence fffc8e18 failed at call 4023b320 (err=-121) ### ERROR ### Please RESET the board ### gpio-hog-optional allows the boot sequence to continue if device_probe fails for optional gpio-hog(s). Signed-off-by: Nate Drude --- doc/device-tree-bindings/gpio/gpio.txt | 1 + drivers/gpio/gpio-uclass.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/device-tree-bindings/gpio/gpio.txt b/doc/device-tree-bindings/gpio/gpio.txt index 1481ed607d..02d296316b 100644 --- a/doc/device-tree-bindings/gpio/gpio.txt +++ b/doc/device-tree-bindings/gpio/gpio.txt @@ -189,6 +189,7 @@ gpio-controller's driver probe function. Each GPIO hog definition is represented as a child node of the GPIO controller. Required properties: - gpio-hog: A property specifying that this child node represents a GPIO hog. +- gpio-hog-optional: A property specifying to continue boot when device_probe fails in gpio_hog_probe_all gpio-hog-optional property does not exist in Linux. If this property is introduced then U-Boot and Linux devicetrees will not be in sync. Can this be fixed differently? Nate, can you send a patch to Linux with the binding update? Regards, Simon Thanks for your responses and feedback. I don't think gpio-hog-optional is relevant to Linux. Sure, but Linux is (for better or worse) the main repo for the device tree bindings. I am not understanding the action. I think you're suggesting I update the Linux device tree bindings so they stay aligned with U-Boot, adding a property gpio-hog-optional after this line: https://github.com/torvalds/linux/blob/v6.0-rc5/Documentation/devicetree/bindings/gpio/gpio.txt#L191 However, since it's not relevant to Linux, I think it will be confusing since it will have no effect and won't be be used in any Linux code. Can you please advise what description I should use for the gpio-hog-optional property so that the Linux maintainers would accept such a patch? Yes, that would be one way to go about this, and there are other non-Linux bindings in the Linux kernel tree, but this might be the first property of an existing binding, so that might also be a bit challenging to get accepted, or find out what the preferred solution is. [snip] Do you have any suggestions for a better approach? Does it make sense for gpio_hog_probe_all to cause a fatal error when the gpio hog probe fails (most devices, including the gpio-expander, will not cause a hang if they fail to probe)? I think your approach is fine as is. An alternate approach is to modify the default behavior so that gpio_hog_probe_all will not trigger a fatal error. Do you think this is better? This too would be acceptable. Thanks for the discussion and feedback. I prefer to avoid changing the bindings in Linux if possible. Would it be acceptable if I rework gpio_hog_probe_all so that it prints an error "Failed to probe device..." if any device_probe fails, but always returns 0 to avoid a fatal error in board_init_r? I can submit a v2 patch, but I want to screen any problems with the approach first. Thanks, Nate
Re: [PATCH v6 0/8] Add support for cyclic function execution infrastruture
On Wed, Sep 14, 2022 at 04:29:36PM +0200, Stefan Roese wrote: > On 14.09.22 14:58, Tom Rini wrote: > > On Fri, 2 Sep 2022 13:57:46 +0200, Stefan Roese wrote: > > > > > This patchset adds the basic infrastructure to periodically execute > > > code, e.g. all 100ms. Examples for such functions might be LED blinking > > > etc. The functions that are hooked into this cyclic list should be > > > small timewise as otherwise the execution of the other code that relies > > > on a high frequent polling (e.g. UART rx char ready check) might be > > > delayed too much. This patch also adds the Kconfig option > > > CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time > > > for such a cyclic function. If it's execution time exceeds this time, > > > this cyclic function will get removed from the cyclic list. > > > > > > [...] > > > > For the series, applied to u-boot/next, thanks! > > Thanks Tom. > > This patch series should not introduce any functional changes. The > next one though, which migrates the WATCHDOG_RESET into the cyclic > function execution IF needs a quite some testing. Perhaps it makes > sense to pull this other series as well quite early in the release > cycle, so that it receives a lot of "attention"? So that we have > time to fix potential problems here. > > What do you think? Yes, the watchdog series should come to next, for v2023.01 as well. Are you comfortable with it now, or are you planning to v2 it? -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 0/8] Add support for cyclic function execution infrastruture
On 14.09.22 16:47, Tom Rini wrote: On Wed, Sep 14, 2022 at 04:29:36PM +0200, Stefan Roese wrote: On 14.09.22 14:58, Tom Rini wrote: On Fri, 2 Sep 2022 13:57:46 +0200, Stefan Roese wrote: This patchset adds the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. [...] For the series, applied to u-boot/next, thanks! Thanks Tom. This patch series should not introduce any functional changes. The next one though, which migrates the WATCHDOG_RESET into the cyclic function execution IF needs a quite some testing. Perhaps it makes sense to pull this other series as well quite early in the release cycle, so that it receives a lot of "attention"? So that we have time to fix potential problems here. What do you think? Yes, the watchdog series should come to next, for v2023.01 as well. Are you comfortable with it now, or are you planning to v2 it? I've only tested it on an MIPS Octeon platform so far. Where I am a bit hesitant is, the very early watchdog integration and SPL. This definitely needs some extensive testing. I don't have any platform for this here ready right now. Thanks, Stefan
Re: [PATCH 0/8] image: Refactor ramdisk code to avoid #ifdef
On Sun, 28 Aug 2022 12:32:45 -0600, Simon Glass wrote: > The previous attempt at this[1] broke a board and was reverted in [2]. > This series adopts a slightly different approach, splitting the changes > into many commits. > > [1] f33a2c1bd0f ("image: Remove #ifdefs from select_ramdisk()") > [2] 621158d106f ("Revert "image: Remove #ifdefs from select_ramdisk()"") > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH] board: gateworks: venice: add imx8mm-gw7904 support
The GW7904 is based on the i.MX 8M Mini SoC featuring: - LPDDR4 DRAM - eMMC FLASH - microSD connector with UHS support - LIS2DE12 3-axis accelerometer - Gateworks System Controller - IMX8M FEC - 2x RS232 off-board connectors - PMIC - 10x bi-color LED's - 1x miniPCIe socket with PCIe and USB2.0 - 802.3at Class 4 PoE - 10-30VDC input via barrel-jack Signed-off-by: Tim Harvey --- arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8mm-venice-gw7904-u-boot.dtsi | 46 + arch/arm/dts/imx8mm-venice-gw7904.dts | 884 ++ board/gateworks/venice/spl.c | 3 +- 4 files changed, 933 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/imx8mm-venice-gw7904-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-venice-gw7904.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 7330121dbaba..14f66da1865e 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -952,6 +952,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \ imx8mm-venice-gw7901.dtb \ imx8mm-venice-gw7902.dtb \ imx8mm-venice-gw7903.dtb \ + imx8mm-venice-gw7904.dtb \ imx8mm-verdin-wifi-dev.dtb \ phycore-imx8mm.dtb \ imx8mn-bsh-smm-s2.dtb \ diff --git a/arch/arm/dts/imx8mm-venice-gw7904-u-boot.dtsi b/arch/arm/dts/imx8mm-venice-gw7904-u-boot.dtsi new file mode 100644 index ..aa1153fbf879 --- /dev/null +++ b/arch/arm/dts/imx8mm-venice-gw7904-u-boot.dtsi @@ -0,0 +1,46 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2022 Gateworks Corporation + */ + +#include "imx8mm-venice-u-boot.dtsi" + +&gpio1 { + rs232en { + gpio-hog; + output-low; + gpios = <12 GPIO_ACTIVE_HIGH>; + line-name = "rs232_en#"; + }; +}; + +&gpio5 { + pci_wdis { + gpio-hog; + output-high; + gpios = <12 GPIO_ACTIVE_HIGH>; + line-name = "pci_wdis#"; + }; +}; + +&fec1 { + phy-reset-gpios = <&gpio4 25 GPIO_ACTIVE_LOW>; + phy-reset-duration = <1>; + phy-reset-post-delay = <300>; +}; + +&pinctrl_fec1 { + u-boot,dm-spl; +}; + +&{/soc@0/bus@3080/i2c@30a3/pmic@4b} { + u-boot,dm-spl; +}; + +&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} { + u-boot,dm-spl; +}; + +&pinctrl_pmic { + u-boot,dm-spl; +}; diff --git a/arch/arm/dts/imx8mm-venice-gw7904.dts b/arch/arm/dts/imx8mm-venice-gw7904.dts new file mode 100644 index ..2b68fb3e43d1 --- /dev/null +++ b/arch/arm/dts/imx8mm-venice-gw7904.dts @@ -0,0 +1,884 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright 2022 Gateworks Corporation + */ + +/dts-v1/; + +#include +#include +#include +#include + +#include "imx8mm.dtsi" + +/ { + model = "Gateworks Venice GW7904 i.MX8MM board"; + compatible = "gateworks,imx8mm-gw7904", "fsl,imx8mm"; + + chosen { + stdout-path = &uart2; + }; + + memory@4000 { + device_type = "memory"; + reg = <0x0 0x4000 0 0x8000>; + }; + + gpio-keys { + compatible = "gpio-keys"; + + key-0 { + label = "user_pb"; + gpios = <&gpio 2 GPIO_ACTIVE_LOW>; + linux,code = ; + }; + + key-1 { + label = "user_pb1x"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <0>; + }; + + key-2 { + label = "key_erased"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <1>; + }; + + key-3 { + label = "eeprom_wp"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <2>; + }; + + key-4 { + label = "switch_hold"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <7>; + }; + }; + + led-controller { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_gpio_leds>; + + led-0 { + function = LED_FUNCTION_STATUS; + color = ; + label = "led01_grn"; + gpios = <&gpioled 0 GPIO_ACTIVE_LOW>; + default-state = "off"; + }; + + led-1 { + function = LED_FUNCTION_STATUS; + color = ; + label = "led01_yel"; + gpios = <&gpioled 1 GPIO_ACTIVE_LOW>; + default-state = "off";
Pull request for efi next
Dear Tom, please, pull into the next branch. The following changes since commit c2238fcf0c4567bbd581882e5952047e71406f58: Merge branch '2022-09-13-add-aspeed-spi-controller' into next (2022-09-13 15:55:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next-2022-09-14 for you to fetch changes up to da4fb707ca095c223b67637e2525df4866e51c62: test: unit test for eficonfig (2022-09-14 08:43:32 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13439 Pull request for efi next UEFI: Implement a command eficonfig to maintain Load Options and boot order via menus. Masahisa Kojima (10): eficonfig: menu-driven addition of UEFI boot option eficonfig: add "Edit Boot Option" menu entry menu: add KEY_PLUS, KEY_MINUS and KEY_SPACE handling eficonfig: add "Delete Boot Option" menu entry bootmenu: add removable media entries eficonfig: scan media device in eficonfig startup eficonfig: add "Change Boot Order" menu entry doc:bootmenu: add description for UEFI boot support doc:eficonfig: add documentation for eficonfig command test: unit test for eficonfig cmd/Kconfig|7 + cmd/Makefile |1 + cmd/bootmenu.c | 22 +- cmd/eficonfig.c| 2502 common/menu.c |9 + configs/sandbox_defconfig |1 + doc/usage/cmd/bootmenu.rst | 74 + doc/usage/cmd/eficonfig.rst| 71 + doc/usage/index.rst|1 + include/efi_config.h | 98 + include/efi_loader.h | 53 + include/menu.h |3 + lib/efi_loader/efi_bootmgr.c |7 + lib/efi_loader/efi_boottime.c | 52 +- lib/efi_loader/efi_console.c | 70 + lib/efi_loader/efi_disk.c | 50 + lib/efi_loader/efi_file.c | 75 +- test/py/tests/test_eficonfig/conftest.py | 40 + test/py/tests/test_eficonfig/test_eficonfig.py | 354 19 files changed, 3437 insertions(+), 53 deletions(-) create mode 100644 cmd/eficonfig.c create mode 100644 doc/usage/cmd/eficonfig.rst create mode 100644 include/efi_config.h create mode 100644 test/py/tests/test_eficonfig/conftest.py create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py
Re: [PATCH 8/8] image: Drop some other #ifdefs in image-board.c
On 8/28/22 20:32, Simon Glass wrote: Remove all but a few that are difficult, relying on legacy CONFIG options or optional global_data fields. Drop the duplicate function name in the comment for boot_get_cmdline(). Signed-off-by: Simon Glass --- boot/image-board.c | 67 +- include/image.h| 6 + 2 files changed, 42 insertions(+), 31 deletions(-) diff --git a/boot/image-board.c b/boot/image-board.c index 7a17ffb7f7f..1be0a359aba 100644 --- a/boot/image-board.c +++ b/boot/image-board.c @@ -16,6 +16,7 @@ #include #include #include +#include This looks like an unrelated change. Best regards Heinrich #include #include #include @@ -172,29 +173,29 @@ void memmove_wd(void *to, void *from, size_t len, ulong chunksz) if (to == from) return; -#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) - if (to > from) { - from += len; - to += len; - } - while (len > 0) { - size_t tail = (len > chunksz) ? chunksz : len; - - WATCHDOG_RESET(); + if (IS_ENABLED(CONFIG_HW_WATCHDOG) || IS_ENABLED(CONFIG_WATCHDOG)) { if (to > from) { - to -= tail; - from -= tail; + from += len; + to += len; } - memmove(to, from, tail); - if (to < from) { - to += tail; - from += tail; + while (len > 0) { + size_t tail = (len > chunksz) ? chunksz : len; + + WATCHDOG_RESET(); + if (to > from) { + to -= tail; + from -= tail; + } + memmove(to, from, tail); + if (to < from) { + to += tail; + from += tail; + } + len -= tail; } - len -= tail; + } else { + memmove(to, from, len); } -#else /* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */ - memmove(to, from, len); -#endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */ } /** @@ -551,7 +552,6 @@ int boot_get_ramdisk(int argc, char *const argv[], bootm_headers_t *images, return 0; } -#if defined(CONFIG_LMB) /** * boot_ramdisk_high - relocate init ramdisk * @lmb: pointer to lmb handle, will be used for memory mgmt @@ -645,7 +645,6 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, ulong rd_len, error: return -1; } -#endif int boot_get_setup(bootm_headers_t *images, u8 arch, ulong *setup_start, ulong *setup_len) @@ -839,15 +838,13 @@ int boot_get_loadable(int argc, char *const argv[], bootm_headers_t *images, return 0; } -#if defined(CONFIG_LMB) -#ifdef CONFIG_SYS_BOOT_GET_CMDLINE /** * boot_get_cmdline - allocate and initialize kernel cmdline * @lmb: pointer to lmb handle, will be used for memory mgmt * @cmd_start: pointer to a ulong variable, will hold cmdline start * @cmd_end: pointer to a ulong variable, will hold cmdline end * - * boot_get_cmdline() allocates space for kernel command line below + * This allocates space for kernel command line below * BOOTMAPSZ + env_get_bootm_low() address. If "bootargs" U-Boot environment * variable is present its contents is copied to allocated kernel * command line. @@ -858,10 +855,19 @@ int boot_get_loadable(int argc, char *const argv[], bootm_headers_t *images, */ int boot_get_cmdline(struct lmb *lmb, ulong *cmd_start, ulong *cmd_end) { + int barg; char *cmdline; char *s; - cmdline = (char *)(ulong)lmb_alloc_base(lmb, CONFIG_SYS_BARGSIZE, 0xf, + /* +* Help the compiler detect that this function is only called when +* CONFIG_SYS_BOOT_GET_CMDLINE is enabled +*/ + if (!IS_ENABLED(CONFIG_SYS_BOOT_GET_CMDLINE)) + return 0; + + barg = IF_ENABLED_INT(CONFIG_SYS_BOOT_GET_CMDLINE, CONFIG_SYS_BARGSIZE); + cmdline = (char *)(ulong)lmb_alloc_base(lmb, barg, 0xf, env_get_bootm_mapsize() + env_get_bootm_low()); if (!cmdline) return -1; @@ -907,22 +913,22 @@ int boot_get_kbd(struct lmb *lmb, struct bd_info **kbd) debug("## kernel board info at 0x%08lx\n", (ulong)*kbd); -#if defined(DEBUG) - if (IS_ENABLED(CONFIG_CMD_BDI)) + if (_DEBUG && IS_ENABLED(CONFIG_CMD_BDI)) do_bdinfo(NULL, 0, 0, NULL); -#endif return 0; } -#endif int image_setup_linux(bootm_headers_t *images) { ulong of_size = images->ft_len; char **of_flat_tree = &images->ft_addr; - struct lmb *lmb = &images->lmb; + struct lmb *lmb = images_lm
[PATCH] arm: mvebu: Add default SPL_SIZE_LIMIT for 32-bit SoCs
32-bit Marvell Armada BootROMs limit maximal size of SPL image to 192 kB. So define 192 kB (= 0x3) limit as default value for SPL_SIZE_LIMIT. Signed-off-by: Pali Rohár --- common/spl/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 70d97815f0a1..29e2f92f9b03 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -40,6 +40,7 @@ config SPL_SIZE_LIMIT hex "Maximum size of SPL image" default 0x11000 if ARCH_MX6 && !MX6_OCRAM_256KB default 0x31000 if ARCH_MX6 && MX6_OCRAM_256KB + default 0x3 if ARCH_MVEBU && ARMADA_32BIT default 0x0 help Specifies the maximum length of the U-Boot SPL image. -- 2.20.1
Re: [PATCH v2 24/24] blk: Rename if_type to uclass_id
Hi Tom, On Tue, 13 Sept 2022 at 10:03, Tom Rini wrote: > > On Thu, Aug 11, 2022 at 07:35:03PM -0600, Simon Glass wrote: > > > Use the word 'uclass' instead of 'if_type' to complete the conversion. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Use conv_uclass_id() instead of the confusing uclass_id_to_uclass_id() > > So, for this series, 1 through 22 apply cleanly (one easy fixup > required), and 23/24 appears to be applied already. But large chunks of > this patch do not apply to lib/efi_loader/efi_disk.c and it's unclear > what I should do here. Should I just apply 1-22 of this series? Or do > you expect to v3 this? Thanks! Yes please apply 1-22. For 24 I will then rebase on -next , address the comments and resend. Regards, Simon
Re: [PATCH v6 0/8] Add support for cyclic function execution infrastruture
Hi Stefan, On Wed, 14 Sept 2022 at 09:19, Stefan Roese wrote: > > On 14.09.22 16:47, Tom Rini wrote: > > On Wed, Sep 14, 2022 at 04:29:36PM +0200, Stefan Roese wrote: > >> On 14.09.22 14:58, Tom Rini wrote: > >>> On Fri, 2 Sep 2022 13:57:46 +0200, Stefan Roese wrote: > >>> > This patchset adds the basic infrastructure to periodically execute > code, e.g. all 100ms. Examples for such functions might be LED blinking > etc. The functions that are hooked into this cyclic list should be > small timewise as otherwise the execution of the other code that relies > on a high frequent polling (e.g. UART rx char ready check) might be > delayed too much. This patch also adds the Kconfig option > CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time > for such a cyclic function. If it's execution time exceeds this time, > this cyclic function will get removed from the cyclic list. > > [...] > >>> > >>> For the series, applied to u-boot/next, thanks! > >> > >> Thanks Tom. > >> > >> This patch series should not introduce any functional changes. The > >> next one though, which migrates the WATCHDOG_RESET into the cyclic > >> function execution IF needs a quite some testing. Perhaps it makes > >> sense to pull this other series as well quite early in the release > >> cycle, so that it receives a lot of "attention"? So that we have > >> time to fix potential problems here. > >> > >> What do you think? > > > > Yes, the watchdog series should come to next, for v2023.01 as well. Are > > you comfortable with it now, or are you planning to v2 it? > > I've only tested it on an MIPS Octeon platform so far. Where I am a bit > hesitant is, the very early watchdog integration and SPL. This > definitely needs some extensive testing. I don't have any platform > for this here ready right now. Once it is in -next, people will test it and we'll flush out any problems. Regards, Simon
Re: [PATCH v2 1/4] common/board_f: remove XTRN_DECLARE_GLOBAL_DATA_PTR dead code
On Tue, 13 Sept 2022 at 12:31, Ovidiu Panait wrote: > > The XTRN_DECLARE_GLOBAL_DATA_PTR declarations in ppc code are permanently > commented out, so there are no users for this macro: > #if 1 >#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2") > #else /* We could use plain global data, but the resulting code is bigger */ >#define XTRN_DECLARE_GLOBAL_DATA_PTR extern >#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \ >gd_t *gd > #endif > > Remove all references to this macro, but add a documentation note regarding > the possibility of using plain global data for the GD pointer. > > Signed-off-by: Ovidiu Panait > --- > > Changes in v2: > - update global data documentation with the info provided by Wolfgang > > arch/powerpc/include/asm/global_data.h | 6 -- > common/board_f.c | 11 --- > doc/develop/global_data.rst| 5 + > 3 files changed, 5 insertions(+), 17 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH] board_f: show_dram_config: Print also real DRAM size
Hi Pali, On Mon, 12 Sept 2022 at 15:58, Sean Anderson wrote: > > > > On 9/12/22 2:56 PM, Pali Rohár wrote: > > On Monday 12 September 2022 07:34:47 Simon Glass wrote: > >> Hi Pali, > >> > >> On Sun, 11 Sept 2022 at 03:39, Pali Rohár wrote: > >> > > >> > 32-bit U-Boot builds cannot use more than around 2 GB of DDR memory. But > >> > on > >> > some platforms/boards it is possible to connect also 4 GB SODIMM DDR > >> > memory. > >> > U-Boot currently prints only effective size of RAM which can use, which > >> > may > >> > be misleading as somebody would expect that this line prints total size > >> > of > >> > connected DDR modules. So change show_dram_config code to prints both > >> > real > >> > and effective DRAM size if they are different. If they are same then > >> > print > >> > just one number like before. It is possible that effective size is just > >> > few > >> > bytes smaller than the real size, so print both numbers only in case > >> > function print_size() prints formats them differently. > >> > > >> > Signed-off-by: Pali Rohár > >> > --- > >> > common/board_f.c | 31 ++- > >> > 1 file changed, 30 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/common/board_f.c b/common/board_f.c > >> > index 9e34fbee147e..3131a06db940 100644 > >> > --- a/common/board_f.c > >> > +++ b/common/board_f.c > >> > @@ -54,6 +54,7 @@ > >> > #include > >> > #include > >> > #include > >> > +#include > >> > > >> > /* > >> > * Pointer to initial global data area > >> > @@ -213,6 +214,30 @@ static int announce_dram_init(void) > >> > return 0; > >> > } > >> > > >> > +/* > >> > + * Check if the sizes in their natural units written in decimal format > >> > with > >> > + * one fraction number are same. > >> > + */ > >> > +static int sizes_near(unsigned long long size1, unsigned long long > >> > size2) > >> > +{ > >> > + unsigned int size1_scale = ilog2(size1) / 10 * 10; > >> > + unsigned int size1_val = (10 * size1 + ((1ULL << size1_scale) >> > >> > 1)) >> size1_scale; > >> > + unsigned int size2_scale = ilog2(size2) / 10 * 10; > >> > + unsigned int size2_val = (10 * size2 + ((1ULL << size2_scale) >> > >> > 1)) >> size2_scale; > >> > >> Can you put that expression into a function with a comment, etc.? It > >> is a bit hard to understand. > > > > Ok. > > > >> > + > >> > + if (size1_val == 10240) { > >> > + size1_val = 10; > >> > + size1_scale += 10; > >> > + } > >> > + > >> > + if (size2_val == 10240) { > >> > + size2_val = 10; > >> > + size2_scale += 10; > >> > + } > >> > >> If you are doing the same thing to each, why bother? It should not > >> affect the expression below, should it? : > > > > This is interesting question, and the answer it that it is required and > > affects comparison expression below. For example for the case when size1 > > is below 1GB limit, size2 is above 1GB limit and both values are near. > > Imagine that size1 is approaching value 1GB from the left and size2 from > > the right side. > > > >> > + > >> > + return size1_scale == size2_scale && size1_val == size2_val; > >> > +} > >> > + > >> > static int show_dram_config(void) > >> > { > >> > unsigned long long size; > >> > @@ -229,7 +254,11 @@ static int show_dram_config(void) > >> > } > >> > debug("\nDRAM: "); > >> > > >> > - print_size(size, ""); > >> > + print_size(gd->ram_size, ""); > >> > + if (!sizes_near(gd->ram_size, size)) { > >> > + printf(" (effective "); > >> > + print_size(size, ")"); > >> > + } > >> > board_add_ram_info(0); > >> > putc('\n'); > >> > > >> > -- > >> > 2.20.1 > >> > > >> > >> Can we make this testable somehow? You could put the new code into a > >> lib/ function, perhaps, and call it from a C unit test in test/lib ? > >> > >> Regards, > >> Simon > > > > Meh... I do not know how to test such code. Due to size / optimization > > requirements it is not a good idea to make function outside of board_f.c > > file. > > > > You can use TEST_STATIC from test/export.h this case. Good point, Sean. Also LTO take away most//all of the cost of making a static function global. Regards, Simon
Re: [PATCH v2] display_options: print_size: Fix order overflow
On Mon, 12 Sept 2022 at 13:03, Pali Rohár wrote: > > Function print_size() round size to the nearst value with one decimal > fraction number. But in special cases also unit order may overflow. > > For example value 1073689396 is printed as "1024 MiB" and value 1073741824 > as "1 GiB". > > Fix this issue by detecting order overflow and increasing unit order. > With this change also value 1073689396 is printed as "1 GiB". > > Signed-off-by: Pali Rohár > > --- > Changes in v2: > * Add unit test case > --- > lib/display_options.c | 6 ++ > test/lib/test_print.c | 3 +++ > 2 files changed, 9 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 09/24] blk: Rename HAVE_BLOCK_DEVICE
Hi Heinrich, On Wed, 14 Sept 2022 at 01:40, Heinrich Schuchardt wrote: > > On 9/14/22 03:42, AKASHI Takahiro wrote: > > On Thu, Aug 11, 2022 at 07:34:48PM -0600, Simon Glass wrote: > >> This option is fact really related to SPL. For U-Boot proper we always use > >> driver model for block devices, so CONFIG_BLK is enabled if block devices > >> are in use. > >> > >> It is only for SPL that we have two cases: > >> > >> - SPL_BLK is enabled, in which case we use driver model and blk-uclass.c > >> - SPL_BLK is not enabled, in which case (if we need block devices) we must > >>use blk_legacy.c > >> > >> Rename the symbol to SPL_LEGACY_BLOCK to make this clear. This is > >> different enough from BLK and SPL_BLK that there should be no confusion. > >> > >> Signed-off-by: Simon Glass > >> --- > >> > >> (no changes since v1) > >> > >> common/spl/Kconfig | 4 ++-- > >> configs/axm_defconfig | 2 +- > >> configs/bcm968380gerg_ram_defconfig| 2 +- > >> configs/gardena-smart-gateway-mt7688_defconfig | 2 +- > >> configs/nsim_hs38_defconfig| 2 +- > >> configs/qemu-ppce500_defconfig | 2 +- > >> disk/Makefile | 4 ++-- > >> disk/disk-uclass.c | 3 +-- > >> doc/develop/driver-model/migration.rst | 2 +- > >> drivers/Makefile | 2 +- > >> drivers/ata/Kconfig| 2 +- > >> drivers/block/Kconfig | 8 > >> drivers/block/Makefile | 2 +- > >> drivers/mmc/Kconfig| 2 +- > >> drivers/nvme/Kconfig | 2 +- > >> drivers/scsi/Kconfig | 2 +- > >> drivers/xen/Kconfig| 2 +- > >> include/blk.h | 2 +- > >> lib/efi_loader/Kconfig | 2 +- > >> 19 files changed, 24 insertions(+), 25 deletions(-) > >> > >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > >> index ee98810e9e9..4c3e74ae5eb 100644 > >> --- a/common/spl/Kconfig > >> +++ b/common/spl/Kconfig > >> @@ -792,7 +792,7 @@ config SPL_DM_MAILBOX > >> config SPL_MMC > >> bool "Support MMC" > >> depends on MMC > >> -select HAVE_BLOCK_DEVICE > >> +select SPL_LEGACY_BLOCK > >> help > >>Enable support for MMC (Multimedia Card) within SPL. This enables > >>the MMC protocol implementation and allows any enabled drivers to > >> @@ -1318,7 +1318,7 @@ config SPL_THERMAL > >> > >> config SPL_USB_HOST > >> bool "Support USB host drivers" > >> -select HAVE_BLOCK_DEVICE > >> +select SPL_LEGACY_BLOCK > >> help > >>Enable access to USB (Universal Serial Bus) host devices so that > >>SPL can load U-Boot from a connected USB peripheral, such as a USB > >> diff --git a/configs/axm_defconfig b/configs/axm_defconfig > >> index a5f60bd8d0c..c42fb37d6c9 100644 > >> --- a/configs/axm_defconfig > >> +++ b/configs/axm_defconfig > >> @@ -80,7 +80,7 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y > >> CONFIG_SPL_DM=y > >> CONFIG_BLK=y > >> -CONFIG_HAVE_BLOCK_DEVICE=y > >> +CONFIG_SPL_LEGACY_BLOCK=y > >> CONFIG_CLK=y > >> CONFIG_CLK_AT91=y > >> CONFIG_AT91_GPIO=y > >> diff --git a/configs/bcm968380gerg_ram_defconfig > >> b/configs/bcm968380gerg_ram_defconfig > >> index 0475535e991..246add6029c 100644 > >> --- a/configs/bcm968380gerg_ram_defconfig > >> +++ b/configs/bcm968380gerg_ram_defconfig > >> @@ -42,7 +42,7 @@ CONFIG_CMD_NAND=y > >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y > >> # CONFIG_NET is not set > >> # CONFIG_DM_DEVICE_REMOVE is not set > >> -CONFIG_HAVE_BLOCK_DEVICE=y > >> +CONFIG_SPL_LEGACY_BLOCK=y > >> CONFIG_BCM6345_GPIO=y > >> CONFIG_LED=y > >> CONFIG_LED_BCM6328=y > >> diff --git a/configs/gardena-smart-gateway-mt7688_defconfig > >> b/configs/gardena-smart-gateway-mt7688_defconfig > >> index b9ee281be9f..fdfab14d53e 100644 > >> --- a/configs/gardena-smart-gateway-mt7688_defconfig > >> +++ b/configs/gardena-smart-gateway-mt7688_defconfig > >> @@ -78,7 +78,7 @@ CONFIG_VERSION_VARIABLE=y > >> CONFIG_NET_RANDOM_ETHADDR=y > >> CONFIG_SPL_DM=y > >> # CONFIG_DM_DEVICE_REMOVE is not set > >> -CONFIG_HAVE_BLOCK_DEVICE=y > >> +CONFIG_SPL_LEGACY_BLOCK=y > >> CONFIG_BOOTCOUNT_LIMIT=y > >> CONFIG_LED=y > >> CONFIG_LED_BLINK=y > >> diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig > >> index 3c3d1812a79..3f23fc4189f 100644 > >> --- a/configs/nsim_hs38_defconfig > >> +++ b/configs/nsim_hs38_defconfig > >> @@ -30,7 +30,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y > >> CONFIG_USE_BOOTFILE=y > >> CONFIG_BOOTFILE="uImage" > >> CONFIG_BLK=y > >> -CONFIG_HAVE_BLOCK_DEVICE=y > >> +CONFIG_SPL_LEGACY_BLOCK=y > >> CONFIG_DM_ETH=y > >> CONFIG_DM_SERIAL=y > >> CONFIG_DEBUG_UART_SHIFT=2 > >> diff --
Re: [PATCH v2 22/24] blk: Drop if_type
Hi Heinrich, On Tue, 13 Sept 2022 at 10:27, Heinrich Schuchardt wrote: > > On 8/12/22 03:35, Simon Glass wrote: > > Use the uclass ID instead. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v1) > > > > cmd/blk_common.c | 2 +- > > drivers/block/blk-uclass.c | 34 +++ > > drivers/block/blk_legacy.c | 20 +-- > > include/blk.h | 41 ++ > > include/efi_loader.h | 2 +- > > 5 files changed, 48 insertions(+), 51 deletions(-) > > [..] > > /* EFI system partition */ > > extern struct efi_system_partition { > > - enum if_type if_type; > > + enum uclass_id if_type; > > int devnum; > > Please, rename the field if_type to class_id in a later patch. Yes, this is done in a later patch: enum uclass_id uclass_id; > > Uclass ID and device number may refer to a different device after > commands like usb init. It would be better if we could use the partition > GUID to identify a partition in the long term. But that is beyond the > scope of this series. > > Acked-by: Heinrich Schuchardt > Thanks for the review. Regards, Simon
Re: [PATCH 8/8] image: Drop some other #ifdefs in image-board.c
Hi Heinrich, On Wed, 14 Sept 2022 at 10:22, Heinrich Schuchardt wrote: > > On 8/28/22 20:32, Simon Glass wrote: > > Remove all but a few that are difficult, relying on legacy CONFIG options > > or optional global_data fields. > > > > Drop the duplicate function name in the comment for boot_get_cmdline(). > > > > Signed-off-by: Simon Glass > > --- > > > > boot/image-board.c | 67 +- > > include/image.h| 6 + > > 2 files changed, 42 insertions(+), 31 deletions(-) > > > > diff --git a/boot/image-board.c b/boot/image-board.c > > index 7a17ffb7f7f..1be0a359aba 100644 > > --- a/boot/image-board.c > > +++ b/boot/image-board.c > > @@ -16,6 +16,7 @@ > > #include > > #include > > #include > > +#include > > This looks like an unrelated change. Yes, probably left in after some debugging. But it doesn't hurt, since at present log.h is being included by one of the other includes... Regards, Simon
Re: [PATCH 1/1] doc: improve description of autostart
On Tue, 13 Sept 2022 at 01:00, Heinrich Schuchardt wrote: > > Complete the list of commands influenced by the autostart environment > variable. > > Make it clearer what values qualifies at 'yes'. > > Eventually the list of environment variables to be alphabetically sorted. > Move autostart up. > > Signed-off-by: Heinrich Schuchardt > --- > doc/usage/environment.rst | 34 +- > 1 file changed, 21 insertions(+), 13 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH] gpio: uclass: Introduce gpio-hog-optional property
Hi, On Wed, 14 Sept 2022 at 08:31, Nate Drude wrote: > > Hi All, > > On 9/14/22 9:16 AM, Tom Rini wrote: > > On Wed, Sep 14, 2022 at 08:59:52AM -0500, Nate Drude wrote: > >> Hi Simon, > >> > >> On 9/14/22 7:49 AM, Simon Glass wrote: > >>> Hi Nate, > >>> > >>> On Mon, 12 Sept 2022 at 14:57, Nate Drude wrote: > > Hi Simon and Fabio, > > On 9/12/22 3:16 PM, Simon Glass wrote: > > Hi, > > > > On Mon, 12 Sept 2022 at 12:48, Fabio Estevam wrote: > >> > >> Hi Nate and Simon, > >> > >> On Mon, Sep 12, 2022 at 2:55 PM Nate Drude > >> wrote: > >>> > >>> gpio_hog_probe_all is invoked by init_sequence_r in board_r.c. > >>> If device_probe fails for any gpio-hog, boot hangs with the following > >>> error: > >>> > initcall sequence fffc8e18 failed at call 4023b320 > (err=-121) > ### ERROR ### Please RESET the board ### > >>> > >>> gpio-hog-optional allows the boot sequence to continue if device_probe > >>> fails for optional gpio-hog(s). > >>> > >>> Signed-off-by: Nate Drude > >>> --- > >>> doc/device-tree-bindings/gpio/gpio.txt | 1 + > >>> drivers/gpio/gpio-uclass.c | 4 +++- > >>> 2 files changed, 4 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/doc/device-tree-bindings/gpio/gpio.txt > >>> b/doc/device-tree-bindings/gpio/gpio.txt > >>> index 1481ed607d..02d296316b 100644 > >>> --- a/doc/device-tree-bindings/gpio/gpio.txt > >>> +++ b/doc/device-tree-bindings/gpio/gpio.txt > >>> @@ -189,6 +189,7 @@ gpio-controller's driver probe function. > >>> Each GPIO hog definition is represented as a child node of the > >>> GPIO controller. > >>> Required properties: > >>> - gpio-hog: A property specifying that this child node > >>> represents a GPIO hog. > >>> +- gpio-hog-optional: A property specifying to continue boot when > >>> device_probe fails in gpio_hog_probe_all > >> > >> gpio-hog-optional property does not exist in Linux. > >> > >> If this property is introduced then U-Boot and Linux devicetrees will > >> not be in sync. > >> > >> Can this be fixed differently? > > > > Nate, can you send a patch to Linux with the binding update? > > > > Regards, > > Simon > > Thanks for your responses and feedback. > > I don't think gpio-hog-optional is relevant to Linux. > >>> > >>> Sure, but Linux is (for better or worse) the main repo for the device > >>> tree bindings. > >> > >> I am not understanding the action. I think you're suggesting I update the > >> Linux device tree bindings so they stay aligned with U-Boot, adding a > >> property gpio-hog-optional after this line: > >> https://github.com/torvalds/linux/blob/v6.0-rc5/Documentation/devicetree/bindings/gpio/gpio.txt#L191 > >> > >> However, since it's not relevant to Linux, I think it will be confusing > >> since it will have no effect and won't be be used in any Linux code. > >> > >> Can you please advise what description I should use for the > >> gpio-hog-optional property so that the Linux maintainers would accept such > >> a > >> patch? You can mention why it is needed and use a u-boot, property-name prefix perhaps. > > > > Yes, that would be one way to go about this, and there are other > > non-Linux bindings in the Linux kernel tree, but this might be the first > > property of an existing binding, so that might also be a bit challenging > > to get accepted, or find out what the preferred solution is. > > > > [snip] > Do you have any suggestions for a better approach? Does it make sense > for gpio_hog_probe_all to cause a fatal error when the gpio hog probe > fails (most devices, including the gpio-expander, will not cause a hang > if they fail to probe)? > >>> > >>> I think your approach is fine as is. > >> > >> An alternate approach is to modify the default behavior so that > >> gpio_hog_probe_all will not trigger a fatal error. Do you think this is > >> better? > > > > This too would be acceptable. I don't like this as it introduces undefined behaviour and may cause the boot to fail with no indication of what has happened, nor any way for higher-level code to resolve the issue. Anything we do here should be deterministic. Failures should be ignored only when the board vendor wants that. > > > > Thanks for the discussion and feedback. I prefer to avoid changing the > bindings in Linux if possible. > > Would it be acceptable if I rework gpio_hog_probe_all so that it prints > an error "Failed to probe device..." if any device_probe fails, but > always returns 0 to avoid a fatal error in board_init_r? I can submit a > v2 patch, but I want to screen any problems with the approach first. How would this be controlled? One option might be to add a binding to the /options node. I don't like it, but it could be a fallback if yo
Re: [PATCH] board_f: show_dram_config: Print also real DRAM size
On Wednesday 14 September 2022 11:10:20 Simon Glass wrote: > LTO take away most//all of the cost of making a static function global. This is not solution as LTO does not work on powerpc and as I figured today, it is broken also on some 32-bit ARM platforms (e.g. mvebu).
Re: [PATCH] board_f: show_dram_config: Print also real DRAM size
Hi Pali, On Wed, 14 Sept 2022 at 11:32, Pali Rohár wrote: > > On Wednesday 14 September 2022 11:10:20 Simon Glass wrote: > > LTO take away most//all of the cost of making a static function global. > > This is not solution as LTO does not work on powerpc and as I figured > today, it is broken also on some 32-bit ARM platforms (e.g. mvebu). Yes, various platforms need debugging of particular issues, as I understand it. Anyway, Sean's solution should work fine and doesn't need LTO. - Simon
Re: [PATCH 1/4] Makefile: Add a Python-based CONFIG checker
On Mon, Aug 29, 2022 at 07:57:04AM -0600, Simon Glass wrote: > The existing shell script is a bit ugly. It was picked up by > Chromium OS and then rewritten in Python, adding unit tests. Bring this > new version into U-Boot. > > Signed-off-by: Simon Glass > --- > > scripts/kconfig_check.py | 338 ++ > scripts/test_kconfig_check.py | 185 +++ > 2 files changed, 523 insertions(+) > create mode 100755 scripts/kconfig_check.py > create mode 100755 scripts/test_kconfig_check.py All told, this ends up being +400 or so lines to replace a shell script with Python. I'm not sure that's a win overall. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/4] common/board_f: remove XTRN_DECLARE_GLOBAL_DATA_PTR dead code
On Tue, Sep 13, 2022 at 09:31:26PM +0300, Ovidiu Panait wrote: > The XTRN_DECLARE_GLOBAL_DATA_PTR declarations in ppc code are permanently > commented out, so there are no users for this macro: > #if 1 >#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2") > #else /* We could use plain global data, but the resulting code is bigger */ >#define XTRN_DECLARE_GLOBAL_DATA_PTR extern >#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \ >gd_t *gd > #endif > > Remove all references to this macro, but add a documentation note regarding > the possibility of using plain global data for the GD pointer. > > Signed-off-by: Ovidiu Panait Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH 2/2] boot: image-pre-load: Check environment for location of signature info
Setting an alternative signature info node in "pre_load_sig_info_path" allows verification of an image using the bootm pre-load mechanism with a different key, e.g.: setenv pre_load_sig_info_path "/alt/sig" ; bootm preload [addr] Signed-off-by: Steven Lawrance --- boot/image-pre-load.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/boot/image-pre-load.c b/boot/image-pre-load.c index 01b60030fc..b504ab42a5 100644 --- a/boot/image-pre-load.c +++ b/boot/image-pre-load.c @@ -33,6 +33,7 @@ static int image_pre_load_sig_setup(struct image_sig_info *info) const u32 *sig_size; int key_len; int node, ret = 0; + char *sig_info_path = NULL; if (!info) { log_err("ERROR: info is NULL for image pre-load sig check\n"); @@ -42,7 +43,11 @@ static int image_pre_load_sig_setup(struct image_sig_info *info) memset(info, 0, sizeof(*info)); - node = fdt_path_offset(gd_fdt_blob(), IMAGE_PRE_LOAD_PATH); + sig_info_path = env_get("pre_load_sig_info_path"); + if (!sig_info_path) + sig_info_path = IMAGE_PRE_LOAD_PATH; + + node = fdt_path_offset(gd_fdt_blob(), sig_info_path); if (node < 0) { log_info("INFO: no info for image pre-load sig check\n"); ret = 1; -- 2.37.2
[PATCH 1/2] image-pre-load: Move macros/definitions to image.h
Putting these definitions in a header will allow signatures to be validated independently of bootm. Signed-off-by: Steven Lawrance --- boot/image-pre-load.c | 43 --- include/image.h | 43 +++ tools/image-host.c| 2 -- 3 files changed, 43 insertions(+), 45 deletions(-) diff --git a/boot/image-pre-load.c b/boot/image-pre-load.c index 5ab9ae1874..01b60030fc 100644 --- a/boot/image-pre-load.c +++ b/boot/image-pre-load.c @@ -11,49 +11,6 @@ DECLARE_GLOBAL_DATA_PTR; #include -#define IMAGE_PRE_LOAD_SIG_MAGIC 0x55425348 -#define IMAGE_PRE_LOAD_SIG_OFFSET_MAGIC0 -#define IMAGE_PRE_LOAD_SIG_OFFSET_IMG_LEN 4 -#define IMAGE_PRE_LOAD_SIG_OFFSET_SIG 8 - -#define IMAGE_PRE_LOAD_PATH"/image/pre-load/sig" -#define IMAGE_PRE_LOAD_PROP_ALGO_NAME "algo-name" -#define IMAGE_PRE_LOAD_PROP_PADDING_NAME "padding-name" -#define IMAGE_PRE_LOAD_PROP_SIG_SIZE "signature-size" -#define IMAGE_PRE_LOAD_PROP_PUBLIC_KEY "public-key" -#define IMAGE_PRE_LOAD_PROP_MANDATORY "mandatory" - -/* - * Information in the device-tree about the signature in the header - */ -struct image_sig_info { - char *algo_name;/* Name of the algo (eg: sha256,rsa2048) */ - char *padding_name; /* Name of the padding */ - u8 *key;/* Public signature key */ - int key_len;/* Length of the public key */ - u32 sig_size; /* size of the signature (in the header) */ - int mandatory; /* Set if the signature is mandatory */ - - struct image_sign_info sig_info; /* Signature info */ -}; - -/* - * Header of the signature header - */ -struct sig_header_s { - u32 magic; - u32 version; - u32 header_size; - u32 image_size; - u32 offset_img_sig; - u32 flags; - u32 reserved0; - u32 reserved1; - u8 sha256_img_sig[SHA256_SUM_LEN]; -}; - -#define SIG_HEADER_LEN (sizeof(struct sig_header_s)) - /* * Offset of the image * diff --git a/include/image.h b/include/image.h index d7d756c645..10fe5115e7 100644 --- a/include/image.h +++ b/include/image.h @@ -1411,6 +1411,49 @@ struct crypto_algo *image_get_crypto_algo(const char *full_name); */ struct padding_algo *image_get_padding_algo(const char *name); +#define IMAGE_PRE_LOAD_SIG_MAGIC 0x55425348 +#define IMAGE_PRE_LOAD_SIG_OFFSET_MAGIC0 +#define IMAGE_PRE_LOAD_SIG_OFFSET_IMG_LEN 4 +#define IMAGE_PRE_LOAD_SIG_OFFSET_SIG 8 + +#define IMAGE_PRE_LOAD_PATH"/image/pre-load/sig" +#define IMAGE_PRE_LOAD_PROP_ALGO_NAME "algo-name" +#define IMAGE_PRE_LOAD_PROP_PADDING_NAME "padding-name" +#define IMAGE_PRE_LOAD_PROP_SIG_SIZE "signature-size" +#define IMAGE_PRE_LOAD_PROP_PUBLIC_KEY "public-key" +#define IMAGE_PRE_LOAD_PROP_MANDATORY "mandatory" + +/* + * Information in the device-tree about the signature in the header + */ +struct image_sig_info { + char *algo_name;/* Name of the algo (eg: sha256,rsa2048) */ + char *padding_name; /* Name of the padding */ + uint8_t *key; /* Public signature key */ + int key_len;/* Length of the public key */ + uint32_t sig_size; /* size of the signature (in the header) */ + int mandatory; /* Set if the signature is mandatory */ + + struct image_sign_info sig_info; /* Signature info */ +}; + +/* + * Header of the signature header + */ +struct sig_header_s { + uint32_t magic; + uint32_t version; + uint32_t header_size; + uint32_t image_size; + uint32_t offset_img_sig; + uint32_t flags; + uint32_t reserved0; + uint32_t reserved1; + uint8_t sha256_img_sig[SHA256_SUM_LEN]; +}; + +#define SIG_HEADER_LEN (sizeof(struct sig_header_s)) + /** * image_pre_load() - Manage pre load header * diff --git a/tools/image-host.c b/tools/image-host.c index 698adfb3e1..0bf18df50e 100644 --- a/tools/image-host.c +++ b/tools/image-host.c @@ -17,8 +17,6 @@ #include #include -#define IMAGE_PRE_LOAD_PATH "/image/pre-load/sig" - /** * fit_set_hash_value - set hash value in requested has node * @fit: pointer to the FIT format image header -- 2.37.2
Re: Pull request for efi next
On Wed, Sep 14, 2022 at 06:20:12PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > please, pull into the next branch. > > The following changes since commit c2238fcf0c4567bbd581882e5952047e71406f58: > > Merge branch '2022-09-13-add-aspeed-spi-controller' into next > (2022-09-13 15:55:33 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-next-2022-09-14 > > for you to fetch changes up to da4fb707ca095c223b67637e2525df4866e51c62: > > test: unit test for eficonfig (2022-09-14 08:43:32 +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13439 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] usb: Kconfig: Fix typo in SPL_DM_USB text
From: Fabio Estevam There is an extra "most" word in the SPL_DM_USB text that makes it confusing. Remove it. Signed-off-by: Fabio Estevam --- drivers/usb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index fd13cf31b529..f0255fa2eae3 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -48,7 +48,7 @@ config DM_USB automatically probed when found on the bus. config SPL_DM_USB - bool "Enable driver model for USB host most in SPL" + bool "Enable driver model for USB host in SPL" depends on SPL_DM && DM_USB default n if ARCH_MVEBU default y -- 2.25.1
Re: [PATCHv5] drivers: tee: i2c: support the NXP SE05x probe errata
On Tue, Aug 30, 2022 at 09:56:45PM +0200, Jorge Ramirez-Ortiz wrote: > Early instantiation of this I2C device would lock up when being > probed. > > https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf > 3.2.2 >In scenarios of detecting I2C ICs on the bus using an empty >I2C frame containing only the address the SE050 will block >the I2C bus. > > Tested on STM32MP1 > > Signed-off-by: Jorge Ramirez-Ortiz > Acked-by: Oleksandr Suvorov This fails causes failure to build on sandbox: https://source.denx.de/u-boot/u-boot/-/jobs/496922#L51 -- Tom signature.asc Description: PGP signature
Re: [PATCH] image: Ensure image header name is null terminated
On Tue, Aug 23, 2022 at 03:59:07PM +1000, Joel Stanley wrote: > When building with GCC 12: > > ../include/image.h:779:9: warning: ‘strncpy’ specified bound 32 equals > destination size [-Wstringop-truncation] > 779 | strncpy(image_get_name(hdr), name, IH_NMLEN); > | ^~~~ > > Ensure the copied string is null terminated by always setting the final > byte to 0. Shorten the strncpy to IH_NMLEN-1 as we will always overwrite > the last byte. > > We can't use strlcpy as this is code is built on the host as well as the > target. > > Fixes: b97a2a0a21f2 ("[new uImage] Define a API for image handling > operations") > Signed-off-by: Joel Stanley So this breaks some tests: https://source.denx.de/u-boot/u-boot/-/jobs/496773#L201 and it's not clear to me if the problem is the tests or the fix itself (should we be doing a buffer of IH_NMLEN+1 and ensuring that's NULL terminated? I don't know). -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] Makefile: Add a Python-based CONFIG checker
Hi Tom, On Wed, 14 Sept 2022 at 12:47, Tom Rini wrote: > > On Mon, Aug 29, 2022 at 07:57:04AM -0600, Simon Glass wrote: > > The existing shell script is a bit ugly. It was picked up by > > Chromium OS and then rewritten in Python, adding unit tests. Bring this > > new version into U-Boot. > > > > Signed-off-by: Simon Glass > > --- > > > > scripts/kconfig_check.py | 338 ++ > > scripts/test_kconfig_check.py | 185 +++ > > 2 files changed, 523 insertions(+) > > create mode 100755 scripts/kconfig_check.py > > create mode 100755 scripts/test_kconfig_check.py > > All told, this ends up being +400 or so lines to replace a shell script > with Python. I'm not sure that's a win overall. It is more maintainable, has tests (which should not detract from line count) and uses kconfiglib. We could remove the non-kconfig code perhaps, but half the code is comments. Perhaps we are going to delete all this anyway soon, I'm not sure? Regards, Simon > > -- > Tom
Re: [PATCH] image: Ensure image header name is null terminated
Hi, On Wed, 14 Sept 2022 at 16:11, Tom Rini wrote: > > On Tue, Aug 23, 2022 at 03:59:07PM +1000, Joel Stanley wrote: > > > When building with GCC 12: > > > > ../include/image.h:779:9: warning: ‘strncpy’ specified bound 32 equals > > destination size [-Wstringop-truncation] > > 779 | strncpy(image_get_name(hdr), name, IH_NMLEN); > > | ^~~~ > > > > Ensure the copied string is null terminated by always setting the final > > byte to 0. Shorten the strncpy to IH_NMLEN-1 as we will always overwrite > > the last byte. > > > > We can't use strlcpy as this is code is built on the host as well as the > > target. > > > > Fixes: b97a2a0a21f2 ("[new uImage] Define a API for image handling > > operations") > > Signed-off-by: Joel Stanley > > So this breaks some tests: > https://source.denx.de/u-boot/u-boot/-/jobs/496773#L201 > and it's not clear to me if the problem is the tests or the fix itself > (should we be doing a buffer of IH_NMLEN+1 and ensuring that's NULL > terminated? I don't know). My reading of it is that the field is of length IH_NMLEN and there is only a terminator if the string is shorter than that. So I don't think this patch is correct / needed. Perhaps we can find a way to silence the warning, e.g. using memcyp(xx,yy, min(IH_NMLEN, strnlen(yy, ...) + 1)) ? Regards, Simon
Re: [PATCH] imx8mq_evk: enlarge SYS_MALLOC_F_LEN
On 9/14/2022 7:51 PM, Heiko Thiery wrote: Hi, Am Mi., 14. Sept. 2022 um 13:34 Uhr schrieb Fabio Estevam : On Wed, Sep 14, 2022 at 1:12 AM Heiko Thiery wrote: When changing these values on the kontron_pitx_imx8m_defconfig this board also works again. Maybe it could be a good idea to change these values for all imx8mq boards. Yes, agreed. It would be great if someone could align these values for all imx8mq boards. Strange thing is, that we already had the value of 0x1 (introduced by 545eceb52062cdc995c45b9581174b7ae66b0e6f and reverted by b598957206e541b3f8876ae34a15fac6da90dcef) and Peng said that the MALLOC BASE address of the IMX8MQ is set to OCRAM_S amd has 32kB [1]. CONFIG_SPL_SYS_MALLOC_F_LEN should be set to 0x2000 CONFIG_SYS_MALLOC_F_LEN should be a bit larger after DM CLK enabled. Regards, Peng. [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fu-boot%2F718b5b97-2b53-06f0-540b-70dd45f3915c%40oss.nxp.com%2F&data=05%7C01%7Cpeng.fan%40nxp.com%7C7bec6a3ee3754efc681908da964777e0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637987530938669481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uLMVrBhVtoXCKJRIUXdKxan%2FemHbKb%2B64ZF4RFWk7Hc%3D&reserved=0 -- Heiko
[PATCH V2] Kconfig: enlarge CONFIG_SYS_MALLOC_F_LEN
From: Peng Fan "alloc space exhausted" happens in very early stage, which could be seen with DEBUG_UART options enabled and leeds to an non-functional board. kontron_pitx_imx8m: CONFIG_DEBUG_UART_BASE=0x3088 # for serial3 CONFIG_DEBUG_UART_CLOCK=2400 imx8mqevk: CONFIG_DEBUG_UART_BASE=0x3086 # for uart1 CONFIG_DEBUG_UART_CLOCK=2400 It is because CONFIG_SYS_MALLOC_F_LEN is too small and still leave CONFIG_SPL_SYS_MALLOC_F_LEN as 0x2000. Reported-by: Heiko Thiery Signed-off-by: Peng Fan --- V2: set for all i.MX8MQ Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 991b260182e..c8c22555a94 100644 --- a/Kconfig +++ b/Kconfig @@ -299,7 +299,7 @@ config SYS_MALLOC_F_LEN default 0x4000 if SANDBOX || RISCV || ARCH_APPLE || ROCKCHIP_RK3368 || \ ROCKCHIP_RK3399 default 0x8000 if RCAR_GEN3 - default 0x1 if ARCH_IMX8 || (ARCH_IMX8M && !IMX8MQ) + default 0x1 if ARCH_IMX8 || ARCH_IMX8M default 0x2000 help Before relocation, memory is very limited on many platforms. Still, @@ -325,6 +325,7 @@ config SPL_SYS_MALLOC_F_LEN depends on SYS_MALLOC_F && SPL default 0 if !SPL_FRAMEWORK default 0x2800 if RCAR_GEN3 + default 0x2000 if IMX8MQ default SYS_MALLOC_F_LEN help In SPL memory is very limited on many platforms. Still, -- 2.36.0
Re: [PATCH v4 0/4] net: Enable NC-SI support
On Tue, 23 Aug 2022 at 04:54, Joel Stanley wrote: > > On Mon, 8 Aug 2022 at 12:16, Joel Stanley wrote: > > > > Back in 2019 Sam submitted NC-SI support. The NC-SI PHY driver was > > merged (patches 1 and 2), but we never got around to merging patches 3 > > and 4: > > > > https://lore.kernel.org/u-boot/20190618013720.2823-1-...@mendozajonas.com/ > > > > Sam as long since moved on from working on the Aspeed BMCs, but the code > > has been in use in the vendor fork for some time. > > > > This refreshes his patches and enables support in the Aspeed defconfigs, > > giving compile coverage to the NC-SI phy. > > > > v4 splits the ncsi integration and cmd code into separate patches, and > > adds r-b from Ramon and Cédric to patches 3 and 4. > > We have review on these patches now. Can we get them merged? ping > > > > > Joel Stanley (1): > > config/aspeed: Enable NC-SI support > > > > Samuel Mendoza-Jonas (3): > > net: NC-SI setup and handling > > cmd: Add ncsi command > > net/ftgmac100: Add NC-SI mode support > > > > include/net.h | 2 +- > > include/phy.h | 2 ++ > > cmd/net.c | 22 ++ > > drivers/net/ftgmac100.c | 14 ++ > > drivers/net/phy/ncsi.c| 1 + > > drivers/net/phy/phy.c | 9 - > > net/net.c | 27 ++- > > cmd/Kconfig | 8 > > configs/evb-ast2500_defconfig | 2 ++ > > configs/evb-ast2600_defconfig | 2 ++ > > 10 files changed, 82 insertions(+), 7 deletions(-) > > > > -- > > 2.35.1 > >
Re: [PATCH v1] wdt: nuvoton: add expire function for generic reset
Hi Stefan Roese Thanks for your review. Here is my log from uboot master. And i add the debug log as below: --- U-Boot 2022.10-rc4-00038-ge3fce5e560-dirty (Sep 15 2022 - 09:58:25 +0800) CPU: NPCM750 A1 @ Model: Nuvoton npcm750 Development Board (Device Tree) DRAM: 464 MiB RNG: NPCM RNG module bind OK OTP: NPCM OTP module bind OK AES: NPCM AES module bind OK SHA: NPCM SHA module bind OK Core: 210 devices, 22 uclasses, devicetree: separate WDT: Started watchdog@801C without servicing (60s timeout) MMC: sdhci0@f0842000: 0 Loading Environment from SPIFlash... SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK In:serial@1000 Out: serial@1000 Err: serial@1000 Net: eth0: eth@f0802000, eth1: eth@f0825000 Hit any key to stop autoboot: 0 U-Boot>reset resetting ... jim[wdt_reboot_request] jim[npcm_wdt_expire_now] jim[npcm_wdt_reset] > > BootBlock by Nuvoton Technology Corp. Ver 10.10.17 > BB Basic Mar 24 2021 12:06:08 >CORSTC = 0x4fff9f9d >WD0RCR = 0x4fff9f9d >WD1RCR = 0x4fff9f9d >WD2RCR = 0x4fff9f9d >SWRSTC1= 0x4fff9f9d >SWRSTC2= 0x4fff9f9d >SWRSTC3= 0x4fff9f9d If you have any suggestions, please provide to me. I will follow to modify it. Best regards, Jim On Thu, Sep 15, 2022 at 10:23 AM jjl...@nuvoton.com wrote: > > > > -Original Message- > From: Stefan Roese > Sent: Wednesday, September 14, 2022 2:27 PM > To: Jim Liu ; CS20 JJLiu0 ; CS20 > YSChu ; CS20 KWLiu > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH v1] wdt: nuvoton: add expire function for generic reset > > On 13.09.22 08:19, Jim Liu wrote: > > Add expire_now function for generic sysreset request > > > > Signed-off-by: Jim Liu > > --- > > drivers/watchdog/npcm_wdt.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c > > index 256020f5d3..e56aa0ebe1 100644 > > --- a/drivers/watchdog/npcm_wdt.c > > +++ b/drivers/watchdog/npcm_wdt.c > > @@ -75,6 +75,11 @@ static int npcm_wdt_reset(struct udevice *dev) > > return 0; > > } > > > > +static int npcm_wdt_expire_now(struct udevice *dev, ulong flags) { > > + return npcm_wdt_reset(dev); > > +} > > + > > Does this really work? You are calling the watchdog reset function here in > the expire function, which will just reset / trigger the WDT. I would not > expect that this will expire the WDT and result in a CPU / SoC reset. > > Thanks, > Stefan > > > static int npcm_wdt_of_to_plat(struct udevice *dev) > > { > > struct npcm_wdt_priv *priv = dev_get_priv(dev); @@ -87,6 +92,7 @@ > > static int npcm_wdt_of_to_plat(struct udevice *dev) > > } > > > > static const struct wdt_ops npcm_wdt_ops = { > > + .expire_now = npcm_wdt_expire_now, > > .start = npcm_wdt_start, > > .reset = npcm_wdt_reset, > > .stop = npcm_wdt_stop, > > Viele Grüße, > Stefan Roese > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de > > > The privileged confidential information contained in this email is intended > for use only by the addressees as indicated by the original sender of this > email. If you are not the addressee indicated in this email or are not > responsible for delivery of the email to such a person, please kindly reply > to the sender indicating this fact and delete all copies of it from your > computer and network server immediately. Your cooperation is highly > appreciated. It is advised that any unauthorized use of confidential > information of Nuvoton is strictly prohibited; and any information in this > email irrelevant to the official business of Nuvoton shall be deemed as > neither given nor endorsed by Nuvoton.
Re: [PATCHv5] drivers: tee: i2c: support the NXP SE05x probe errata
On 14/09/22, Tom Rini wrote: > On Tue, Aug 30, 2022 at 09:56:45PM +0200, Jorge Ramirez-Ortiz wrote: > > > Early instantiation of this I2C device would lock up when being > > probed. > > > > https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf > > 3.2.2 > >In scenarios of detecting I2C ICs on the bus using an empty > >I2C frame containing only the address the SE050 will block > >the I2C bus. > > > > Tested on STM32MP1 > > > > Signed-off-by: Jorge Ramirez-Ortiz > > Acked-by: Oleksandr Suvorov > > This fails causes failure to build on sandbox: > https://source.denx.de/u-boot/u-boot/-/jobs/496922#L51 um, will send an updated patch - sorry about it. does that sandbox uses different build flags? > > -- > Tom
Re: [PATCH v6 0/8] Add support for cyclic function execution infrastruture
Hi Simon, On 14.09.22 19:09, Simon Glass wrote: Hi Stefan, On Wed, 14 Sept 2022 at 09:19, Stefan Roese wrote: On 14.09.22 16:47, Tom Rini wrote: On Wed, Sep 14, 2022 at 04:29:36PM +0200, Stefan Roese wrote: On 14.09.22 14:58, Tom Rini wrote: On Fri, 2 Sep 2022 13:57:46 +0200, Stefan Roese wrote: This patchset adds the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. [...] For the series, applied to u-boot/next, thanks! Thanks Tom. This patch series should not introduce any functional changes. The next one though, which migrates the WATCHDOG_RESET into the cyclic function execution IF needs a quite some testing. Perhaps it makes sense to pull this other series as well quite early in the release cycle, so that it receives a lot of "attention"? So that we have time to fix potential problems here. What do you think? Yes, the watchdog series should come to next, for v2023.01 as well. Are you comfortable with it now, or are you planning to v2 it? I've only tested it on an MIPS Octeon platform so far. Where I am a bit hesitant is, the very early watchdog integration and SPL. This definitely needs some extensive testing. I don't have any platform for this here ready right now. Once it is in -next, people will test it and we'll flush out any problems. Yes, agreed. This is the way. ;) Thanks, Stefan
Re: [PATCH v1] wdt: nuvoton: add expire function for generic reset
Hi Jim, On 15.09.22 04:35, Jim Liu wrote: Hi Stefan Roese Thanks for your review. Here is my log from uboot master. And i add the debug log as below: --- U-Boot 2022.10-rc4-00038-ge3fce5e560-dirty (Sep 15 2022 - 09:58:25 +0800) CPU: NPCM750 A1 @ Model: Nuvoton npcm750 Development Board (Device Tree) DRAM: 464 MiB RNG: NPCM RNG module bind OK OTP: NPCM OTP module bind OK AES: NPCM AES module bind OK SHA: NPCM SHA module bind OK Core: 210 devices, 22 uclasses, devicetree: separate WDT: Started watchdog@801C without servicing (60s timeout) MMC: sdhci0@f0842000: 0 Loading Environment from SPIFlash... SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK In:serial@1000 Out: serial@1000 Err: serial@1000 Net: eth0: eth@f0802000, eth1: eth@f0825000 Hit any key to stop autoboot: 0 U-Boot>reset resetting ... jim[wdt_reboot_request] jim[npcm_wdt_expire_now] jim[npcm_wdt_reset] Interesting. Thanks for sending this log. And what does "wdt expire" say? Thanks, Stefan BootBlock by Nuvoton Technology Corp. Ver 10.10.17 BB Basic Mar 24 2021 12:06:08 CORSTC = 0x4fff9f9d WD0RCR = 0x4fff9f9d WD1RCR = 0x4fff9f9d WD2RCR = 0x4fff9f9d SWRSTC1= 0x4fff9f9d SWRSTC2= 0x4fff9f9d SWRSTC3= 0x4fff9f9d If you have any suggestions, please provide to me. I will follow to modify it. Best regards, Jim On Thu, Sep 15, 2022 at 10:23 AM jjl...@nuvoton.com wrote: -Original Message- From: Stefan Roese Sent: Wednesday, September 14, 2022 2:27 PM To: Jim Liu ; CS20 JJLiu0 ; CS20 YSChu ; CS20 KWLiu Cc: u-boot@lists.denx.de Subject: Re: [PATCH v1] wdt: nuvoton: add expire function for generic reset On 13.09.22 08:19, Jim Liu wrote: Add expire_now function for generic sysreset request Signed-off-by: Jim Liu --- drivers/watchdog/npcm_wdt.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c index 256020f5d3..e56aa0ebe1 100644 --- a/drivers/watchdog/npcm_wdt.c +++ b/drivers/watchdog/npcm_wdt.c @@ -75,6 +75,11 @@ static int npcm_wdt_reset(struct udevice *dev) return 0; } +static int npcm_wdt_expire_now(struct udevice *dev, ulong flags) { + return npcm_wdt_reset(dev); +} + Does this really work? You are calling the watchdog reset function here in the expire function, which will just reset / trigger the WDT. I would not expect that this will expire the WDT and result in a CPU / SoC reset. Thanks, Stefan static int npcm_wdt_of_to_plat(struct udevice *dev) { struct npcm_wdt_priv *priv = dev_get_priv(dev); @@ -87,6 +92,7 @@ static int npcm_wdt_of_to_plat(struct udevice *dev) } static const struct wdt_ops npcm_wdt_ops = { + .expire_now = npcm_wdt_expire_now, .start = npcm_wdt_start, .reset = npcm_wdt_reset, .stop = npcm_wdt_stop, Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton. Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH V2] Kconfig: enlarge CONFIG_SYS_MALLOC_F_LEN
Hi, Am Do., 15. Sept. 2022 um 02:53 Uhr schrieb Peng Fan (OSS) : > > From: Peng Fan > > "alloc space exhausted" happens in very early stage, which could be seen > with DEBUG_UART options enabled and leeds to an non-functional board. > > kontron_pitx_imx8m: > CONFIG_DEBUG_UART_BASE=0x3088 # for serial3 > CONFIG_DEBUG_UART_CLOCK=2400 > > imx8mqevk: > CONFIG_DEBUG_UART_BASE=0x3086 # for uart1 > CONFIG_DEBUG_UART_CLOCK=2400 > > It is because CONFIG_SYS_MALLOC_F_LEN is too small and still leave > CONFIG_SPL_SYS_MALLOC_F_LEN as 0x2000. > > Reported-by: Heiko Thiery > Signed-off-by: Peng Fan Reviewed-by: Heiko Thiery Tested-by: Heiko Thiery Tested on: - kontron-pitx-imx8m - imx8mq_evk > --- > > V2: > set for all i.MX8MQ > > Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Kconfig b/Kconfig > index 991b260182e..c8c22555a94 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -299,7 +299,7 @@ config SYS_MALLOC_F_LEN > default 0x4000 if SANDBOX || RISCV || ARCH_APPLE || ROCKCHIP_RK3368 > || \ > ROCKCHIP_RK3399 > default 0x8000 if RCAR_GEN3 > - default 0x1 if ARCH_IMX8 || (ARCH_IMX8M && !IMX8MQ) > + default 0x1 if ARCH_IMX8 || ARCH_IMX8M > default 0x2000 > help > Before relocation, memory is very limited on many platforms. Still, > @@ -325,6 +325,7 @@ config SPL_SYS_MALLOC_F_LEN > depends on SYS_MALLOC_F && SPL > default 0 if !SPL_FRAMEWORK > default 0x2800 if RCAR_GEN3 > + default 0x2000 if IMX8MQ > default SYS_MALLOC_F_LEN > help > In SPL memory is very limited on many platforms. Still, > -- > 2.36.0 >
Re: [PATCH v1] wdt: nuvoton: add expire function for generic reset
Hi Stefan Roese Thanks for the quick reply. sorry for the topic naming. my mean is i add a npcm_wdt_expire_now function to support sysreset . Best regards, Jim On Thu, Sep 15, 2022 at 1:02 PM Stefan Roese wrote: > > Hi Jim, > > On 15.09.22 04:35, Jim Liu wrote: > > Hi Stefan Roese > > > > Thanks for your review. > > Here is my log from uboot master. > > And i add the debug log as below: > > > > --- > > U-Boot 2022.10-rc4-00038-ge3fce5e560-dirty (Sep 15 2022 - 09:58:25 +0800) > > > > CPU: NPCM750 A1 @ Model: Nuvoton npcm750 Development Board (Device Tree) > > DRAM: 464 MiB > > RNG: NPCM RNG module bind OK > > OTP: NPCM OTP module bind OK > > AES: NPCM AES module bind OK > > SHA: NPCM SHA module bind OK > > Core: 210 devices, 22 uclasses, devicetree: separate > > WDT: Started watchdog@801C without servicing (60s timeout) > > MMC: sdhci0@f0842000: 0 > > Loading Environment from SPIFlash... SF: Detected mx66l51235l with > > page size 256 Bytes, erase size 64 KiB, total 64 MiB > > OK > > In:serial@1000 > > Out: serial@1000 > > Err: serial@1000 > > Net: eth0: eth@f0802000, eth1: eth@f0825000 > > Hit any key to stop autoboot: 0 > > U-Boot>reset > > resetting ... > > jim[wdt_reboot_request] > > jim[npcm_wdt_expire_now] > > jim[npcm_wdt_reset] > > Interesting. Thanks for sending this log. And what does "wdt > expire" say? > > Thanks, > Stefan > > >> > >> BootBlock by Nuvoton Technology Corp. Ver 10.10.17 > >> > > > > BB Basic > > Mar 24 2021 > > 12:06:08 > > > > > > > > > >> CORSTC = 0x4fff9f9d > >> WD0RCR = 0x4fff9f9d > >> WD1RCR = 0x4fff9f9d > >> WD2RCR = 0x4fff9f9d > >> SWRSTC1= 0x4fff9f9d > >> SWRSTC2= 0x4fff9f9d > >> SWRSTC3= 0x4fff9f9d > > > > > > If you have any suggestions, please provide to me. > > I will follow to modify it. > > > > Best regards, > > Jim > > > > On Thu, Sep 15, 2022 at 10:23 AM jjl...@nuvoton.com > > wrote: > >> > >> > >> > >> -Original Message- > >> From: Stefan Roese > >> Sent: Wednesday, September 14, 2022 2:27 PM > >> To: Jim Liu ; CS20 JJLiu0 ; CS20 > >> YSChu ; CS20 KWLiu > >> Cc: u-boot@lists.denx.de > >> Subject: Re: [PATCH v1] wdt: nuvoton: add expire function for generic reset > >> > >> On 13.09.22 08:19, Jim Liu wrote: > >>> Add expire_now function for generic sysreset request > >>> > >>> Signed-off-by: Jim Liu > >>> --- > >>>drivers/watchdog/npcm_wdt.c | 6 ++ > >>>1 file changed, 6 insertions(+) > >>> > >>> diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c > >>> index 256020f5d3..e56aa0ebe1 100644 > >>> --- a/drivers/watchdog/npcm_wdt.c > >>> +++ b/drivers/watchdog/npcm_wdt.c > >>> @@ -75,6 +75,11 @@ static int npcm_wdt_reset(struct udevice *dev) > >>>return 0; > >>>} > >>> > >>> +static int npcm_wdt_expire_now(struct udevice *dev, ulong flags) { > >>> + return npcm_wdt_reset(dev); > >>> +} > >>> + > >> > >> Does this really work? You are calling the watchdog reset function here in > >> the expire function, which will just reset / trigger the WDT. I would not > >> expect that this will expire the WDT and result in a CPU / SoC reset. > >> > >> Thanks, > >> Stefan > >> > >>>static int npcm_wdt_of_to_plat(struct udevice *dev) > >>>{ > >>>struct npcm_wdt_priv *priv = dev_get_priv(dev); @@ -87,6 +92,7 @@ > >>> static int npcm_wdt_of_to_plat(struct udevice *dev) > >>>} > >>> > >>>static const struct wdt_ops npcm_wdt_ops = { > >>> + .expire_now = npcm_wdt_expire_now, > >>>.start = npcm_wdt_start, > >>>.reset = npcm_wdt_reset, > >>>.stop = npcm_wdt_stop, > >> > >> Viele Grüße, > >> Stefan Roese > >> > >> -- > >> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > >> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de > >> > >> > >> The privileged confidential information contained in this email is > >> intended for use only by the addressees as indicated by the original > >> sender of this email. If you are not the addressee indicated in this email > >> or are not responsible for delivery of the email to such a person, please > >> kindly reply to the sender indicating this fact and delete all copies of > >> it from your computer and network server immediately. Your cooperation is > >> highly appreciated. It is advised that any unauthorized use of > >> confidential information of Nuvoton is strictly prohibited; and any > >> information in this email irrelevant to the official business of Nuvoton > >> shall be deemed as neither given nor endorsed by Nuvoton. > > Viele Grüße, > Stefan Roese > > -- > DENX Software En