Re: [PATCH v2 1/3] efi_loader: Add SPI I/O protocol support

2022-09-14 Thread Heinrich Schuchardt

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

2022-09-14 Thread Heiko Thiery
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

2022-09-14 Thread Heinrich Schuchardt

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

2022-09-14 Thread Heinrich Schuchardt

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

2022-09-14 Thread Heiko Thiery
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

2022-09-14 Thread AKASHI Takahiro
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

2022-09-14 Thread patrick.delaunay
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

2022-09-14 Thread Sughosh Ganu


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

2022-09-14 Thread Sughosh Ganu
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

2022-09-14 Thread Sughosh Ganu
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

2022-09-14 Thread Sughosh Ganu
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

2022-09-14 Thread Fabio Estevam
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

2022-09-14 Thread 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.


[PATCH] armv8: cache_v8: Fix pgtables setup when MMU is already enabled

2022-09-14 Thread Pali Rohár
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

2022-09-14 Thread Heiko Thiery
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Pali Rohár
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

2022-09-14 Thread Pali Rohár
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

2022-09-14 Thread Nate Drude

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

2022-09-14 Thread Fabio Estevam
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Andre Przywara
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

2022-09-14 Thread Stefan Roese

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

2022-09-14 Thread Nate Drude

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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Stefan Roese

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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Tim Harvey
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

2022-09-14 Thread Heinrich Schuchardt

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

2022-09-14 Thread Heinrich Schuchardt

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

2022-09-14 Thread Pali Rohár
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Pali Rohár
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Steven Lawrance
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

2022-09-14 Thread Steven Lawrance
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Fabio Estevam
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Tom Rini
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Simon Glass
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

2022-09-14 Thread Peng Fan




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

2022-09-14 Thread 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 
---

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

2022-09-14 Thread Joel Stanley
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

2022-09-14 Thread Jim Liu
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

2022-09-14 Thread Jorge Ramirez-Ortiz, Foundries
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

2022-09-14 Thread Stefan Roese

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

2022-09-14 Thread Stefan Roese

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

2022-09-14 Thread Heiko Thiery
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

2022-09-14 Thread Jim Liu
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