[PULL] u-boot-riscv/master

[Leo Liang]

Hi Tom, 

The following changes since commit fb1018106a7bbb1a0d723029f6760b1b1b4d306d:

  Merge branch '2021-10-19-assorted-changes' (2021-10-19 20:45:12 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-riscv.git 

for you to fetch changes up to ddf4972834fdf33f0a3360ff4a68fde333995113:

  riscv: Avoid io read/write cause wrong result (2021-10-20 10:59:17 +0800)

SI result shows no issue: 
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/9532


Bin Meng (10):
  board: sifive: Fix a potential build warning in board_fdt_blob_setup()
  cache: sifive: Fix -Wint-to-pointer-cast warning
  clk: sifive: Fix -Wint-to-pointer-cast warning
  gpio: sifive: Fix -Wint-to-pointer-cast warning
  i2c: ocores: Fix -Wint-to-pointer-cast warning
  dm: core: Add a new API devfdt_get_addr_index_ptr()
  dm: Provide dev_read_addr_index_ptr() wrapper
  net: macb: Fix -Wint-to-pointer-cast warnings
  ram: sifive: Fix -Wint-to-pointer-cast warnings
  board: sifive: Fix -Wint-to-pointer-cast warning

Nick Hu (1):
  riscv: Avoid io read/write cause wrong result

 arch/riscv/include/asm/io.h | 18 +-
 board/sifive/unleashed/unleashed.c  |  6 +++---
 board/sifive/unmatched/unmatched.c  |  6 +++---
 drivers/cache/cache-sifive-ccache.c |  2 +-
 drivers/clk/sifive/sifive-prci.c|  6 +++---
 drivers/core/fdtaddr.c  | 11 ---
 drivers/gpio/sifive-gpio.c  |  6 ++
 drivers/i2c/ocores_i2c.c|  2 +-
 drivers/net/macb.c  | 11 +++
 drivers/ram/sifive/sifive_ddr.c |  8 
 include/dm/fdtaddr.h| 12 
 include/dm/read.h   | 18 ++
 12 files changed, 67 insertions(+), 39 deletions(-)

Best regards,
Leo

Re: [PATCH v2 15/16] clk: Detect failure to set defaults

[Rasmus Villemoes]

On 20/08/2021 20.18, Simon Glass wrote:
> Hi Harm,
> 
> On Wed, 18 Aug 2021 at 08:09, Harm Berntsen  wrote:
>>
>> On Thu, 2021-05-13 at 19:39 -0600, Simon Glass wrote:
>>>  int clk_uclass_post_probe(struct udevice *dev)
>>>  {
>>> +   int ret;
>>> +
>>> /*
>>>  * when a clock provider is probed. Call clk_set_defaults()
>>>  * also after the device is probed. This takes care of cases
>>>  * where the DT is used to setup default parents and rates
>>>  * using assigned-clocks
>>>  */
>>> -   clk_set_defaults(dev, 1);
>>> +   ret = clk_set_defaults(dev, 1);
>>> +   if (ret)
>>> +   return log_ret(ret);
>>>
>>> return 0;
>>>  }
>>
>> Note that this patch broke booting my imx8mn based board on U-Boot
>> v2021.10-rc2. 

I just ran into the same issue with v2021.10 being broken for
imx8mp_evk, and git bisect pointing at this commit, symptoms being

U-Boot 2021.10 (Oct 20 2021 - 08:45:51 +0200)

CPU:   Freescale i.MX8MP[8] rev1.1 at 1200 MHz
...
MMC:   mmc@30b5 - probe failed: -2
mmc@30b6 - probe failed: -2

Reverting 92f1e9a4b on top of v2021.10 yields

U-Boot 2021.10-1-gac2520a138 (Oct 20 2021 - 09:05:48 +0200)

CPU:   Freescale i.MX8MP[8] rev1.1 at 1200 MHz
...
MMC:   FSL_SDHC: 1, FSL_SDHC: 2

cc += imx maintainers, this should not still be broken 2 months (and a
release) after it was reported.

Rasmus

[PATCH v2 0/2] pxe_utils: Fix arguments to x86 zboot

[Zhaofeng Li]

Hi Simon,

Thanks for your review! I have added a second patch to perform the
cleanup that you mentioned in the review, so the actual "fix" patch
stays minimal and easy to review.

I agree that calling the bootm and zboot code directly is the real
solution to go. The current method is inherently error-prone, and
I wonder how many cases of "kinda works but not really" [1] like
this are there in U-Boot.

Thanks,
Zhaofeng Li

[1] Without the patch, the kernel would boot with the U-Boot log
showing initrd being loaded. However, the kernel wouldn't
actually get the initrd.

---

This patch series fixes the issue that incorrect arguments are
passed to x86 zboot in pxe_utils (pxe/extlinux-like config). See
the commit message of the first patch for details.

Changes since v1:
- Added patch to clean up argv generation

Zhaofeng Li (2):
  pxe_utils: Fix arguments to x86 zboot
  pxe_utils: Clean up {bootm,zboot}_argv generation

 cmd/pxe_utils.c | 45 -
 1 file changed, 32 insertions(+), 13 deletions(-)

-- 
2.33.0

[PATCH v2 1/2] pxe_utils: Fix arguments to x86 zboot

[Zhaofeng Li]

bootm and zboot accept different arguments:

> bootm [addr [arg ...]]
>- boot application image stored in memory
>passing arguments 'arg ...'; when booting a Linux kernel,
>'arg' can be the address of an initrd image

> zboot [addr] [size] [initrd addr] [initrd size] [setup] [cmdline]
>   addr -The optional starting address of the bzimage.
> If not set it defaults to the environment
> variable "fileaddr".
>   size -The optional size of the bzimage. Defaults to
> zero.
>   initrd addr - The address of the initrd image to use, if any.
>   initrd size - The size of the initrd image to use, if any.

In the zboot flow, the current code will reuse the bootm args and attempt
to pass the initrd arg (argv[2]) as the kernel size (should be argv[3]).
zboot also expects the initrd address and size to be separate arguments.

Let's untangle them and have separate argv/argc locals.

Signed-off-by: Zhaofeng Li 
Cc: Simon Glass 
Cc: Bin Meng 
---
 cmd/pxe_utils.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 067c24e5ff..78ebfdcc79 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -441,11 +441,14 @@ skip_overlay:
 static int label_boot(struct cmd_tbl *cmdtp, struct pxe_label *label)
 {
char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
+   char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
char initrd_str[28];
+   char initrd_filesize[10];
char mac_str[29] = "";
char ip_str[68] = "";
char *fit_addr = NULL;
int bootm_argc = 2;
+   int zboot_argc = 3;
int len = 0;
ulong kernel_addr;
void *buf;
@@ -478,6 +481,11 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
strcat(bootm_argv[2], ":");
strncat(bootm_argv[2], env_get("filesize"), 9);
bootm_argc = 3;
+
+   strncpy(initrd_filesize, env_get("filesize"), 9);
+   zboot_argv[3] = env_get("ramdisk_addr_r");
+   zboot_argv[4] = initrd_filesize;
+   zboot_argc = 5;
}
 
if (get_relfile_envaddr(cmdtp, label->kernel, "kernel_addr_r") < 0) {
@@ -529,6 +537,8 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
}
 
bootm_argv[1] = env_get("kernel_addr_r");
+   zboot_argv[1] = env_get("kernel_addr_r");
+
/* for FIT, append the configuration identifier */
if (label->config) {
int len = strlen(bootm_argv[1]) + strlen(label->config) + 1;
@@ -665,7 +675,7 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
/* Try booting an x86_64 Linux kernel image */
else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
-   do_zboot_parent(cmdtp, 0, bootm_argc, bootm_argv, NULL);
+   do_zboot_parent(cmdtp, 0, zboot_argc, zboot_argv, NULL);
 
unmap_sysmem(buf);
 
-- 
2.33.0

[PATCH v2 2/2] pxe_utils: Clean up {bootm,zboot}_argv generation

[Zhaofeng Li]

Signed-off-by: Zhaofeng Li 
Cc: Simon Glass 
Cc: Bin Meng 
---
 cmd/pxe_utils.c | 45 +++--
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 78ebfdcc79..b79fcb6418 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -442,15 +442,17 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
 {
char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
-   char initrd_str[28];
+   char *kernel_addr = NULL;
+   char *initrd_addr_str = NULL;
char initrd_filesize[10];
+   char initrd_str[28];
char mac_str[29] = "";
char ip_str[68] = "";
char *fit_addr = NULL;
int bootm_argc = 2;
int zboot_argc = 3;
int len = 0;
-   ulong kernel_addr;
+   ulong kernel_addr_r;
void *buf;
 
label_print(label);
@@ -476,16 +478,12 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
return 1;
}
 
-   bootm_argv[2] = initrd_str;
-   strncpy(bootm_argv[2], env_get("ramdisk_addr_r"), 18);
-   strcat(bootm_argv[2], ":");
-   strncat(bootm_argv[2], env_get("filesize"), 9);
-   bootm_argc = 3;
-
+   initrd_addr_str = env_get("ramdisk_addr_r");
strncpy(initrd_filesize, env_get("filesize"), 9);
-   zboot_argv[3] = env_get("ramdisk_addr_r");
-   zboot_argv[4] = initrd_filesize;
-   zboot_argc = 5;
+
+   strncpy(initrd_str, initrd_addr_str, 18);
+   strcat(initrd_str, ":");
+   strncat(initrd_str, initrd_filesize, 9);
}
 
if (get_relfile_envaddr(cmdtp, label->kernel, "kernel_addr_r") < 0) {
@@ -536,20 +534,19 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
printf("append: %s\n", finalbootargs);
}
 
-   bootm_argv[1] = env_get("kernel_addr_r");
-   zboot_argv[1] = env_get("kernel_addr_r");
+   kernel_addr = env_get("kernel_addr_r");
 
/* for FIT, append the configuration identifier */
if (label->config) {
-   int len = strlen(bootm_argv[1]) + strlen(label->config) + 1;
+   int len = strlen(kernel_addr) + strlen(label->config) + 1;
 
fit_addr = malloc(len);
if (!fit_addr) {
printf("malloc fail (FIT address)\n");
return 1;
}
-   snprintf(fit_addr, len, "%s%s", bootm_argv[1], label->config);
-   bootm_argv[1] = fit_addr;
+   snprintf(fit_addr, len, "%s%s", kernel_addr, label->config);
+   kernel_addr = fit_addr;
}
 
/*
@@ -653,6 +650,18 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
}
}
 
+   bootm_argv[1] = kernel_addr;
+   zboot_argv[1] = kernel_addr;
+
+   if (initrd_addr_str) {
+   bootm_argv[2] = initrd_str;
+   bootm_argc = 3;
+
+   zboot_argv[3] = initrd_addr_str;
+   zboot_argv[4] = initrd_filesize;
+   zboot_argc = 5;
+   }
+
if (!bootm_argv[3])
bootm_argv[3] = env_get("fdt_addr");
 
@@ -662,8 +671,8 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
bootm_argc = 4;
}
 
-   kernel_addr = genimg_get_kernel_addr(bootm_argv[1]);
-   buf = map_sysmem(kernel_addr, 0);
+   kernel_addr_r = genimg_get_kernel_addr(kernel_addr);
+   buf = map_sysmem(kernel_addr_r, 0);
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID)
do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
-- 
2.33.0

Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Pali Rohár]

On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote:
> Some image types (kwbimage and mxsimage) always depend on OpenSSL, so
> they can only be included in mkimage when TOOLS_LIBCRYPTO is selected.
> Use Makefile logic to conditionally link the files.
> 
> Signed-off-by: Samuel Holland 

NAK.

As explained in previous email [1], kwbimage is required for building
Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms.
Therefore it cannot be disabled or hidden behind some user config
options for these platforms (and it does not matter if it is crypto
option or any other option). kwbimage must be unconditionally enabled on
these platforms like it was before this change, as it is crucial part of
build.

[1] - https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/

> ---
> 
> Changes in v4:
>  - Do not select TOOLS_LIBCRYPTO anywhere
> 
> Changes in v3:
>  - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best
>as I can tell, using the suggestions from Pali Rohár)
> 
> Changes in v2:
>  - Refactored the first patch on top of TOOLS_LIBCRYPTO
> 
>  scripts/config_whitelist.txt |  1 -
>  tools/Makefile   | 19 +--
>  tools/mxsimage.c |  3 ---
>  3 files changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index cd94b5777a..affae6875d 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -828,7 +828,6 @@ CONFIG_MXC_UART_BASE
>  CONFIG_MXC_USB_FLAGS
>  CONFIG_MXC_USB_PORT
>  CONFIG_MXC_USB_PORTSC
> -CONFIG_MXS
>  CONFIG_MXS_AUART
>  CONFIG_MXS_AUART_BASE
>  CONFIG_MXS_OCOTP
> diff --git a/tools/Makefile b/tools/Makefile
> index 999fd46531..a9b3d982d8 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -94,9 +94,11 @@ ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix 
> lib/ecdsa/, ecdsa-libcrypto.
>  AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \
>   aes-encrypt.o aes-decrypt.o)
>  
> -# Cryptographic helpers that depend on openssl/libcrypto
> -LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
> - fdt-libcrypto.o)
> +# Cryptographic helpers and image types that depend on openssl/libcrypto
> +LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := \
> + lib/fdt-libcrypto.o \
> + kwbimage.o \
> + mxsimage.o
>  
>  ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
>  
> @@ -118,10 +120,8 @@ dumpimage-mkimage-objs := aisimage.o \
>   imximage.o \
>   imx8image.o \
>   imx8mimage.o \
> - kwbimage.o \
>   lib/md5.o \
>   lpc32xximage.o \
> - mxsimage.o \
>   omapimage.o \
>   os_support.o \
>   pblimage.o \
> @@ -156,22 +156,13 @@ fit_info-objs   := $(dumpimage-mkimage-objs) fit_info.o
>  fit_check_sign-objs   := $(dumpimage-mkimage-objs) fit_check_sign.o
>  file2include-objs := file2include.o
>  
> -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_TOOLS_LIBCRYPTO),)
> -# Add CONFIG_MXS into host CFLAGS, so we can check whether or not register
> -# the mxsimage support within tools/mxsimage.c .
> -HOSTCFLAGS_mxsimage.o += -DCONFIG_MXS
> -endif
> -
>  ifdef CONFIG_TOOLS_LIBCRYPTO
>  # This affects include/image.h, but including the board config file
>  # is tricky, so manually define this options here.
>  HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE
>  HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
>  HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER
> -endif
>  
> -# MXSImage needs LibSSL
> -ifneq 
> ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
>  HOSTCFLAGS_kwbimage.o += \
>   $(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
>  HOSTLDLIBS_mkimage += \
> diff --git a/tools/mxsimage.c b/tools/mxsimage.c
> index 002f4b525a..2bfbb421eb 100644
> --- a/tools/mxsimage.c
> +++ b/tools/mxsimage.c
> @@ -5,8 +5,6 @@
>   * Copyright (C) 2012-2013 Marek Vasut 
>   */
>  
> -#ifdef CONFIG_MXS
> -
>  #include 
>  #include 
>  #include 
> @@ -2363,4 +2361,3 @@ U_BOOT_IMAGE_TYPE(
>   NULL,
>   mxsimage_generate
>  );
> -#endif
> -- 
> 2.32.0
> 

Re: [PATCH v4 05/11] tools: mkeficapsule: add firmwware image signing

[Masami Hiramatsu]

Hello Akashi-san,

Can you split this patch out from this series?
It seems that the series is doing several different things. This
capsule signing has no alternatives, but others are modifying or
replacing the current existing feature. In other words, this capsule
signing feature has no alternatives, but others we can continue to
use.

Thank you,

2021年10月7日(木) 15:25 AKASHI Takahiro :
>
> With this enhancement, mkeficapsule will be able to sign a capsule
> file when it is created. A signature added will be used later
> in the verification at FMP's SetImage() call.
>
> To do that, We need specify additional command parameters:
>   -monotonic-cout  : monotonic count
>   -private-key  : private key file
>   -certificate  : certificate file
> Only when all of those parameters are given, a signature will be added
> to a capsule file.
>
> Users are expected to maintain and increment the monotonic count at
> every time of the update for each firmware image.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  tools/Kconfig|   7 +
>  tools/Makefile   |   8 +-
>  tools/mkeficapsule.c | 435 +++
>  3 files changed, 416 insertions(+), 34 deletions(-)
>
> diff --git a/tools/Kconfig b/tools/Kconfig
> index d6f82cd949b5..9a37ed035311 100644
> --- a/tools/Kconfig
> +++ b/tools/Kconfig
> @@ -20,4 +20,11 @@ config TOOLS_LIBCRYPTO
>   This selection does not affect target features, such as runtime FIT
>   signature verification.
>
> +config TOOLS_MKEFICAPSULE
> +   bool "Build efimkcapsule command"
> +   default y if EFI_CAPSULE_ON_DISK
> +   help
> + This command allows users to create a UEFI capsule file and,
> + optionally sign that file. If you want to enable UEFI capsule
> + update feature on your target, you certainly need this.
>  endmenu
> diff --git a/tools/Makefile b/tools/Makefile
> index 4a86321f6467..6ea3033dbfb8 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -237,8 +237,12 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
>  hostprogs-$(CONFIG_ASN1_COMPILER)  += asn1_compiler
>  HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
>
> -mkeficapsule-objs  := mkeficapsule.o $(LIBFDT_OBJS)
> -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
> +HOSTLDLIBS_mkeficapsule += -luuid
> +ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y)
> +HOSTLDLIBS_mkeficapsule += \
> +   $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo 
> "-lssl -lcrypto")
> +endif
> +hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
>
>  # We build some files with extra pedantic flags to try to minimize things
>  # that won't build on some weird host compiler -- though there are lots of
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index 4995ba4e0c2a..5541e4bda894 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -15,6 +15,16 @@
>  #include 
>  #include 
>
> +#include 
> +#ifdef CONFIG_TOOLS_LIBCRYPTO
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#endif
> +
>  typedef __u8 u8;
>  typedef __u16 u16;
>  typedef __u32 u32;
> @@ -38,12 +48,25 @@ efi_guid_t efi_guid_image_type_uboot_fit =
> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
>  efi_guid_t efi_guid_image_type_uboot_raw =
> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> +efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> +
> +#ifdef CONFIG_TOOLS_LIBCRYPTO
> +static const char *opts_short = "f:r:i:I:v:p:c:m:dh";
> +#else
> +static const char *opts_short = "f:r:i:I:v:h";
> +#endif
>
>  static struct option options[] = {
> {"fit", required_argument, NULL, 'f'},
> {"raw", required_argument, NULL, 'r'},
> {"index", required_argument, NULL, 'i'},
> {"instance", required_argument, NULL, 'I'},
> +#ifdef CONFIG_TOOLS_LIBCRYPTO
> +   {"private-key", required_argument, NULL, 'p'},
> +   {"certificate", required_argument, NULL, 'c'},
> +   {"monotonic-count", required_argument, NULL, 'm'},
> +   {"dump-sig", no_argument, NULL, 'd'},
> +#endif
> {"help", no_argument, NULL, 'h'},
> {NULL, 0, NULL, 0},
>  };
> @@ -57,16 +80,280 @@ static void print_usage(void)
>"\t-r, --rawnew raw image file\n"
>"\t-i, --index  update image index\n"
>"\t-I, --instanceupdate hardware instance\n"
> +#ifdef CONFIG_TOOLS_LIBCRYPTO
> +  "\t-p, --private-key   private key file\n"
> +  "\t-c, --certificate  signer's certificate 
> file\n"
> +  "\t-m, --monotonic-count  monotonic count\n"
> +  "\t-d, --dump_sig  dump signature (*.p7)\n"
> +#endif
>"\t-h, --help  print a help message\n",
>tool_name);
>  }
>
> +/**
> + * auth_context - authentication context
> + * @key_file:  Path to a private key file
> + * @cert_file: Path to a certificate file
> + * @image

Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()

[Masami Hiramatsu]

Hi Simon,

2021年10月15日(金) 9:40 Simon Glass :
>
> Hi Takahiro,
>
> On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro  
> wrote:
> >
> > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
> > .rodata"") failed to revert the removal of efi_get_public_key_data().
> >
> > Add back this function and move it under lib/efi_loader so that other
> > platforms can utilize it. It is now declared as a weak function so that
> > it can be replaced with a platform-specific implementation.
> >
> > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
> > .rodata"")
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  lib/efi_loader/efi_capsule.c | 36 
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index b75e4bcba1a9..44f5da61a9be 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -11,15 +11,20 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> >  #include 
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> >  const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
> >  static const efi_guid_t efi_guid_firmware_management_capsule_id =
> > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > @@ -251,6 +256,37 @@ out:
> >  }
> >
> >  #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
>
> I don't think this should be weak. What other way is there of handling
> this and why would it be platform-specific?

I have a question about the current design of the capsule auth key.
If the platform has its own key-storage, how can the platform use the
platform specific storage? Does such platform load the key from the storage
and generate the dtb node in the platform initialization code? (or
device driver?)

Thank you,


>
> > +{
> > +   const void *fdt_blob = gd->fdt_blob;
> > +   const void *blob;
> > +   const char *cnode_name = "capsule-key";
> > +   const char *snode_name = "signature";
> > +   int sig_node;
> > +   int len;
> > +
> > +   sig_node = fdt_subnode_offset(fdt_blob, 0, snode_name);
> > +   if (sig_node < 0) {
> > +   log_err("Unable to get signature node offset\n");
> > +
> > +   return -FDT_ERR_NOTFOUND;
> > +   }
> > +
> > +   blob = fdt_getprop(fdt_blob, sig_node, cnode_name, &len);
> > +
> > +   if (!blob || len < 0) {
> > +   log_err("Unable to get capsule-key value\n");
> > +   *pkey = NULL;
> > +   *pkey_len = 0;
> > +
> > +   return -FDT_ERR_NOTFOUND;
> > +   }
> > +
> > +   *pkey = (void *)blob;
> > +   *pkey_len = len;
> > +
> > +   return 0;
> > +}
> >
> >  efi_status_t efi_capsule_authenticate(const void *capsule, efi_uintn_t 
> > capsule_size,
> >   void **image, efi_uintn_t *image_size)
> > --
> > 2.33.0
> >
>
> Regards,
> Simon



--
Masami Hiramatsu

Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()

[François Ozog]

Le mer. 20 oct. 2021 à 10:18, Masami Hiramatsu 
a écrit :

> Hi Simon,
>
> 2021年10月15日(金) 9:40 Simon Glass :
> >
> > Hi Takahiro,
> >
> > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro 
> wrote:
> > >
> > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB
> to
> > > .rodata"") failed to revert the removal of efi_get_public_key_data().
> > >
> > > Add back this function and move it under lib/efi_loader so that other
> > > platforms can utilize it. It is now declared as a weak function so that
> > > it can be replaced with a platform-specific implementation.
> > >
> > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
> > > .rodata"")
> > > Signed-off-by: AKASHI Takahiro 
> > > ---
> > >  lib/efi_loader/efi_capsule.c | 36 
> > >  1 file changed, 36 insertions(+)
> > >
> > > diff --git a/lib/efi_loader/efi_capsule.c
> b/lib/efi_loader/efi_capsule.c
> > > index b75e4bcba1a9..44f5da61a9be 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -11,15 +11,20 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include 
> > >  #include 
> > >  #include 
> > >
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > >  const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
> > >  static const efi_guid_t efi_guid_firmware_management_capsule_id =
> > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > > @@ -251,6 +256,37 @@ out:
> > >  }
> > >
> > >  #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
> >
> > I don't think this should be weak. What other way is there of handling
> > this and why would it be platform-specific?
>
> I have a question about the current design of the capsule auth key.
> If the platform has its own key-storage, how can the platform use the
> platform specific storage? Does such platform load the key from the storage
> and generate the dtb node in the platform initialization code? (or
> device driver?)

it depends on what the capsule contains.

If the capsule contains SCP firmware or secure firmware or TAs, U-Boot may
not be even allowed to see the key.
If the capsule contains U-Boot itself it may be again outside scope of
U-Boot because that may be secure firmware that verifies the signature. We
may allow U-Boot to update itself but the final say is the secure firmware
that may prevent the boot.
If the capsule contains device firmware then it may depend on the device:
secure device U-Boot can do anything, otherwise then it is to be decided by
U-Boot.


>
> Thank you,
>
>
> >
> > > +{
> > > +   const void *fdt_blob = gd->fdt_blob;
> > > +   const void *blob;
> > > +   const char *cnode_name = "capsule-key";
> > > +   const char *snode_name = "signature";
> > > +   int sig_node;
> > > +   int len;
> > > +
> > > +   sig_node = fdt_subnode_offset(fdt_blob, 0, snode_name);
> > > +   if (sig_node < 0) {
> > > +   log_err("Unable to get signature node offset\n");
> > > +
> > > +   return -FDT_ERR_NOTFOUND;
> > > +   }
> > > +
> > > +   blob = fdt_getprop(fdt_blob, sig_node, cnode_name, &len);
> > > +
> > > +   if (!blob || len < 0) {
> > > +   log_err("Unable to get capsule-key value\n");
> > > +   *pkey = NULL;
> > > +   *pkey_len = 0;
> > > +
> > > +   return -FDT_ERR_NOTFOUND;
> > > +   }
> > > +
> > > +   *pkey = (void *)blob;
> > > +   *pkey_len = len;
> > > +
> > > +   return 0;
> > > +}
> > >
> > >  efi_status_t efi_capsule_authenticate(const void *capsule,
> efi_uintn_t capsule_size,
> > >   void **image, efi_uintn_t
> *image_size)
> > > --
> > > 2.33.0
> > >
> >
> > Regards,
> > Simon
>
>
>
> --
> Masami Hiramatsu
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

[PATCH] imx: nandbcb: Fix printf format in write_fcb

[Pali Rohár]

Correct printf format for unsigned long long is %llx and not %llxx.

Signed-off-by: Pali Rohár 
---
 arch/arm/mach-imx/cmd_nandbcb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index 09622c13c980..646da0198660 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -650,7 +650,7 @@ static int write_fcb(struct boot_config *boot_cfg, struct 
fcb_block *fcb)
};
 
ret = mtd_write_oob(mtd, off, &ops);
-   printf("NAND FCB write to 0x%llxx offset 0x%zx written: 
%s\n", off, ops.len, ret ? "ERROR" : "OK");
+   printf("NAND FCB write to 0x%llx offset 0x%zx written: 
%s\n", off, ops.len, ret ? "ERROR" : "OK");
}
 
if (ret)
-- 
2.20.1

Re: [PATCH] mtd: spi-nor-ids: Add SECT_4K to mt25qu512a

[Kris Chaplin]

Thank you Pratyush,

I'm not a regular submitter so appreciate the feedback.  Looking at 
denx.de/wiki/U-Boot/Patches I saw:

Tested-by:
   A Tested-by: tag indicates that the patch has been successfully
   tested (in some environment) by the person named. Andrew Morton: "I
   think it's very useful information to have. For a start, it tells
   you who has the hardware and knows how to build a kernel. So if
   you're making a change to a driver and want it tested, you can troll
   the file's changelog looking for people who might be able to help."

Totally appreciate that this is inferred by the change - thanks also for the 
maintainer advice.

Regards
Kris

On 19/10/2021 19:38, Pratyush Yadav wrote:


On 18/10/21 03:30AM, Kris Chaplin wrote:

The mt25qu512a supports 4K or 64K sectors, so adding SECT_4K to enable 4K 
sector usage.

Datasheet: 
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_512mb_1ce_3v_65nm.pdf

Tested on Intel n5x hardware with QSPI carrier card

Signed-off-by: Kris Chaplin 
Tested by: Kris Chaplin 

This is unusual. The patch should *always* be tested by the author so
you don't really need a Tested-by from the author. It is implied.

You should also Cc the subsystem maintainers so that they can see the
patch and review and apply it. You can use `./scripts/get_maintainer.pl
` to get the list of people who need to be in Cc.
Adding Jagan and Vignesh for this patch.

Anyway, with the Tested-by trailer dropped,

Acked-by: Pratyush Yadav 


---
  drivers/mtd/spi/spi-nor-ids.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index f0c8041997..5359d09489 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -190,7 +190,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO6("mt25qu256a",  0x20bb19, 0x104400, 64 * 1024,  512, SECT_4K | 
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | USE_FSR) },
{ INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | 
SPI_NOR_QUAD_READ | USE_FSR) },
{ INFO6("mt25qu512a",  0x20bb20, 0x104400, 64 * 1024, 1024,
-SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
+SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | 
SPI_NOR_4B_OPCODES |
 USE_FSR) },
{ INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ) },
{ INFO6("mt25ql512a",  0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | 
USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
--
2.25.1

Re: [PATCH] arm: a37xx: pci: Do not allow setting bars on PCI Bridge

[Stefan Roese]

On 12.10.21 13:19, Pali Rohár wrote:

PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.

So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.

After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.

Signed-off-by: Pali Rohár 
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root 
bus")


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/pci/pci-aardvark.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 38eff495ab1c..ade5ab056f84 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -581,6 +581,10 @@ static int pcie_advk_write_config(struct udevice *bus, 
pci_dev_t bdf,
if (offset >= 0x10 && offset < 0x34) {
data = pcie->cfgcache[(offset - 0x10) / 4];
data = pci_conv_size_to_32(data, value, offset, size);
+   /* This PCI bridge does not have configurable bars */
+   if ((offset & ~3) == PCI_BASE_ADDRESS_0 ||
+   (offset & ~3) == PCI_BASE_ADDRESS_1)
+   data = 0x0;
pcie->cfgcache[(offset - 0x10) / 4] = data;
} else if ((offset & ~3) == PCI_ROM_ADDRESS1) {
data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG);




Viele Grüße,
Stefan

--
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] arm: mvebu: Add missing "if SPL"

[Stefan Roese]

On 15.10.21 16:54, Tom Rini wrote:

We can only select SPL_SKIP_LOWLEVEL_INIT if SPL is enabled, otherwise
we get a warning about unmet dependencies on platforms that don't use
SPL.

Fixes: cf47a8cf8f7e ("arm: mvebu: Select SPL_SKIP_LOWLEVEL_INIT on 
ARMADA_32BIT")
Cc: Stefan Roese 
Signed-off-by: Tom Rini 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 54dff9986b41..c9dbef2e6392 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -11,7 +11,7 @@ config ARMADA_32BIT
select SPL_DM if SPL
select SPL_DM_SEQ_ALIAS if SPL
select SPL_OF_CONTROL if SPL
-   select SPL_SKIP_LOWLEVEL_INIT
+   select SPL_SKIP_LOWLEVEL_INIT if SPL
select SPL_SIMPLE_BUS if SPL
select SUPPORT_SPL
select TRANSLATION_OFFSET




Viele Grüße,
Stefan

--
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] doc: Remove obsolete README.440-DDR-performance file

[Stefan Roese]

On 19.10.21 09:25, Thomas Huth wrote:

The PPC 440 support has been removed in commit 98f705c9ce
("powerpc: remove 4xx support") already, so this file is
certainly not required anymore.

Signed-off-by: Thomas Huth 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  doc/README.440-DDR-performance | 90 --
  1 file changed, 90 deletions(-)
  delete mode 100644 doc/README.440-DDR-performance

diff --git a/doc/README.440-DDR-performance b/doc/README.440-DDR-performance
deleted file mode 100644
index 66b97bc9b5..00
--- a/doc/README.440-DDR-performance
+++ /dev/null
@@ -1,90 +0,0 @@
-AMCC suggested to set the PMU bit to 0 for best performace on the
-PPC440 DDR controller. The 440er common DDR setup files (sdram.c &
-spd_sdram.c) are changed accordingly. So all 440er boards using
-these setup routines will automatically receive this performance
-increase.
-
-Please see below some benchmarks done by AMCC to demonstrate this
-performance changes:
-
-
-
-SDRAM0_CFG0[PMU] = 1 (U-Boot default for Bamboo, Yosemite and Yellowstone)
-
-Stream benchmark results
--
-This system uses 8 bytes per DOUBLE PRECISION word.
--
-Array size = 200, Offset = 0
-Total memory required = 45.8 MB.
-Each test is run 10 times, but only
-the *best* time for each is used.
--
-Your clock granularity/precision appears to be 1 microseconds.
-Each test below will take on the order of 112345 microseconds.
-   (= 112345 clock ticks)
-Increase the size of the arrays if this shows that you are not getting
-at least 20 clock ticks per test.
--
-WARNING -- The above is only a rough guideline.
-For best results, please be sure you know the precision of your system
-timer.
--
-Function  Rate (MB/s)   RMS time Min time Max time
-Copy: 256.7683   0.1248   0.1246   0.1250
-Scale:246.0157   0.1302   0.1301   0.1302
-Add:  255.0316   0.1883   0.1882   0.1885
-Triad:253.1245   0.1897   0.1896   0.1899
-
-
-TTCP Benchmark Results
-ttcp-t: socket
-ttcp-t: connect
-ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000  tcp  ->
-localhost
-ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++
-ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57
-ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw
-
-
-SDRAM0_CFG0[PMU] = 0 (Suggested modification)
-Setting PMU = 0 provides a noticeable performance improvement *2% to
-5% improvement in memory performance.
-*Improves the Mbit/sec for TTCP benchmark by almost 76%.
-
-Stream benchmark results
--
-This system uses 8 bytes per DOUBLE PRECISION word.
--
-Array size = 200, Offset = 0
-Total memory required = 45.8 MB.
-Each test is run 10 times, but only
-the *best* time for each is used.
--
-Your clock granularity/precision appears to be 1 microseconds.
-Each test below will take on the order of 120066 microseconds.
-   (= 120066 clock ticks)
-Increase the size of the arrays if this shows that you are not getting
-at least 20 clock ticks per test.
--
-WARNING -- The above is only a rough guideline.
-For best results, please be sure you know the precision of your system
-timer.
--
-Function  Rate (MB/s)   RMS time Min time Max time
-Copy: 262.5167   0.1221   0.1219   0.1223
-Scale:258.4856   0.1238   0.1238   0.1240
-Add:  262.5404   0.1829   0.1828   0.1831
-Triad:266.8594   0.1800   0.1799   0.1802
-
-TTCP Benchmark Results
-ttcp-t: socket
-ttcp-t: connect
-ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000  tcp  ->
-localhost
-ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++
-ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89
-ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw
-
-
-2006-07-28, Stefan Roese 




Viele Grüße,
Stefan

--
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] arm: a37xx: pci: Fix condition for CRS response

[Stefan Roese]

On 19.10.21 11:05, Pali Rohár wrote:

As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.

Fixes: 1d7ad68559e2 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe 
Root Port")
Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/pci/pci-aardvark.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index ade5ab056f84..9e623b6e617b 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -445,7 +445,7 @@ static int pcie_advk_read_config(const struct udevice *bus, 
pci_dev_t bdf,
 * for returning CRS, so that if U-Boot does support CRS in the future,
 * it will work for Aardvark.
 */
-   allow_crs = pcie->cfgcrssve;
+   allow_crs = (offset == PCI_VENDOR_ID) && (size == PCI_SIZE_32) && 
pcie->cfgcrssve;
  
  	if (advk_readl(pcie, PIO_START)) {

dev_err(pcie->dev,




Viele Grüße,
Stefan

--
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: buildman stops (crashed) on current master

[Stefano Babic]

On 20.10.21 05:42, Simon Glass wrote:

Hi,

On Tue, 19 Oct 2021 at 17:01, Tom Rini  wrote:


On Tue, Oct 19, 2021 at 04:59:15PM -0600, Simon Glass wrote:

Hi Tom,

On Tue, 19 Oct 2021 at 16:53, Tom Rini  wrote:


On Tue, Oct 19, 2021 at 05:39:12PM +0200, Stefano Babic wrote:

Hi Simon,

On 07.10.21 15:43, Simon Glass wrote:

Hi Stefano,

On Thu, 7 Oct 2021 at 04:37, Stefano Babic  wrote:


Hi all,

CI stops by building aarch64 without notice, for reference:

https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/332319

There is no error, just process is killed. It looks like it stops at
xilinx_zynqmp_virt,

./tools/buildman/buildman -o /tmp -P -E -W aarch64but board can be built
without issues.

If I build on my host (not in docker, anyway), it generally builds fine
- but it crashes sometimes, too. On gitlab instance , it crashes.
Issue does not seem that depends on merged patches, and introduces
boards were already built successfully. Any hint ? I have also no idea
what I should look as what I see is just

"usr/bin/bash: line 104:24 Killed
./tools/buildman/buildman -o /tmp -P -E -W aarch64"


I cannot see that link. I am not sure what is going on. Does it say
what signal killed it?


Pipelines on our server were not public - I have enbaled now for u-boot-imx.



Does it sit there for an hour and timeout? If so, then I  did see that
myself once recently, when the Kconfig needed stdin, but I could not
quitetie it down. I think buildman would provide it, but sometimes
not, apparently. So it can happen when there is an existing build
there and your new one which adds Kconfig options that don't have
defaults, or something like that?



I have investigated further, and I can reproduce it on my host outside the
gitlab server. buildman causes a OOM, but I cannot find the cause.

Strange enough, this happens with the "aarch64" target, and I cannot
reproduce it with Tom's master. So it seems that -master is ok, and somethin
on u-boot-imx generates the OOM.

However

The OOM happens always when -2 (two boards remain) appears. I can see with
htop that buildman starts to allocate memory until it is exhausted (64GB RAM
+ 8 GB swap). Then the kernel decides that it is enough and kills buildman -
this is what I see on Ci.

You can see now the pipelines:

https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/9520

I have then split aarch64 and I built imx8 separately - same result. The
pipeline stops with xilinx board, but they have nothing to do. In fact, I
can build all xilinx board separately. If I run buildman -W aarch64 -x
xilinx, OOM is shown by another board.

Strange enough, I can build each single board with buildman without issues,
neither errors nor warnongs. Just when buildman runs all together (aarch64,
308 boards), the OOM is generated.

Bisect does not help: I started bisect, and at the end this commit was
presented:

commit 53a24dee86fb72ae41e7579607bafe13442616f2
Author: Fabio Estevam 
Date:   Mon Aug 23 21:11:09 2021 -0300

 imx8mm-cl-iot-gate: Split the defconfigs


I strongly suspect what's going on here is that these new defconfigs are
out of sync with changes now in Kconfig.  The build itself will just sit
there, waiting for the "oldconfig" prompt to be answered.

I want to say the problem here is that stdin is open, rather than
pointing to something closed and would lead to the build failing
immediately, rather than once a timeout is hit, or OOM kicks in due to
kconfig chewing up all the memory.


Yes that's exactly what I saw...

In fact, see this commit:

e62a24ce27a buildman: Avoid hanging when the config changes

But that was 3 years ago.


Looks like something else needs to be changed then, I've bisected down
similar failures here before very recently.


I dug into this a bit and I think buildman can detect this situation.
I'll send a little series.



Patch definetly help ;-)

It breaks build (on CI when build-tools runs), but I get much more 
details when I build locally single boards. I can find for 
kontron-sl-mx8mm several errors due to:


- CONFIG_SYS_LOAD_ADDR not defined in configs, but in header
- CONFIG_SYS_EXTRA_OPTIONS instead of CONFIG_IMX_CONFIG
- CONFIG_SYS_MALLOC_LEN not defined in config, but in header

Your patch are a valueable tool (CI driove me crazy), I can now folow 
what happens. I send a patch for kontron, and I go on with the rest (I 
guess kontron is not the only board causing this deadlock). Many thanks !


Tom, I apply Simon's patches on my tree, I cannot work without them...

Regards,
Stefano

--
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH] kontron-sl-mx8mm: fix missing configs and deadlock in CI

[Stefano Babic]

Even if board can be successfuly built, CI goes in deadlock (see thread
on https://www.mail-archive.com/u-boot@lists.denx.de/msg419663.html).
This is caused by SYS_CONFIG set in header file and because defconfig
for the board is out of sync with Kconfig. As result, buildman goes on
to read from stdin until an OOM is reached.

Signed-off-by: Stefano Babic 
CC: Frieder Schrempf 
---
 configs/kontron-sl-mx8mm_defconfig | 4 +++-
 include/configs/kontron-sl-mx8mm.h | 3 ---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/configs/kontron-sl-mx8mm_defconfig 
b/configs/kontron-sl-mx8mm_defconfig
index 06c57b7555..02897818d9 100644
--- a/configs/kontron-sl-mx8mm_defconfig
+++ b/configs/kontron-sl-mx8mm_defconfig
@@ -8,6 +8,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x1
 CONFIG_ENV_SIZE=0x1
 CONFIG_ENV_OFFSET=0x1f
 CONFIG_ENV_SECT_SIZE=0x1
+CONFIG_SYS_MALLOC_LEN=0x400
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="imx8mm-kontron-n801x-s"
@@ -17,6 +18,7 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_BOOTCOUNT_BOOTLIMIT=3
 CONFIG_SPL=y
+CONFIG_SYS_LOAD_ADDR=0x4048
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DISTRO_DEFAULTS=y
@@ -25,7 +27,7 @@ CONFIG_FIT_EXTERNAL_OFFSET=0x3000
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/kontron/sl-mx8mm/imximage.cfg"
+CONFIG_IMX_CONFIG="board/kontron/sl-mx8mm/imximage.cfg"
 CONFIG_BOARD_TYPES=y
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SEPARATE_BSS=y
diff --git a/include/configs/kontron-sl-mx8mm.h 
b/include/configs/kontron-sl-mx8mm.h
index 4909b3679d..0d9ab3b755 100644
--- a/include/configs/kontron-sl-mx8mm.h
+++ b/include/configs/kontron-sl-mx8mm.h
@@ -22,7 +22,6 @@
 #define CONFIG_SYS_INIT_RAM_ADDR   0x4000
 #define CONFIG_SYS_INIT_RAM_SIZE   0x20
 
-#define CONFIG_SYS_MALLOC_LEN  SZ_64M
 #define CONFIG_SYS_HZ  1000
 
 #define CONFIG_SYS_INIT_SP_OFFSET \
@@ -55,8 +54,6 @@
 #define BOOTENV
 #endif
 
-#define CONFIG_LOADADDR0x4048
-#define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
 #define CONFIG_SYS_BOOTM_LEN   SZ_64M
 #define CONFIG_SPL_MAX_SIZE(148 * SZ_1K)
 #define CONFIG_FSL_USDHC
-- 
2.25.1

[PATCH] imx8mm-cl-iot-gate-optee: align config with Kconfig

[Stefano Babic]

Due to missing configs, CI goes in deadlock until an OOM is tracked. Add
CONFIG_SYS_LOAD_ADDR and replace CONFIG_SYS_EXTRA_OPTIONS with
CONFIG_IMX_CONFIG.

Signed-off-by: Stefano Babic 
CC: Ying-Chun Liu (PaulLiu)" 
CC: Fabio Estevam 
---
 configs/imx8mm-cl-iot-gate-optee_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/imx8mm-cl-iot-gate-optee_defconfig 
b/configs/imx8mm-cl-iot-gate-optee_defconfig
index d918779960..d987328922 100644
--- a/configs/imx8mm-cl-iot-gate-optee_defconfig
+++ b/configs/imx8mm-cl-iot-gate-optee_defconfig
@@ -21,13 +21,14 @@ CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_SPL=y
 CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SYS_LOAD_ADDR=0x4048
 CONFIG_FIT=y
 CONFIG_FIT_EXTERNAL_OFFSET=0x3000
 CONFIG_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg"
+CONFIG_IMX_CONFIG="board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg"
 CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SEPARATE_BSS=y
-- 
2.25.1

Re: [PATCH] mtd: spi-nor-ids: Add SECT_4K to mt25qu512a

[Pratyush Yadav]

On 20/10/21 10:43AM, Kris Chaplin wrote:
> Thank you Pratyush,
> 
> I'm not a regular submitter so appreciate the feedback.  Looking at 
> denx.de/wiki/U-Boot/Patches I saw:
> 
> Tested-by:
>A Tested-by: tag indicates that the patch has been successfully
>tested (in some environment) by the person named. Andrew Morton: "I
>think it's very useful information to have. For a start, it tells
>you who has the hardware and knows how to build a kernel. So if
>you're making a change to a driver and want it tested, you can troll
>the file's changelog looking for people who might be able to help."
> 
> Totally appreciate that this is inferred by the change - thanks also for the 
> maintainer advice.

You're welcome :-). One more tip: avoid top posting [0].

[0] https://www.idallen.com/topposting.html

> 
> Regards
> Kris
> 
> On 19/10/2021 19:38, Pratyush Yadav wrote:
> 
> > On 18/10/21 03:30AM, Kris Chaplin wrote:
> > > The mt25qu512a supports 4K or 64K sectors, so adding SECT_4K to enable 4K 
> > > sector usage.
> > > 
> > > Datasheet: 
> > > https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_512mb_1ce_3v_65nm.pdf
> > > 
> > > Tested on Intel n5x hardware with QSPI carrier card
> > > 
> > > Signed-off-by: Kris Chaplin 
> > > Tested by: Kris Chaplin 
> > This is unusual. The patch should *always* be tested by the author so
> > you don't really need a Tested-by from the author. It is implied.
> > 
> > You should also Cc the subsystem maintainers so that they can see the
> > patch and review and apply it. You can use `./scripts/get_maintainer.pl
> > ` to get the list of people who need to be in Cc.
> > Adding Jagan and Vignesh for this patch.
> > 
> > Anyway, with the Tested-by trailer dropped,
> > 
> > Acked-by: Pratyush Yadav 
> > 
> > > ---
> > >   drivers/mtd/spi/spi-nor-ids.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > > index f0c8041997..5359d09489 100644
> > > --- a/drivers/mtd/spi/spi-nor-ids.c
> > > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > > @@ -190,7 +190,7 @@ const struct flash_info spi_nor_ids[] = {
> > >   { INFO6("mt25qu256a",  0x20bb19, 0x104400, 64 * 1024,  512, 
> > > SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | USE_FSR) },
> > >   { INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | 
> > > SPI_NOR_QUAD_READ | USE_FSR) },
> > >   { INFO6("mt25qu512a",  0x20bb20, 0x104400, 64 * 1024, 1024,
> > > -  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
> > > +  SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | 
> > > SPI_NOR_4B_OPCODES |
> > >USE_FSR) },
> > >   { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | 
> > > USE_FSR | SPI_NOR_QUAD_READ) },
> > >   { INFO6("mt25ql512a",  0x20ba20, 0x104400, 64 * 1024, 1024, 
> > > SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> > > -- 
> > > 2.25.1
> > > 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

[PATCH v3 0/1] arm: spl: prepare for jumping to OPTEE

[Oleksandr Suvorov]

This series introduces a weak and ARM-specific function to jump into
OP-TEE from SPL. The ARM-specific function fixes a system halting
when jumping to OP-TEE on some SoCs (the issue was found and fixed
for iMX6Q).

Changes in v3:
- squashed the fix commit :)

Changes in v2:
- fix: building on evb-rk3229 and evb-rk3288;
- fix: warning about return from noreturn-function.

Ricardo Salveti (1):
  arm: spl: prepare for jumping to OPTEE

 arch/arm/lib/spl.c | 11 +++
 common/spl/spl.c   | 11 +--
 include/spl.h  | 11 ++-
 3 files changed, 30 insertions(+), 3 deletions(-)

-- 
2.31.1

[PATCH v3 1/1] arm: spl: prepare for jumping to OPTEE

[Oleksandr Suvorov]

From: Ricardo Salveti 

Make sure to (if applicable) flush the D-cache, invalidate I-cache,
and disable MMU and caches before jumping to OPTEE.
This fixes the SDP->SPL->OPTEE boot flow on iMX6Q and most likely on
some other ARM SoCs.

Signed-off-by: Ricardo Salveti 
Co-developed-by: Oleksandr Suvorov 
Signed-off-by: Oleksandr Suvorov 
---

Changes in v3:
- squashed the fix commit :)

Changes in v2:
- fix: building on evb-rk3229 and evb-rk3288;
- fix: warning about return from noreturn-function.

 arch/arm/lib/spl.c | 11 +++
 common/spl/spl.c   | 11 +--
 include/spl.h  | 11 ++-
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index 8e2bdf3536..4f9b84ba34 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -77,3 +77,14 @@ void __noreturn jump_to_image_linux(struct spl_image_info 
*spl_image)
 }
 #endif /* CONFIG_ARM64 */
 #endif
+
+#if CONFIG_IS_ENABLED(OPTEE_IMAGE)
+void __noreturn jump_to_image_optee(struct spl_image_info *spl_image)
+{
+   /* flush and turn off caches before jumping to OPTEE */
+   cleanup_before_linux();
+
+   spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
+   (void *)spl_image->entry_point);
+}
+#endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index a9304d4148..0c08da06e8 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -174,6 +174,14 @@ __weak void spl_board_prepare_for_optee(void *fdt)
 {
 }
 
+#if CONFIG_IS_ENABLED(OPTEE_IMAGE)
+__weak void __noreturn jump_to_image_optee(struct spl_image_info *spl_image)
+{
+   spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
+   (void *)spl_image->entry_point);
+}
+#endif
+
 __weak void spl_board_prepare_for_boot(void)
 {
/* Nothing to do! */
@@ -780,8 +788,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
case IH_OS_TEE:
debug("Jumping to U-Boot via OP-TEE\n");
spl_board_prepare_for_optee(spl_image.fdt_addr);
-   spl_optee_entry(NULL, NULL, spl_image.fdt_addr,
-   (void *)spl_image.entry_point);
+   jump_to_image_optee(&spl_image);
break;
 #endif
 #if CONFIG_IS_ENABLED(OPENSBI)
diff --git a/include/spl.h b/include/spl.h
index afbf39bef4..f7d1ef5c88 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -460,6 +460,15 @@ int spl_board_boot_device(u32 boot_device);
  */
 void __noreturn jump_to_image_linux(struct spl_image_info *spl_image);
 
+/**
+ * jump_to_image_linux() - Jump to OP-TEE OS from SPL
+ *
+ * This jumps into OP-TEE OS using the information in @spl_image.
+ *
+ * @spl_image: Image description to set up
+ */
+void __noreturn jump_to_image_optee(struct spl_image_info *spl_image);
+
 /**
  * spl_start_uboot() - Check if SPL should start the kernel or U-Boot
  *
@@ -751,7 +760,7 @@ struct bl_params 
*bl2_plat_get_bl31_params_v2_default(uintptr_t bl32_entry,
  * @arg2: device tree address, (ARMv7 standard bootarg #2)
  * @arg3: non-secure entry address (ARMv7 bootarg #0)
  */
-void spl_optee_entry(void *arg0, void *arg1, void *arg2, void *arg3);
+void __noreturn spl_optee_entry(void *arg0, void *arg1, void *arg2, void 
*arg3);
 
 /**
  * spl_invoke_opensbi - boot using a RISC-V OpenSBI image
-- 
2.31.1

Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification

[Alec Brown]

On Sun, Sep 19, 2021 at 12:53:35AM +0200, Heinrich Schuchardt wrote:
> 
> 
> Am 18. September 2021 18:04:13 MESZ schrieb Alec Brown 
> :
> >Hi everyone,
> >
> >I've been working on improving the specification for the firmware and 
> >bootloader
> >log that Daniel Kiper has proposed and take into account most of the 
> >suggestions
> >that were made in these threads [1], [2].
> >
> >The goal is to allow various boot components to pass logs to the running OS 
> >and
> >then to the user space for processing and analysis. These logs should be 
> >generic
> >enough so that it can work in multiple environments and be human readable.
> 
> Hello Alec,
> 
> in your mail it remains unclear which information you want to put into the 
> log and why it is needed. I would prefer the motivation and content to be 
> clarified before defining any interface structures.
> 
> We already the EFI_TCG2_PROTOCOL and RFC 5424 (The syslog protocol). Why do 
> we need to start from scratch?
> 
> Best regards
> 
> Heinrich 

Hi Heinrich,

The motivation behind developing these logs was to allow TrenchBoot to be able
to view how the platform was setup during boot. We intend for our specification
to target the Bootloader and Firmware and collect logs from them, but not TPM
event logs, which is what the EFI_TCG2_PROTOCOL collects. We plan on using our
specification for the GRUB Bootloader since it will be more efficient and
flexible to use than the syslog protocol. However, if other boot components
want to use a different logging format, our bf_log_header allows them to do so.

Alec Brown

> 
> >
> >It has yet to be decided where to put the final version of this 
> >specification.
> >It should be merged into an existing specification, e.g. UEFI, ACPI, 
> >Multiboot2,
> >or be standalone, such as a part of OASIS Standards.
> >
> >Below is how the layout of these logs would store their data.
> >
> >bf_log_header:
> >   +---+
> >u32| version   |
> >u32| size  |
> >u8[64] | producer  |
> >u8[64] | log_format|
> >u64| flags |
> >u64| next_bflh_addr|
> >u64| log_addr  |
> >u32| log_size  |
> >   +---+
> >
> >bf_log_buffer:
> >   +---+
> >u32| version   |
> >u32| size  |
> >u8[64] | producer  |
> >u32| next_msg_off  |
> >bf_log_msg[l]  | msgs  |
> >   +---+
> >
> >bf_log_msg:
> >   +---+
> >u32| size  |
> >u64| ts_nsec   |
> >u32| level |
> >u32| facility  |
> >u32| msg_off   |
> >u8[n]  | type  |
> >u8[m]  | msg   |
> >   +---+
> >
> >Where l is the number of msgs, n is the size of type, and m is the size of 
> >the
> >msg.
> >
> >The bf_log_header structure forms a linked list. Each bf_log_header element 
> >in
> >the linked list points to the individual log buffer and the next 
> >bf_log_header
> >element in the linked list. The first element in the linked list points to 
> >the
> >last boot component in the boot chain. The last element points to the 
> >starting
> >boot component in the boot chain. The log buffers which contain the log
> >messages are produced by the various boot components, typically from the
> >firmware to the bootloader. The log message is stored in a log format that is
> >compatible with the boot component that produced it.
> >
> >The fields in bf_log_header structure:
> >  - version: the firmware and bootloader log header version number, 1 for 
> > now,
> >  - size: the size of the bf_log_header to allow for backward compatibility 
> > if 
> >other fields are added,
> >  - producer: the producer/firmware/bootloader/... entity, NUL terminated
> >string, e.g. GRUB, Coreboot; the length allows for ASCII UUID storage,
> >  - log_format: the format used to record the log messages, NUL terminated
> >string, e.g. bf_log_msg, cbmem_cons, etc.; various producers may generate
> >logs in various formats if needed,
> >  - flags: bit field used to store information about the log state, if bit 0 
> > has
> >been set it means the log was truncated,
> >  - next_bflh_addr: the physical address of the next bf_log_header structure,
> >none if zero,
> >  - log_addr: the physical address of where the log buffer is stored,
> >  - log_size: the total size of the log buffer.
> >
> >The bf_log_buffer is used to store log messages from the firmware and
> >bootloader. This format for storing messages is called the bf log format. The
> >bf_log_buffer contains the header information of the bf log format with the 
> >log
> >messages being stored in an array of bf_log_msg m

Re: [External] : Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification

[Alec Brown]

On Tue, Sep 21, 2021 at 03:40:20PM +, Peter Stuge wrote:
> Alec Brown wrote:
> > Below is how the layout of these logs would store their data.
> > 
> > bf_log_header:
> >+---+
> > u32| version   |
> > u32| size  |
> > u8[64] | producer  |
> > u8[64] | log_format|
> > u64| flags |
> > u64| next_bflh_addr|
> > u64| log_addr  |
> > u32| log_size  |
> >+---+
> 
> I suggest to include a .magic at least in bf_log_header and an
> .xor_checksum or .crc32 only in bf_log_header.
> 
> .magic doubles as endianess indicator when the structures are
> stored on movable media. (Pick an asymmetric magic bit pattern!)

This is something we will need to think about.

>  
> I suggest renaming .next_bflh_addr to .next_log_header and .log_addr
> to .log_buffer_addr.
> 
> I suggest to remove .size and .log_size:
> 
> The rationale for .size is "to allow for backward compatibility" but
> that seems redundant thanks to .version.
> 
> .log_size can be calculated from the subordinate data and is thus
> mostly an unneccessary source of potential inconsistency.

Looking back, I agree with removing .size since .version accomplishes the same
task. I'm not so sure on removing .log_size as it can be very convenient, and
.log_size won't need to be calculated every time someone wants to know the size
of the logs generated from the boot component.

> 
> 
> > bf_log_buffer:
> >+---+
> > u32| version   |
> > u32| size  |
> > u8[64] | producer  |
> > u32| next_msg_off  |
> > bf_log_msg[l]  | msgs  |
> >+---+
> 
> I suggest replacing .size and .next_msg_off with .messages containing l:
> 
> .size can then be calculated from .messages; again, reliably avoiding
> inconsistency between .size and .next_msg_off.
> 
> Allocated size doesn't seem useful if writers must anyway maintain state
> containing the starting address. If writers must be allowed to be completely
> stateless then maybe at least rename .size to .allocated_size and see below
> for discovery.
> 
> Having .messages also eliminates the need for an end-of-messages marker
> when the allocated space is not yet filled.
> 

After some thinking, it makes sense to replace the meaning of .size with the
meaning of .next_msg_off and removing .next_msg_off from the structure. This 
wouldn't be useful to store for the readers of the log.

> 
> > bf_log_msg:
> >+---+
> > u32| size  |
> > u64| ts_nsec   |
> > u32| level |
> > u32| facility  |
> > u32| msg_off   |
> > u8[n]  | type  |
> > u8[m]  | msg   |
> >+---+
> 
> It seems inconsistent that log_header.size and log_msg.size cover only
> the respective struct itself while log_buffer.size also covers all
> subordinate messages. Skipping all .size in this version fixes that.
> 
> And log_msg.size is not very useful since both .type and .msg have variable
> length; it's not possible to access .msg without scanning .type. Please at
> a minimum add .type_size but better yet replace .size with .type_size and
> .msg_size.
> 

You bring up some good points about the names for the fields and that they need
to be more consistent. By removing .size in bf_log_header, this should make it
more consistent.

> 
> > There is still the outstanding issue of how the logs will be sent to the 
> > OS. If
> > UEFI is used, we can use config tables. If ACPI or Device Tree is used, we 
> > can
> > use bf_log_header.next_bflh_addr to present the logs. If none of these 
> > platforms
> > are used, it becomes a lot trickier to solve this issue.
> > 
> > Any suggestions are much appreciated and will be taken into consideration.
> 
> Having bf_log_header.magic and some bf_log_header.$checksum, a strict rule
> for bf_log_header start address granularity and a strict maximum offset
> for the first header from top and/or bottom of memory allows to quickly
> discover a log in memory without explicit handover.
> 

This is something we'll have to think about some more. We aren't convinced about
using .magic for log discovery and are looking for a more explicit way of doing
this.

> 
> > LPC System Boot and Security Micro-conference on the 22nd of September
> > at 7:50 AM PDT (14:50 UTC).
> 
> Have fun! :)
> 
> 
> Heinrich Schuchardt wrote:
> > We already the EFI_TCG2_PROTOCOL and RFC 5424 (The syslog protocol).
> > Why do we need to start from scratch?
> 
> That's a good question. I guess noone wants to settle for a standard
> from somewhere else. ;)
> 
> I wouldn't mind if log_msg was a syslog transport

Re: [PATCH] part: return -ENOSYS when get_info not valid.

[schspa]

在 2021-10-19星期二的 17:23 +0200，Heinrich Schuchardt写道：
> On 10/19/21 15:35, zhaohui.shi wrote:
> > From: schspa 
> > 
> > In some case, get_info() interface can be NULL, add this check to
> > stop
> > from crash.
> 
> Thank you for reviewing the partition driver code.
> 
> There seems to be no driver missing a get_info implementation. Where
> did
> you run into a problem?
> 
Yes, I do run into a problem, In my spl build, CONFIG_SPL_FS_EXT4,
CONFIG_SPL_FS_FAT, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION are all
not enabled. In this case, get_info implementation is NULL. see
'part_get_info_ptr' and 'part_print_ptr' and part_efi.c for detail.

> Why should we only check .get_info and not .test and not .print?
> 

All part type driver have .test implementation, it can't be NULL,
and .print have NULL pointer judgement already.

> > 
> > Signed-off-by: schspa 
> 
> Please, provide a name.
> 
> > ---
> >   disk/part.c | 7 +++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/disk/part.c b/disk/part.c
> > index a6a8f7052b..7af3240ec7 100644
> > --- a/disk/part.c
> > +++ b/disk/part.c
> > @@ -668,6 +668,13 @@ int part_get_info_by_name_type(struct blk_desc
> > *dev_desc, const char *name,
> > part_drv = part_driver_lookup_type(dev_desc);
> > if (!part_drv)
> > return -1;
> > +
> > +   if (!part_drv->get_info) {
> > +   PRINTF("## Driver %s does not have the get_info()
> > method\n",
> > +  part_drv->name);
> 
> Please, use log_debug() to avoid noise on the console on every boot.
> 

I think it's OK to use PRINTF, because of this BUG occurs only when
user give a bad part configuration, and this error message can prompt
the user that a configuration error has occurred.
Besides, 'part_get_info' use PRINTF for this null pointer protection
too.

> Best regards
> 
> Heinrich
> 
> > +   return -ENOSYS;
> > +   }
> > +
> > for (i = 1; i < part_drv->max_entries; i++) {
> > ret = part_drv->get_info(dev_desc, i, info);
> > if (ret != 0) {
> > 

-- 
Best regards

schspa 

Re: [PATCH] part: return -ENOSYS when get_info not valid.

[schspa]

在 2021-10-20星期三的 06:44 +0200，Heinrich Schuchardt写道：
> 
> 
> On 10/20/21 04:37, schspa wrote:
> > 在 2021-10-19星期二的 17:23 +0200，Heinrich Schuchardt写道：
> > > On 10/19/21 15:35, zhaohui.shi wrote:
> > > > From: schspa 
> > > > 
> > > > In some case, get_info() interface can be NULL, add this check to
> > > > stop
> > > > from crash.
> > > 
> > > Thank you for reviewing the partition driver code.
> > > 
> > > There seems to be no driver missing a get_info implementation.
> > > Where
> > > did
> > > you run into a problem?
> > > 
> > Yes, I do run into a problem, In my spl build, CONFIG_SPL_FS_EXT4,
> > CONFIG_SPL_FS_FAT, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION are all
> > not enabled. In this case, get_info implementation is NULL. see
> > 'part_get_info_ptr' and 'part_print_ptr' and part_efi.c for detail.
> > 
> > > Why should we only check .get_info and not .test and not .print?
> > > 
> > 
> > All part type driver have .test implementation, it can't be NULL,
> > and .print have NULL pointer judgement already.
> > 
> > > > 
> > > > Signed-off-by: schspa 
> > > 
> > > Please, provide a name.
> > > 
> > > > ---
> > > >    disk/part.c | 7 +++
> > > >    1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/disk/part.c b/disk/part.c
> > > > index a6a8f7052b..7af3240ec7 100644
> > > > --- a/disk/part.c
> > > > +++ b/disk/part.c
> > > > @@ -668,6 +668,13 @@ int part_get_info_by_name_type(struct
> > > > blk_desc
> > > > *dev_desc, const char *name,
> > > >  part_drv = part_driver_lookup_type(dev_desc);
> > > >  if (!part_drv)
> > > >  return -1;
> > > > +
> > > > +   if (!part_drv->get_info) {
> > > > +   PRINTF("## Driver %s does not have the get_info()
> > > > method\n",
> > > > +  part_drv->name);
> > > 
> > > Please, use log_debug() to avoid noise on the console on every
> > > boot.
> > > 
> > 
> > I think it's OK to use PRINTF, because of this BUG occurs only when
> > user give a bad part configuration, and this error message can prompt
> > the user that a configuration error has occurred.
> > Besides, 'part_get_info' use PRINTF for this null pointer protection
> > too.
> 
> Above you write that part_drv->get_info = NULL is part of your
> configuration. So it will always be printed. The size of the SPL is
> very
> critical on many boards. We should avoid anything that increases it.
> 

Considering this problem, I will upload a new patch to use log_debug()
for error message.

> Why is part_get_info_by_name_type() being called in your configuration
> which does not provide a partition driver in SPL? Are there some
> dependencies missing in the Kconfig files?
> 

In my case, I have 
CONFIG_SPL_EFI_PARTITION=y
CONFIG_SPL_LIBDISK_SUPPORT=y
but forget to enable CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION.


Yes, it seems we can have some dependencies in Kconfig like this:
config SPL_LIBDISK_SUPPORT
bool "Support disk partitions"
depends on CONFIG_SPL_EXT_SUPPORT || CONFIG_SPL_FAT_SUPPORT ||
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
help

But there is some case for part_iso or part_mac, which have no this
dependencies (because of it don't use part_get_info_ptr to wrap
part_get_info_iso).

How do you think about this ?  Should we add such dependencies ?
part_iso seems shouldn't have dependencies about ext, fat, mmcsd etc.


> Best regards
> 
> Heinrich
> 
> > 
> > > Best regards
> > > 
> > > Heinrich
> > > 
> > > > +   return -ENOSYS;
> > > > +   }
> > > > +
> > > >  for (i = 1; i < part_drv->max_entries; i++) {
> > > >  ret = part_drv->get_info(dev_desc, i, info);
> > > >  if (ret != 0) {
> > > > 
> > 

-- 
schspa 

[PATCH v2] part: return -ENOSYS when get_info not valid.

[schspa]

In some case, get_info() interface can be NULL, add this check to stop
from crash.

Signed-off-by: schspa 
---
 disk/part.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/disk/part.c b/disk/part.c
index a6a8f7052b..f9b9b89861 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -668,6 +668,13 @@ int part_get_info_by_name_type(struct blk_desc *dev_desc, 
const char *name,
part_drv = part_driver_lookup_type(dev_desc);
if (!part_drv)
return -1;
+
+   if (!part_drv->get_info) {
+   log_debug("## Driver %s does not have the get_info() method\n",
+  part_drv->name);
+   return -ENOSYS;
+   }
+
for (i = 1; i < part_drv->max_entries; i++) {
ret = part_drv->get_info(dev_desc, i, info);
if (ret != 0) {
-- 
2.33.1

[PATCH 1/7] tools: imx8mimage: not abort when mmap fail

[sbabic]

> From: Peng Fan 
> When creating flash.bin, the hdmi firmware might not be
> copied to U-Boot source tree. Then mkimage will fail.
> However we are switching to binman, binman will show the
> message if the file not there, and create empty file per
> i.MX8MQ binman node. So we not fail mkimage here othersize
> CI will fail if hdmi firmware not copied here.
> Signed-off-by: Peng Fan 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v2] board: ea: mx7ulp_com: move setting CONFIG_BOOTCOMMAND to defconfig

[sbabic]

> From: Ricardo Salveti 
> Move setting CONFIG_BOOTCOMMAND to the mx7ulp_com_defconfig file.
> It also allows replacing the default CONFIG_BOOTCOMMAND without
> code modification.
> Signed-off-by: Ricardo Salveti 
> Signed-off-by: Oleksandr Suvorov 
> Reviewed-by: Fabio Estevam 
> Reviewed-by: Tom Rini 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 5/7] imx: makefile: drop the use of imx8mimage.sh

[sbabic]

> From: Peng Fan 
> After switch to use binman, no need to use the bash script
> to check file exsiting or not. And there is bug that
> the script will be executed everytime Makefile is used which is
> confusing people.
> Signed-off-by: Peng Fan 
> Tested-by: Frieder Schrempf 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v3 2/2] mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

[sbabic]

> Import HS400 support for iMX7ULP B0 from the Linux kernel:
> 2eaf5a533afd ("mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP")
> According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
> before any setting of STROBE_DLL_CTRL register.
> USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
> for slave sel value. If this register bits value is 0,  it needs
> 256 ref_clk cycles to update slave sel value. IC suggest to set
> bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
> sel value. This will short the lock time of slave.
> i.MX7ULP B0 will need more time to lock the REF and SLV, so change
> to add 5us delay.
> Signed-off-by: Oleksandr Suvorov 
> Reviewed-by: Fabio Estevam 
> Reviewed-by: Jaehoon Chung 
> Reviewed-by: Igor Opaniuk 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: use imx8mm-venice-u-boot.dtsi

[sbabic]

> Use the common imx8mm-venice-u-boot.dtsi (dtb for the
> 'DEFAULT_DEVICE_TREE) so that it inherits things like binman.
> Signed-off-by: Tim Harvey 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v1 1/2] colibri-imx6: use dynamic DDR calibration

[sbabic]

> Enable dynamic DDR calibration to have a reliable behavior on edge
> temperatures conditions.
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Francesco Dolcini 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 1/3] ARM: imx: mx5: Enable BMODE command on MX53 Menlo board

[sbabic]

> The board can do primary/secondary boot switching, enable the bmode command.
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 3/3] smegw01: Select IMX_HAB

[sbabic]

> Select IMX_HAB to allow secure boot.
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 1/3] smegw01: Pass 'mmcpart' to the kernel command line

[sbabic]

> When using SWUpdate, it is necessary to toggle between partitions.
> Use the 'mmcpart' environment variable to accomplish that.
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 3/3] ARM: imx: mx5: Add altbootcmd and resets to M53Menlo

[sbabic]

> Bulletproof the default boot command with reset statements in case
> any command in the chain would fail. In case a failure were to happen,
> the board will reset, increment boot counter and retry the procedure.
> In case the failures persist and the boot counter reaches the bootlimit,
> U-Boot starts altbootcmd instead of the default bootcmd boot command.
> The altbootcmd swaps the default boot partition for the other boot
> partition, which is an identical copy or an older copy, and tries
> booting from that one instead.
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 3/4] arm64: dts: imx8mm-venice-gw7902: use imx8mm-venice-u-boot.dtsi

[sbabic]

> Use the common imx8mm-venice-u-boot.dtsi (dtb for the
> 'DEFAULT_DEVICE_TREE) so that it inherits things like binman.
> Signed-off-by: Tim Harvey 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v1 2/2] apalis-imx6: use dynamic DDR calibration

[sbabic]

> Enable dynamic DDR calibration to have a reliable behavior on edge
> temperatures conditions.
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Francesco Dolcini 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v3 1/2] mmc: fsl_esdhc_imx: initialize data for imx7ulp

[sbabic]

> From: Jorge Ramirez-Ortiz 
> Import data for eSDHC driver for SoC iMX7ULP from the Linux kernel.
> Set supported by u-boot flags only.
> Signed-off-by: Jorge Ramirez-Ortiz 
> Signed-off-by: Ricardo Salveti 
> Co-developed-by: Oleksandr Suvorov 
> Signed-off-by: Oleksandr Suvorov 
> Reviewed-by: Fabio Estevam 
> Reviewed-by: Jaehoon Chung 
> Reviewed-by: Igor Opaniuk 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 2/3] smegw01: Add redundant environment support

[sbabic]

> Add redundant environment support as it is required
> by SWUpdate.
> While at it, place the CONFIG_ENV_OFFSET at 0x10 to allow
> more headroom.
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 2/4] arm64: dts: imx8mm-venice-gw7901: use imx8mm-venice-u-boot.dtsi

[sbabic]

> Use the common imx8mm-venice-u-boot.dtsi (dtb for the
> 'DEFAULT_DEVICE_TREE) so that it inherits things like binman.
> Signed-off-by: Tim Harvey 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 2/3] ARM: imx: mx5: Enable Thumb2 build on MX53 Menlo board

[sbabic]

> Build U-Boot in Thumb2 mode for M53Menlo board, this makes better
> use of the CPU since the instruction density is higher.
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v1 1/1] Makefile.lib: Always rebuild DSDT

[Andy Shevchenko]

The dsdt.asl is usually combined out of several files that are included
in the main one. Whenever we change the content of any of such files,
build system is not able to recognize them. Hence the easiest way is to
force DSDT rebuild each time we run make.

Signed-off-by: Andy Shevchenko 
---
 scripts/Makefile.lib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 07696e86bb54..8c3c893b398a 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -441,7 +441,7 @@ cmd_acpi_c_asl= \
iasl -p $@ -tc $(ASL_TMP) $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \
mv $(patsubst %.c,%.hex,$@) $@
 
-$(obj)/dsdt.c:$(src)/dsdt.asl
+$(obj)/dsdt.c:$(src)/dsdt.asl FORCE
$(call cmd,acpi_c_asl)
$(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@
 
-- 
2.33.0

Pull request: u-boot-imx u-boot-imx-20211020

[Stefano Babic]

Hi Tom,

this is a first PR for u-boot-imx. I have still a lot of patches in 
queue, so a second PR will follow. Simon's patches to improve buildman 
are merged here (thanks, else I had no idea how to discover the cause of 
crashes). CI ran with them.


The following changes since commit ea67f467a43e4c8852bd1ce1bb75f5dc6c3788d1:

  Merge branch '2021-10-06-assorted-improvements' (2021-10-06 13:46:31 
-0400)


are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git

for you to fetch changes up to f0045799c6957e374cc12a6146ac60881cd827d6:

  imx8mm-cl-iot-gate-optee: align config with Kconfig (2021-10-20 
12:13:44 +0200)



Andrej Rosano (2):
  imx53: usbarmory: Add card detect configuration
  imx53: usbarmory: Use ethernet driver model

Andrey Zhizhikin (1):
  tree: imx: remove old fit generator script

Fabio Estevam (4):
  imx8mm-cl-iot-gate: Split the defconfigs
  smegw01: Pass 'mmcpart' to the kernel command line
  smegw01: Add redundant environment support
  smegw01: Select IMX_HAB

Francesco Dolcini (2):
  colibri-imx6: use dynamic DDR calibration
  apalis-imx6: use dynamic DDR calibration

Frieder Schrempf (2):
  imx: imx6ul: Add support for Kontron Electronics SL/BL 
i.MX6UL/ULL boards (N63xx/N64xx)
  imx: imx8mm: Add support for Kontron Electronics SL/BL 
i.MX8M-Mini boards (N801x)


Haolin Li (1):
  mtd: nand: Fix typo in MXC Kconfig symbol description

Heiko Schocher (3):
  spl_fit. add hook to make fixes after fit header is loaded
  imx: spl: implement spl_load_simple_fit_fix_load
  imx: spl: fix imx8m secure boot

Heiko Thiery (1):
  rtc: rv8803: add epson,rx8803 and epson,rx8900 compatible

Jorge Ramirez-Ortiz (1):
  mmc: fsl_esdhc_imx: initialize data for imx7ulp

Marek Vasut (4):
  ARM: dts: imx8mm-verdin: Set PHY mode to RGMII-ID
  ARM: imx: mx5: Enable BMODE command on MX53 Menlo board
  ARM: imx: mx5: Enable Thumb2 build on MX53 Menlo board
  ARM: imx: mx5: Add altbootcmd and resets to M53Menlo

Matthias Schiffer (1):
  imx: mx7: spl: fix CONFIG_SPL_MAX_SIZE definition

Michael Scott (1):
  misc: ocotp: Allow disabling ocotp driver in SPL

Oleksandr Suvorov (5):
  imx8mm_evk: Increase CONFIG_SYS_BOOTM_LEN to 64MB
  imx8mq_evk: Increase CONFIG_SYS_BOOTM_LEN to 64MB
  imx8qm_mek: Increase CONFIG_SYS_BOOTM_LEN to 64MB
  ARM: dts: imx: use generic name bus
  mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

Peng Fan (2):
  tools: imx8mimage: not abort when mmap fail
  imx: makefile: drop the use of imx8mimage.sh

Ricardo Salveti (4):
  mx7ulp: Allow to enable CONFIG_IMX_HAB
  Kconfig: Don't use RSA_FREESCALE_EXP on MX7ULP
  ARM: dts: imx6-apalis: enable watchdog
  board: ea: mx7ulp_com: move setting CONFIG_BOOTCOMMAND to defconfig

Simon Glass (2):
  buildman: Write output even on fatal error
  buildman: Detect Kconfig loops

Stefano Babic (2):
  kontron-sl-mx8mm: fix missing configs and deadlock in CI
  imx8mm-cl-iot-gate-optee: align config with Kconfig

Teresa Remmet (1):
  arm: dts: imx8mp: Generate single bootable binary

Tim Harvey (15):
  board: gateworks: venice: display hwmon details by default
  board: gateworks: venice: do not overwrite serial#
  arm: dts: imx8mm-venice-gw700x: fix mp5416 pmic config
  board: gateworks: venice: update thermal temp thresholds per cpu 
grade

  arm: dts: imx8mm-venice*: remove thermal zone overrides
  imx: ventana: add part command
  imx: ventana: add U-Boot watchdog support
  imx: ventana: remove phy gpio reset from dt
  imx: ventana: enable additional USB ether devices
  imx: ventana: fix splash logo drawing
  imx: ventana: update LVDS support
  imx: ventana: fix USB hub reset
  arm64: dts: imx8mm-venice-gw700x: use imx8mm-venice-u-boot.dtsi
  arm64: dts: imx8mm-venice-gw7901: use imx8mm-venice-u-boot.dtsi
  arm64: dts: imx8mm-venice-gw7902: use imx8mm-venice-u-boot.dtsi

Ye Li (4):
  mmc: fsl_esdhc_imx: Fix clock disable issue
  arm: imx8m: Fix pad DSE issue for i.MX8MM/MN/MP
  mtd: nand: mxs_nand_spl: Add nand_spl_adjust_offset
  mx7ulp: Update wdog disable sequence

Ying-Chun Liu (PaulLiu) (2):
  imx8m: Restrict usable memory based on rom_pointer[0]
  arm: imx8m: imx8mm-cl-iot-gate: Add support for detect memory size

 Makefile   |3 -
 arch/arm/dts/Makefile  |8 +-
 arch/arm/dts/imx53-m53menlo-u-boot.dtsi|2 +-
 arch/arm/dts/imx53-usbarmory.dts   |1 +
 arch/arm/dts/imx53.dtsi|4 +-
 arch/arm/dts/imx6-apalis-u-boot.dtsi   |   11 ++
 arch/arm/dts/imx6dl.dtsi   |4 +-
 arch/arm/dts/imx6q-display5-u-bo

[PATCH v1 1/1] x86: tangier: Replace Method() by Name() for _STA object

[Andy Shevchenko]

There is no point to use Method() for the constant.
Replace it with Name() defined object. For the _STA
case it saves 3 bytes per each entry.

Before: 2881
After: 2833

Signed-off-by: Andy Shevchenko 
---
 .../asm/arch-tangier/acpi/southcluster.asl| 81 ---
 1 file changed, 17 insertions(+), 64 deletions(-)

diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index a8852f8202c7..4a7c85426182 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -123,10 +123,7 @@ Device (PCI0)
 }
 })
 
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 }
 
 Device (SDHC)
@@ -138,10 +135,7 @@ Device (PCI0)
 })
 Name (PSTS, Zero)
 
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Method (_PS3, 0, NotSerialized)
 {
@@ -168,10 +162,7 @@ Device (PCI0)
 GPIO
 })
 
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Method (_RMV, 0, NotSerialized)
 {
@@ -203,10 +194,8 @@ Device (PCI0)
 Device (BRC2)
 {
 Name (_ADR, 0x02)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+
+Name (_STA, STA_VISIBLE)
 
 Method (_RMV, 0, NotSerialized)
 {
@@ -257,20 +246,14 @@ Device (PCI0)
 }
 })
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 }
 
 Device (I2C1)
 {
 Name (_ADR, 0x0008)
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Name (SSCN, Package ()
 {
@@ -303,10 +286,7 @@ Device (PCI0)
 {
 Name (_ADR, 0x00090001)
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Name (SSCN, Package ()
 {
@@ -328,10 +308,7 @@ Device (PCI0)
 {
 Name (_ADR, 0x000c)
 
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Name (AVBL, Zero)
 Method (_REG, 2, NotSerialized)
@@ -361,10 +338,7 @@ Device (PCI0)
 ^IPC1.PMIC
 })
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Device (RHUB)
 {
@@ -404,20 +378,14 @@ Device (PCI0)
 {
 Name (_ADR, 0x0017)
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 }
 
 Device (HSU0)
 {
 Name (_ADR, 0x00040001)
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Device (BTH0)
 {
@@ -428,10 +396,7 @@ Device (PCI0)
 HSU0
 })
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Name (RBUF, ResourceTemplate()
 {
@@ -466,10 +431,7 @@ Device (PCI0)
 {
 Name (_ADR, 0x0013)
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Device (PMIC)
 {
@@ -481,10 +443,7 @@ Device (PCI0)
 IPC1
 })
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Name (RBUF, ResourceTemplate()
 {
@@ -554,10 +513,7 @@ Device (PCI0)
 Name (_ADR, 0x0015)
 Name (_UID, Zero)
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 
 Name (RBUF, ResourceTemplate ()
 {
@@ -594,8 +550,5 @@ Device (FLIS)
 Return (RBUF)
 }
 
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
 }
-- 
2.33.0

Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Andre Przywara]

On Wed, 20 Oct 2021 09:29:25 +0200
Pali Rohár  wrote:

Hi,

> On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote:
> > Some image types (kwbimage and mxsimage) always depend on OpenSSL, so
> > they can only be included in mkimage when TOOLS_LIBCRYPTO is selected.
> > Use Makefile logic to conditionally link the files.
> > 
> > Signed-off-by: Samuel Holland   
> 
> NAK.
> 
> As explained in previous email [1], kwbimage is required for building
> Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms.
> Therefore it cannot be disabled or hidden behind some user config
> options for these platforms (and it does not matter if it is crypto
> option or any other option).

So somehow we need to find a solution between your view and Alex' view of
things.
First: Pali, do you see any actual problem at the moment? TOOLS_LIBCRYPTO
defaults to y, so if I am not mistaken that means that a user would need
to deliberately turn that off to trigger build errors?
And also: the situation with this patch is not worse as before, isn't it?

So if it's just the missing improvement that you are concerned about, I am
not sure that should block this patch? I mean you could always propose
your own version of that missing piece, to improve the situation for the
boards you care about? And we should have this discussion there?

As it stands right now, this patch just improves things (just not
*everything*), and it is a prerequisite for the rest of the series
(unrelated to your problems), so I would like to go ahead on this one.

Cheers,
Andre.

> kwbimage must be unconditionally enabled on
> these platforms like it was before this change, as it is crucial part of
> build.
> 
> [1] - https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/
> 
> > ---
> > 
> > Changes in v4:
> >  - Do not select TOOLS_LIBCRYPTO anywhere
> > 
> > Changes in v3:
> >  - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best
> >as I can tell, using the suggestions from Pali Rohár)
> > 
> > Changes in v2:
> >  - Refactored the first patch on top of TOOLS_LIBCRYPTO
> > 
> >  scripts/config_whitelist.txt |  1 -
> >  tools/Makefile   | 19 +--
> >  tools/mxsimage.c |  3 ---
> >  3 files changed, 5 insertions(+), 18 deletions(-)
> > 
> > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> > index cd94b5777a..affae6875d 100644
> > --- a/scripts/config_whitelist.txt
> > +++ b/scripts/config_whitelist.txt
> > @@ -828,7 +828,6 @@ CONFIG_MXC_UART_BASE
> >  CONFIG_MXC_USB_FLAGS
> >  CONFIG_MXC_USB_PORT
> >  CONFIG_MXC_USB_PORTSC
> > -CONFIG_MXS
> >  CONFIG_MXS_AUART
> >  CONFIG_MXS_AUART_BASE
> >  CONFIG_MXS_OCOTP
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 999fd46531..a9b3d982d8 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -94,9 +94,11 @@ ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix 
> > lib/ecdsa/, ecdsa-libcrypto.
> >  AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \
> > aes-encrypt.o aes-decrypt.o)
> >  
> > -# Cryptographic helpers that depend on openssl/libcrypto
> > -LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
> > -   fdt-libcrypto.o)
> > +# Cryptographic helpers and image types that depend on openssl/libcrypto
> > +LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := \
> > +   lib/fdt-libcrypto.o \
> > +   kwbimage.o \
> > +   mxsimage.o
> >  
> >  ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
> >  
> > @@ -118,10 +120,8 @@ dumpimage-mkimage-objs := aisimage.o \
> > imximage.o \
> > imx8image.o \
> > imx8mimage.o \
> > -   kwbimage.o \
> > lib/md5.o \
> > lpc32xximage.o \
> > -   mxsimage.o \
> > omapimage.o \
> > os_support.o \
> > pblimage.o \
> > @@ -156,22 +156,13 @@ fit_info-objs   := $(dumpimage-mkimage-objs) 
> > fit_info.o
> >  fit_check_sign-objs   := $(dumpimage-mkimage-objs) fit_check_sign.o
> >  file2include-objs := file2include.o
> >  
> > -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_TOOLS_LIBCRYPTO),)
> > -# Add CONFIG_MXS into host CFLAGS, so we can check whether or not register
> > -# the mxsimage support within tools/mxsimage.c .
> > -HOSTCFLAGS_mxsimage.o += -DCONFIG_MXS
> > -endif
> > -
> >  ifdef CONFIG_TOOLS_LIBCRYPTO
> >  # This affects include/image.h, but including the board config file
> >  # is tricky, so manually define this options here.
> >  HOST_EXTRACFLAGS   += -DCONFIG_FIT_SIGNATURE
> >  HOST_EXTRACFLAGS   += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
> >  HOST_EXTRACFLAGS   += -DCONFIG_FIT_CIPHER
> > -endif
> >  
> > -# MXSImage needs LibSSL
> > -ifneq 
> > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
> >  HOSTCFLA

Re: buildman stops (crashed) on current master

[Simon Glass]

Hi Stefano,

On Wed, 20 Oct 2021 at 03:55, Stefano Babic  wrote:
>
> On 20.10.21 05:42, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 19 Oct 2021 at 17:01, Tom Rini  wrote:
> >>
> >> On Tue, Oct 19, 2021 at 04:59:15PM -0600, Simon Glass wrote:
> >>> Hi Tom,
> >>>
> >>> On Tue, 19 Oct 2021 at 16:53, Tom Rini  wrote:
> 
>  On Tue, Oct 19, 2021 at 05:39:12PM +0200, Stefano Babic wrote:
> > Hi Simon,
> >
> > On 07.10.21 15:43, Simon Glass wrote:
> >> Hi Stefano,
> >>
> >> On Thu, 7 Oct 2021 at 04:37, Stefano Babic  wrote:
> >>>
> >>> Hi all,
> >>>
> >>> CI stops by building aarch64 without notice, for reference:
> >>>
> >>> https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/332319
> >>>
> >>> There is no error, just process is killed. It looks like it stops at
> >>> xilinx_zynqmp_virt,
> >>>
> >>> ./tools/buildman/buildman -o /tmp -P -E -W aarch64but board can be 
> >>> built
> >>> without issues.
> >>>
> >>> If I build on my host (not in docker, anyway), it generally builds 
> >>> fine
> >>> - but it crashes sometimes, too. On gitlab instance , it crashes.
> >>> Issue does not seem that depends on merged patches, and introduces
> >>> boards were already built successfully. Any hint ? I have also no idea
> >>> what I should look as what I see is just
> >>>
> >>> "usr/bin/bash: line 104:24 Killed
> >>> ./tools/buildman/buildman -o /tmp -P -E -W aarch64"
> >>
> >> I cannot see that link. I am not sure what is going on. Does it say
> >> what signal killed it?
> >
> > Pipelines on our server were not public - I have enbaled now for 
> > u-boot-imx.
> >
> >>
> >> Does it sit there for an hour and timeout? If so, then I  did see that
> >> myself once recently, when the Kconfig needed stdin, but I could not
> >> quitetie it down. I think buildman would provide it, but sometimes
> >> not, apparently. So it can happen when there is an existing build
> >> there and your new one which adds Kconfig options that don't have
> >> defaults, or something like that?
> >>
> >
> > I have investigated further, and I can reproduce it on my host outside 
> > the
> > gitlab server. buildman causes a OOM, but I cannot find the cause.
> >
> > Strange enough, this happens with the "aarch64" target, and I cannot
> > reproduce it with Tom's master. So it seems that -master is ok, and 
> > somethin
> > on u-boot-imx generates the OOM.
> >
> > However
> >
> > The OOM happens always when -2 (two boards remain) appears. I can see 
> > with
> > htop that buildman starts to allocate memory until it is exhausted 
> > (64GB RAM
> > + 8 GB swap). Then the kernel decides that it is enough and kills 
> > buildman -
> > this is what I see on Ci.
> >
> > You can see now the pipelines:
> >
> > https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/9520
> >
> > I have then split aarch64 and I built imx8 separately - same result. The
> > pipeline stops with xilinx board, but they have nothing to do. In fact, 
> > I
> > can build all xilinx board separately. If I run buildman -W aarch64 -x
> > xilinx, OOM is shown by another board.
> >
> > Strange enough, I can build each single board with buildman without 
> > issues,
> > neither errors nor warnongs. Just when buildman runs all together 
> > (aarch64,
> > 308 boards), the OOM is generated.
> >
> > Bisect does not help: I started bisect, and at the end this commit was
> > presented:
> >
> > commit 53a24dee86fb72ae41e7579607bafe13442616f2
> > Author: Fabio Estevam 
> > Date:   Mon Aug 23 21:11:09 2021 -0300
> >
> >  imx8mm-cl-iot-gate: Split the defconfigs
> 
>  I strongly suspect what's going on here is that these new defconfigs are
>  out of sync with changes now in Kconfig.  The build itself will just sit
>  there, waiting for the "oldconfig" prompt to be answered.
> 
>  I want to say the problem here is that stdin is open, rather than
>  pointing to something closed and would lead to the build failing
>  immediately, rather than once a timeout is hit, or OOM kicks in due to
>  kconfig chewing up all the memory.
> >>>
> >>> Yes that's exactly what I saw...
> >>>
> >>> In fact, see this commit:
> >>>
> >>> e62a24ce27a buildman: Avoid hanging when the config changes
> >>>
> >>> But that was 3 years ago.
> >>
> >> Looks like something else needs to be changed then, I've bisected down
> >> similar failures here before very recently.
> >
> > I dug into this a bit and I think buildman can detect this situation.
> > I'll send a little series.
> >
>
> Patch definetly help ;-)
>
> It breaks build (on CI when build-tools runs), but I get much more
> details when I build locally single boards. I can 

Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()

[Simon Glass]

Hi Masami,

On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
 wrote:
>
> Hi Simon,
>
> 2021年10月15日(金) 9:40 Simon Glass :
> >
> > Hi Takahiro,
> >
> > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro  
> > wrote:
> > >
> > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
> > > .rodata"") failed to revert the removal of efi_get_public_key_data().
> > >
> > > Add back this function and move it under lib/efi_loader so that other
> > > platforms can utilize it. It is now declared as a weak function so that
> > > it can be replaced with a platform-specific implementation.
> > >
> > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
> > > .rodata"")
> > > Signed-off-by: AKASHI Takahiro 
> > > ---
> > >  lib/efi_loader/efi_capsule.c | 36 
> > >  1 file changed, 36 insertions(+)
> > >
> > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > index b75e4bcba1a9..44f5da61a9be 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -11,15 +11,20 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include 
> > >  #include 
> > >  #include 
> > >
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > >  const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
> > >  static const efi_guid_t efi_guid_firmware_management_capsule_id =
> > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > > @@ -251,6 +256,37 @@ out:
> > >  }
> > >
> > >  #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
> >
> > I don't think this should be weak. What other way is there of handling
> > this and why would it be platform-specific?
>
> I have a question about the current design of the capsule auth key.
> If the platform has its own key-storage, how can the platform use the
> platform specific storage? Does such platform load the key from the storage
> and generate the dtb node in the platform initialization code? (or
> device driver?)

Are we talking about a public key (which I assume from the function
naming) or some secret key. What is an auth key?

As I understand it, the public key should be provided by the platform
in devicetree that U-Boot uses, by whatever prior stage has access to
the key.

Regards,
Simon

Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Pali Rohár]

On Wednesday 20 October 2021 14:29:02 Andre Przywara wrote:
> On Wed, 20 Oct 2021 09:29:25 +0200
> Pali Rohár  wrote:
> 
> Hi,
> 
> > On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote:
> > > Some image types (kwbimage and mxsimage) always depend on OpenSSL, so
> > > they can only be included in mkimage when TOOLS_LIBCRYPTO is selected.
> > > Use Makefile logic to conditionally link the files.
> > > 
> > > Signed-off-by: Samuel Holland   
> > 
> > NAK.
> > 
> > As explained in previous email [1], kwbimage is required for building
> > Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms.
> > Therefore it cannot be disabled or hidden behind some user config
> > options for these platforms (and it does not matter if it is crypto
> > option or any other option).
> 
> So somehow we need to find a solution between your view and Alex' view of
> things.
> First: Pali, do you see any actual problem at the moment? TOOLS_LIBCRYPTO
> defaults to y, so if I am not mistaken that means that a user would need
> to deliberately turn that off to trigger build errors?
> And also: the situation with this patch is not worse as before, isn't it?

I do not think so. Without this patch, kwbimage is always going
compiled, which means it is compiled also for mvebu platforms which
needs it.

With this patch it is possible via _valid_ config options to disable
compilation of kwbimage which would lead to totally bogus and
unintuitive behavior and errors. Without this patch compilation fails on
exact and clear error = cryto header files (or libs) were not found and
user / developer / package maintainer would know what is needed (= mean
to install missing dependency).

> So if it's just the missing improvement that you are concerned about, I am
> not sure that should block this patch?

V3 patch was improvement - it enforced required dependencies and I guess
it showed some build system error message when dependences were not met.
This is improvement from situation without patch when it failed on
compiling kwbimage which probably showed error message about missing
header files (or libs, depends on which stage it failed). It was not the
best choice as in some cases it enforced crypto dependencies also in
cases when they were not really required -- but it should have solve the
problem that dependences are there for platforms which require them.

v4 patch is not improvement, it is step backward - it started allowing
to compile mkimage without required functionality, even on platforms
which needs them, and effectively hides issue which is there.

> I mean you could always propose
> your own version of that missing piece, to improve the situation for the
> boards you care about? And we should have this discussion there?

I think I have written details and some proposed solution in that email.
What is needed is to ensure that kwbimage is always compiled for
platforms which require it (list of platform are in email 1 in previous
email). This can be done as hard dependency like it is currently without
this patch (ugly, does not show nice error message and enforce everybody
to have crypto dependency, even platforms which do not need it). Other
solution could be to define some select symbol which says that kwbimage
is required and then kwbimage would be unconditionally compiled when
this symbol is selected. And to make error message nice in build system,
this symbol could depends on crypto symbol to ensure that all
dependencies are met when trying to compile something which needs it.
Another option could be to implement required crypto functions directly
in u-boot source tree to remove external dependency. I do not know which
solution is the best or how hard they are to implement, and neither what
can be accepted by other u-boot developers / maintainers. I see an issue
here that fixing this problem need to touch more parts of u-boot source
code and build system which, which means that u-boot maintainers need to
say what they are willing to accept and what not.

> As it stands right now, this patch just improves things (just not
> *everything*), and it is a prerequisite for the rest of the series
> (unrelated to your problems), so I would like to go ahead on this one.

Well, maybe this patch improves some things about non-mvebu platforms,
but makes mvebu platform code / build system worse. And due to this fact
I cannot say that I want this change...

> Cheers,
> Andre.
> 
> > kwbimage must be unconditionally enabled on
> > these platforms like it was before this change, as it is crucial part of
> > build.
> > 
> > [1] - https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/
> > 
> > > ---
> > > 
> > > Changes in v4:
> > >  - Do not select TOOLS_LIBCRYPTO anywhere
> > > 
> > > Changes in v3:
> > >  - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best
> > >as I can tell, using the suggestions from Pali Rohár)
> > > 
> > > Changes in v2:
> > >  - Refactored the first patch on top of TOOLS_LIBCRYPTO
> 

Re: Pull request: u-boot-imx u-boot-imx-20211020

[Stefano Babic]

On 20.10.21 14:48, Stefano Babic wrote:

Hi Tom,

this is a first PR for u-boot-imx. I have still a lot of patches in 
queue, so a second PR will follow. Simon's patches to improve buildman 
are merged here (thanks, else I had no idea how to discover the cause of 
crashes). CI ran with them.


PR was tagged, I forget to copy it:

u-boot-imx-20211020
---

First PR from u-boot-imx for 2022.01

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/9535

- new board: kontron-sl-mx8mm
- imx8m:
- fix secure boot
- imx ESDHC: fixes
- i.MX53: Support thum2, bmode and fixes for Menlo board
  usbarmory switch to Ethernet driver model
- imx6 :
- DDR calibration for Toradex boards
- imx7:
- Fixes
- Updated gateworks boards (ventana / venice)

Regards,
Stefano



The following changes since commit 
ea67f467a43e4c8852bd1ce1bb75f5dc6c3788d1:


   Merge branch '2021-10-06-assorted-improvements' (2021-10-06 13:46:31 
-0400)


are available in the Git repository at:

   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git

for you to fetch changes up to f0045799c6957e374cc12a6146ac60881cd827d6:

   imx8mm-cl-iot-gate-optee: align config with Kconfig (2021-10-20 
12:13:44 +0200)



Andrej Rosano (2):
   imx53: usbarmory: Add card detect configuration
   imx53: usbarmory: Use ethernet driver model

Andrey Zhizhikin (1):
   tree: imx: remove old fit generator script

Fabio Estevam (4):
   imx8mm-cl-iot-gate: Split the defconfigs
   smegw01: Pass 'mmcpart' to the kernel command line
   smegw01: Add redundant environment support
   smegw01: Select IMX_HAB

Francesco Dolcini (2):
   colibri-imx6: use dynamic DDR calibration
   apalis-imx6: use dynamic DDR calibration

Frieder Schrempf (2):
   imx: imx6ul: Add support for Kontron Electronics SL/BL 
i.MX6UL/ULL boards (N63xx/N64xx)
   imx: imx8mm: Add support for Kontron Electronics SL/BL 
i.MX8M-Mini boards (N801x)


Haolin Li (1):
   mtd: nand: Fix typo in MXC Kconfig symbol description

Heiko Schocher (3):
   spl_fit. add hook to make fixes after fit header is loaded
   imx: spl: implement spl_load_simple_fit_fix_load
   imx: spl: fix imx8m secure boot

Heiko Thiery (1):
   rtc: rv8803: add epson,rx8803 and epson,rx8900 compatible

Jorge Ramirez-Ortiz (1):
   mmc: fsl_esdhc_imx: initialize data for imx7ulp

Marek Vasut (4):
   ARM: dts: imx8mm-verdin: Set PHY mode to RGMII-ID
   ARM: imx: mx5: Enable BMODE command on MX53 Menlo board
   ARM: imx: mx5: Enable Thumb2 build on MX53 Menlo board
   ARM: imx: mx5: Add altbootcmd and resets to M53Menlo

Matthias Schiffer (1):
   imx: mx7: spl: fix CONFIG_SPL_MAX_SIZE definition

Michael Scott (1):
   misc: ocotp: Allow disabling ocotp driver in SPL

Oleksandr Suvorov (5):
   imx8mm_evk: Increase CONFIG_SYS_BOOTM_LEN to 64MB
   imx8mq_evk: Increase CONFIG_SYS_BOOTM_LEN to 64MB
   imx8qm_mek: Increase CONFIG_SYS_BOOTM_LEN to 64MB
   ARM: dts: imx: use generic name bus
   mmc: sdhci-esdhc-imx: Add HS400 support for iMX7ULP

Peng Fan (2):
   tools: imx8mimage: not abort when mmap fail
   imx: makefile: drop the use of imx8mimage.sh

Ricardo Salveti (4):
   mx7ulp: Allow to enable CONFIG_IMX_HAB
   Kconfig: Don't use RSA_FREESCALE_EXP on MX7ULP
   ARM: dts: imx6-apalis: enable watchdog
   board: ea: mx7ulp_com: move setting CONFIG_BOOTCOMMAND to defconfig

Simon Glass (2):
   buildman: Write output even on fatal error
   buildman: Detect Kconfig loops

Stefano Babic (2):
   kontron-sl-mx8mm: fix missing configs and deadlock in CI
   imx8mm-cl-iot-gate-optee: align config with Kconfig

Teresa Remmet (1):
   arm: dts: imx8mp: Generate single bootable binary

Tim Harvey (15):
   board: gateworks: venice: display hwmon details by default
   board: gateworks: venice: do not overwrite serial#
   arm: dts: imx8mm-venice-gw700x: fix mp5416 pmic config
   board: gateworks: venice: update thermal temp thresholds per cpu 
grade

   arm: dts: imx8mm-venice*: remove thermal zone overrides
   imx: ventana: add part command
   imx: ventana: add U-Boot watchdog support
   imx: ventana: remove phy gpio reset from dt
   imx: ventana: enable additional USB ether devices
   imx: ventana: fix splash logo drawing
   imx: ventana: update LVDS support
   imx: ventana: fix USB hub reset
   arm64: dts: imx8mm-venice-gw700x: use imx8mm-venice-u-boot.dtsi
   arm64: dts: imx8mm-venice-gw7901: use imx8mm-venice-u-boot.dtsi
   arm64: dts: imx8mm-venice-gw7902: use imx8mm-venice-u-boot.dtsi

Ye Li (4):
   mmc: fsl_esdhc_imx: Fix clock disable issue
   arm: imx8m: Fix pad DSE issue for i.MX8MM/MN/MP
   mtd: nand: mxs_nand_spl: Add nand_spl_adjust_offset
   mx7ulp: Update wdog disable se

Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Samuel Holland]

On 10/20/21 8:47 AM, Pali Rohár wrote:
> On Wednesday 20 October 2021 14:29:02 Andre Przywara wrote:
>> On Wed, 20 Oct 2021 09:29:25 +0200
>> Pali Rohár  wrote:
>>
>> Hi,
>>
>>> On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote:
 Some image types (kwbimage and mxsimage) always depend on OpenSSL, so
 they can only be included in mkimage when TOOLS_LIBCRYPTO is selected.
 Use Makefile logic to conditionally link the files.

 Signed-off-by: Samuel Holland   
>>>
>>> NAK.
>>>
>>> As explained in previous email [1], kwbimage is required for building
>>> Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms.
>>> Therefore it cannot be disabled or hidden behind some user config
>>> options for these platforms (and it does not matter if it is crypto
>>> option or any other option).
>>
>> So somehow we need to find a solution between your view and Alex' view of
>> things.
>> First: Pali, do you see any actual problem at the moment? TOOLS_LIBCRYPTO
>> defaults to y, so if I am not mistaken that means that a user would need
>> to deliberately turn that off to trigger build errors?
>> And also: the situation with this patch is not worse as before, isn't it?
> 
> I do not think so. Without this patch, kwbimage is always going
> compiled, which means it is compiled also for mvebu platforms which
> needs it.
> 
> With this patch it is possible via _valid_ config options to disable
> compilation of kwbimage which would lead to totally bogus and
> unintuitive behavior and errors. Without this patch compilation fails on
> exact and clear error = cryto header files (or libs) were not found and
> user / developer / package maintainer would know what is needed (= mean
> to install missing dependency).

Andre is correct. No version of this patch makes *any* change to *any*
in-tree defconfig build, because TOOLS_LIBCRYPTO=y in all defconfigs.

>> So if it's just the missing improvement that you are concerned about, I am
>> not sure that should block this patch?
> 
> V3 patch was improvement - it enforced required dependencies and I guess
> it showed some build system error message when dependences were not met.
> This is improvement from situation without patch when it failed on
> compiling kwbimage which probably showed error message about missing
> header files (or libs, depends on which stage it failed). It was not the
> best choice as in some cases it enforced crypto dependencies also in
> cases when they were not really required -- but it should have solve the
> problem that dependences are there for platforms which require them.

No, you would have seen the exact same error message with v3 as you get
today without any patch. Because all v3 does is enforce that kwbimage.o
gets compiled on certain platforms (whereas today, it is compiled on
*all* platforms).

> v4 patch is not improvement, it is step backward - it started allowing
> to compile mkimage without required functionality, even on platforms
> which needs them, and effectively hides issue which is there.

Even if I was to accept your assertion that it hides a possible error on
platforms using kwbimage:

1) It does not *create* any errors for those platforms, and
2) It *fixes* possible errors for almost all other platforms.

>> I mean you could always propose
>> your own version of that missing piece, to improve the situation for the
>> boards you care about? And we should have this discussion there?
> 
> I think I have written details and some proposed solution in that email.

Yes, Pali, like I said in response to your comments on v2, you should
really be the one sending the patch here. I know next to nothing about
your platforms, and even giving me a list of SoC families does not tell
me where in the Kconfig you want the change to go. I am not interested
in continuing to play a guessing game (which so far I have been losing).

The TOOLS_LIBCRYPTO option has been around for several months now, so
there is no need to wait for my series to send your patch.

In fact, it was your change which broke the mkimage build with
TOOLS_LIBCRYPTO=n in the first place, so it is all the more
disappointing that, instead of fixing it, you are now trying to block
other people from fixing it.

> What is needed is to ensure that kwbimage is always compiled for
> platforms which require it (list of platform are in email 1 in previous
> email). This can be done as hard dependency like it is currently without
> this patch (ugly, does not show nice error message and enforce everybody
> to have crypto dependency, even platforms which do not need it). Other
> solution could be to define some select symbol which says that kwbimage
> is required and then kwbimage would be unconditionally compiled when
> this symbol is selected. And to make error message nice in build system,
> this symbol could depends on crypto symbol to ensure that all
> dependencies are met when trying to compile something which needs it.
> Another option could be to implement required cry

Re: [PATCH] ARM: amlogic: add sm efuse write support and cmd for read/write efuse

[Neil Armstrong]

On 05/10/2021 14:00, Vyacheslav Bocharov wrote:
> This adds support for amlogic efuse write and provides two subcommands
> of "sm" command: "efuseread" and "efusewrite" to read/write bytes between
> memory and efuse.
> 
> Signed-off-by: Vyacheslav Bocharov 
> ---
>  arch/arm/mach-meson/sm.c | 68 +++-
>  1 file changed, 67 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
> index 1a8f23cb1fa..fb437b94d14 100644
> --- a/arch/arm/mach-meson/sm.c
> +++ b/arch/arm/mach-meson/sm.c
> @@ -68,6 +68,26 @@ ssize_t meson_sm_read_efuse(uintptr_t offset, void 
> *buffer, size_t size)
>   return regs.regs[0];
>  }
>  
> +ssize_t meson_sm_write_efuse(uintptr_t offset, void *buffer, size_t size)
> +{
> + struct pt_regs regs;
> +
> + meson_init_shmem();
> +
> +memcpy(shmem_input, buffer, size);
> +
> + regs.regs[0] = FN_EFUSE_WRITE;
> + regs.regs[1] = offset;
> + regs.regs[2] = size;
> +
> + smc_call(®s);
> +
> + if (regs.regs[0] == 0)
> + return -1;
> +
> + return 0;
> +}
> +
>  #define SM_CHIP_ID_LENGTH119
>  #define SM_CHIP_ID_OFFSET4
>  #define SM_CHIP_ID_SIZE  12
> @@ -187,9 +207,53 @@ static int do_sm_reboot_reason(struct cmd_tbl *cmdtp, 
> int flag, int argc,
>   return CMD_RET_SUCCESS;
>  }
>  
> +static int do_efuse_read(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + ulong address, offset, size;
> + int ret;
> +
> + if (argc < 4)
> + return CMD_RET_USAGE;
> +
> +offset = simple_strtoul(argv[1], NULL, 0);
> +size = simple_strtoul(argv[2], NULL, 0);
> +
> +address = simple_strtoul(argv[3], NULL, 0);
> +
> + ret = meson_sm_read_efuse(offset, (void *)address, size);
> + if (ret)
> + return CMD_RET_FAILURE;
> +
> + return CMD_RET_SUCCESS;
> +}
> +
> +static int do_efuse_write(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + ulong address, offset, size;
> + int ret;
> +
> + if (argc < 4)
> + return CMD_RET_USAGE;
> +
> +offset = simple_strtoul(argv[1], NULL, 0);
> +size = simple_strtoul(argv[2], NULL, 0);
> +
> +address = simple_strtoul(argv[3], NULL, 0);
> +
> + ret = meson_sm_write_efuse(offset, (void *)address, size);
> + if (ret)
> + return CMD_RET_FAILURE;
> +
> + return CMD_RET_SUCCESS;
> +}
> +
>  static struct cmd_tbl cmd_sm_sub[] = {
>   U_BOOT_CMD_MKENT(serial, 2, 1, do_sm_serial, "", ""),
>   U_BOOT_CMD_MKENT(reboot_reason, 1, 1, do_sm_reboot_reason, "", ""),
> +U_BOOT_CMD_MKENT(efuseread, 4, 1, do_efuse_read, "", ""),
> +U_BOOT_CMD_MKENT(efusewrite, 4, 0, do_efuse_write, "", ""),

These should be aligned with tabs

>  };
>  
>  static int do_sm(struct cmd_tbl *cmdtp, int flag, int argc,
> @@ -216,5 +280,7 @@ U_BOOT_CMD(
>   sm, 5, 0, do_sm,
>   "Secure Monitor Control",
>   "serial  - read chip unique id to memory address\n"
> - "sm reboot_reason [name] - get reboot reason and store to to 
> environment"
> + "sm reboot_reason [name] - get reboot reason and store to to 
> environment\n"
> +"sm efuseread- read efuse to memory 
> address\n"
> +"sm efusewrite- write into efuse from 
> memory address"

Same here

>  );
> 

Applied to u-boot-amlogic while fixing indent

Thanks,
Neil

[PATCH v6 03/11] ARM: dts: imx8mm-verdin: prepare for dek blob encapsulation

[sbabic]

> From: Marcel Ziswiler 
> Prepare for DEK blob encapsulation support through "dek_blob" command.
> On ARMv8, u-boot runs in non-secure, thus cannot encapsulate a DEK blob
> for encrypted boot.
> The DEK blob is encapsulated by OP-TEE through a trusted application
> call. U-boot sends and receives the DEK and the DEK blob binaries
> through OP-TEE dynamic shared memory.
> To enable the DEK blob encapsulation, add to the defconfig:
> CONFIG_SECURE_BOOT=y
> CONFIG_FAT_WRITE=y
> CONFIG_CMD_DEKBLOB=y
> Taken from NXP's commit 56d2050f4028 ("imx8m: Add DEK blob encapsulation
> for imx8m").
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 7/9] board: phytec: phycore-imx8mm: Add SPI-NOR flash support

[sbabic]

> Adds SPI-NOR flash support to erase, read and write in bootloader.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 2/9] include: configs: phycore_imx8mm: Remove hard coded network settings

[sbabic]

> Remove ip address and server ip from board config as they should not
> be added hardcoded.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 07/11] verdin-imx8mm: clean-up include order

[sbabic]

> From: Marcel Ziswiler 
> Alphabetically order includes.
> While at it also update copyright year resp. period.
> Signed-off-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 8/9] configs: phycore-imx8mm_defconfig: Enable clk command

[sbabic]

> Enable clk command to dump clock tree.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 11/11] verdin-imx8mm: fix watchdog pinctrl issue

[sbabic]

> From: Marcel Ziswiler 
> Finally, found the root cause of the issue already once mentioned back
> here [2] which caused the following error message during boot:
> imx_wdt watchdog@3028:
>  pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
> Turns out while the watchdog node itself was already u-boot,dm-spl its
> pinctrl node was not which caused it to be unavailable at that early
> stage. Note that any and all other boards I checked also seem to be
> missing this. However, I can't judge whether or not they might indeed
> need a similar fix or not.
> [2] https://marc.info/?l=u-boot&m=161786572422973
> Fixes: commit d304e7ace3a6
>  ("ARM: imx8m: Fix reset in SPL on Toradex iMX8MM Verdin")
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 6/9] arm: dts: phycore-imx8mm: Fix property

[sbabic]

> Fix misspelled property "stdout-path".
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 1/9] board: phytec: phycore_imx8mm: Clean up spl

[sbabic]

> Remove not needed code in the spl board code.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 9/9] board: phytec: imx8mm-phycore: Switch to binman

[sbabic]

> Use binman for image creation.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 01/11] imx8m: clean-up kconfig indentation

[sbabic]

> From: Marcel Ziswiler 
> Replace spurious spaces with proper tabs.
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 4/9] include: configs: phycore-imx8mm: Do not use macro for address

[sbabic]

> Do not use size macros for addesses. So convert PHYS_SDRAM to address.
> No functional change.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 09/11] include/configs: apalis-imx8/verdin-imx8mm: rename kernel image variable

[sbabic]

> From: Oleksandr Suvorov 
> Variable "kernel_image" is used in boot.scr script only, that sets its
> own default value to the constant string @@KERNEL_IMAGETYPE@@ in case
> "kernel_image" is not set.
> The default name of the kernel image shipped with BSP 5.x is "Image.gz".
> Setting kernel_image="Image" as a pre-defined u-boot variable
> breaks booting systems with modern versions of boot.scr, whereas
> renaming it fixes booting with modern scripts and does not break working
> of earlier versions of boot.scr.
> While at it also update the copyright period, rather than hard-coding
> fdtfile default fdt_board to dev for the Verdin iMX8M Mini and fix its
> closing #endif comment.
> Signed-off-by: Oleksandr Suvorov 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 05/11] verdin-imx8mm: switch to use binman to pack images

[sbabic]

> From: Marcel Ziswiler 
> Use binman to pack images.
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Heiko Thiery 
> Reviewed-by: Fabio Estevam 
> Reviewed-by: Heiko Schocher 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 04/11] arm64: dts: imx8mm-verdin-u-boot.dtsi: alphabetically re-order

[sbabic]

> From: Marcel Ziswiler 
> Alphabetically re-order nodes and properties.
> Signed-off-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 3/9] include: configs: phycore-imx8mm: Remove not needed defines

[sbabic]

> Remove obsolet defines in phycore_imx8mm.h.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 02/11] verdin-imx8mm: fix ethernet

[sbabic]

> From: Marcel Ziswiler 
> Turns out Microship (formerly Micrel) meanwhile integrated proper
> support for the DLL setup on their KSZ9131. Unfortunately, this
> conflicts with our previous board code doing that.
> Fix this by getting rid of our board code and just relying on the
> generic implementation relying on rgmii-id being used as phy-mode.
> Fixes: commit c6df0e2ffdc4
>("net: phy: micrel: add support for DLL setup on ksz9131")
> Fixes: commit af2d3c91d877
>("ARM: dts: imx8mm-verdin: Set PHY mode to RGMII-ID")
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 08/11] verdin-imx8mm: drop support for v1.0 hardware

[sbabic]

> From: Max Krummenacher 
> We drop support for Verdin iMX8M Mini V1.0B.
> Related-to: ELB-3551
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 06/11] verdin-imx8mm: enable sleep_moci output

[sbabic]

> From: Max Krummenacher 
> This powers some peripherals on the carrier board e.g. the USB hub.
> Related-to: ELB-3206
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v6 10/11] verdin-imx8mm: use preboot for fdtfile evaluation

[sbabic]

> From: Igor Opaniuk 
> Enable and set preboot var with fdtfile evaluation.
> It will be checked and run immediately before starting the
> CONFIG_BOOTDELAY countdown and/or running the auto-boot command resp.
> entering interactive mode.
> This provides possibility to use different boot cmds in interactive mode
> without manual setting fdtfile value, as it it's already evaluated
> before entering interactive mode.
> Signed-off-by: Igor Opaniuk 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 5/9] arm: dts: phycore-imx8mm-u-boot: Add wdog pinctrl entry

[sbabic]

> Add missing pinctrl entry in spl.
> Signed-off-by: Teresa Remmet 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 1/1] arm64: zynqmp: allow overriding board name

[Liam Beguin]

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin 
---
 arch/arm/mach-zynqmp/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
index f7b08db35501..716c4d354f34 100644
--- a/arch/arm/mach-zynqmp/Kconfig
+++ b/arch/arm/mach-zynqmp/Kconfig
@@ -25,6 +25,7 @@ config SPL_SPI
default y if ZYNQ_QSPI
 
 config SYS_BOARD
+   string "Board name"
default "zynqmp"
 
 config SYS_VENDOR
-- 
2.32.0.452.g940fe202adcb

[PATCH] phy: cadence: phy-cadence-torrent: Change the name of subnode searched

[Aswath Govindraju]

Search for "phy" in the subnode names, to syncup with kernel.

Signed-off-by: Aswath Govindraju 
---
 drivers/phy/cadence/phy-cadence-torrent.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/cadence/phy-cadence-torrent.c 
b/drivers/phy/cadence/phy-cadence-torrent.c
index 141ece479fe5..ef924e7af508 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -616,8 +616,8 @@ static int cdns_torrent_phy_probe(struct udevice *dev)
 
/* Going through all the available subnodes or children*/
ofnode_for_each_subnode(child, dev_ofnode(dev)) {
-   /* PHY subnode name must be a 'link' */
-   if (!ofnode_name_eq(child, "link"))
+   /* PHY subnode name must be a 'phy' */
+   if (!ofnode_name_eq(child, "phy"))
continue;
cdns_phy->phys[node].lnk_rst =
devm_reset_bulk_get_by_node(dev, child);
-- 
2.17.1

[PATCH] usb: cdns3: cdns3-ti: Add compatible for AM64 SoC

[Aswath Govindraju]

Add new compatible for AM64 SoC.

Signed-off-by: Aswath Govindraju 
---
 drivers/usb/cdns3/cdns3-ti.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 43171678ee17..8958f0166bd5 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -180,6 +180,7 @@ static int cdns_ti_remove(struct udevice *dev)
 
 static const struct udevice_id cdns_ti_of_match[] = {
{ .compatible = "ti,j721e-usb", },
+   { .compatible = "ti,am64-usb", },
{},
 };
 
-- 
2.17.1

[PATCH 1/2] arm: dts: am642-sk: Add and Enable USB SuperSpeed Host Port in SPL

[Aswath Govindraju]

From: Kishon Vijay Abraham I 

Add and Enable USB SuperSpeed Host Port in SPL.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Aswath Govindraju 
---
 arch/arm/dts/k3-am642-r5-sk.dts  | 40 
 arch/arm/dts/k3-am642-sk-u-boot.dtsi | 33 +++
 2 files changed, 73 insertions(+)

diff --git a/arch/arm/dts/k3-am642-r5-sk.dts b/arch/arm/dts/k3-am642-r5-sk.dts
index 79eff8259f94..71fcf61ff9fb 100644
--- a/arch/arm/dts/k3-am642-r5-sk.dts
+++ b/arch/arm/dts/k3-am642-r5-sk.dts
@@ -5,6 +5,8 @@
 
 /dts-v1/;
 
+#include 
+#include 
 #include "k3-am642.dtsi"
 #include "k3-am64-sk-lp4-1333MTs.dtsi"
 #include "k3-am64-ddr.dtsi"
@@ -107,6 +109,13 @@
AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0)/* 
(C20) MMC1_SDWP */
>;
};
+
+   main_usb0_pins_default: main-usb0-pins-default {
+   u-boot,dm-spl;
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19) 
USB0_DRVVBUS */
+   >;
+   };
 };
 
 &dmsc {
@@ -142,4 +151,35 @@
pinctrl-0 = <&main_mmc1_pins_default>;
 };
 
+&serdes_ln_ctrl {
+   idle-states = ;
+};
+
+&serdes_wiz0 {
+   status = "okay";
+};
+
+&serdes0 {
+   serdes0_usb_link: link@0 {
+   reg = <0>;
+   cdns,num-lanes = <1>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   resets = <&serdes_wiz0 1>;
+   };
+};
+
+&usbss0 {
+   ti,vbus-divider;
+};
+
+&usb0 {
+   dr_mode = "host";
+   maximum-speed = "super-speed";
+   pinctrl-names = "default";
+   pinctrl-0 = <&main_usb0_pins_default>;
+   phys = <&serdes0_usb_link>;
+   phy-names = "cdns3,usb3-phy";
+};
+
 #include "k3-am642-sk-u-boot.dtsi"
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index efbcfb36e92a..95cf52c37fab 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -110,3 +110,36 @@
 &cpsw_port2 {
status = "disabled";
 };
+
+&main_usb0_pins_default {
+   u-boot,dm-spl;
+};
+
+&serdes_ln_ctrl {
+   u-boot,mux-autoprobe;
+};
+
+&usbss0 {
+   u-boot,dm-spl;
+};
+
+&usb0 {
+   dr_mode = "host";
+   u-boot,dm-spl;
+};
+
+&serdes_wiz0 {
+   u-boot,dm-spl;
+};
+
+&serdes0_usb_link {
+   u-boot,dm-spl;
+};
+
+&serdes0 {
+   u-boot,dm-spl;
+};
+
+&serdes_refclk {
+   u-boot,dm-spl;
+};
-- 
2.17.1

[PATCH 2/2] configs: am64x_evm_*_defconfig: Add configs to enable serdes for USB 3.0 support

[Aswath Govindraju]

Add configs to enable serdes for USB 3.0 support.

Signed-off-by: Aswath Govindraju 
---
 configs/am64x_evm_a53_defconfig | 15 +++
 configs/am64x_evm_r5_defconfig  | 13 +
 2 files changed, 28 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index d157403d84cb..388b3530d0b9 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_SKIP_LOWLEVEL_INIT=y
 CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x8000
@@ -34,6 +35,7 @@ CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
 CONFIG_SPL_DMA=y
+CONFIG_SPL_DM_GPIO=y
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_I2C=y
 CONFIG_SPL_DM_MAILBOX=y
@@ -70,10 +72,14 @@ CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_CLK_CCF=y
+CONFIG_SPL_CLK_CCF=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
@@ -84,6 +90,7 @@ CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_DM_GPIO=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
 CONFIG_SUPPORT_EMMC_BOOT=y
@@ -96,10 +103,18 @@ CONFIG_MMC_SDHCI_AM654=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
 CONFIG_PHY_TI_DP83867=y
 CONFIG_PHY_FIXED=y
 CONFIG_DM_ETH=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_TORRENT=y
+CONFIG_SPL_PHY_CADENCE_TORRENT=y
+CONFIG_PHY_J721E_WIZ=y
+CONFIG_SPL_PHY_J721E_WIZ=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index 5b04f18a635a..0f49b5d7cb6e 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_SIZE=0x2
 CONFIG_ENV_OFFSET=0x68
 CONFIG_SYS_MALLOC_LEN=0x200
 CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="k3-am642-r5-evm"
 CONFIG_SPL_TEXT_BASE=0x7000
@@ -76,10 +77,14 @@ CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_CLK_CCF=y
+CONFIG_SPL_CLK_CCF=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
@@ -97,6 +102,14 @@ CONFIG_MMC_SDHCI_AM654=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_SIERRA=y
+CONFIG_SPL_PHY_CADENCE_SIERRA=y
+CONFIG_PHY_CADENCE_TORRENT=y
+CONFIG_SPL_PHY_CADENCE_TORRENT=y
+CONFIG_PHY_J721E_WIZ=y
+CONFIG_SPL_PHY_J721E_WIZ=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 CONFIG_SPL_PINCTRL=y
-- 
2.17.1

[PATCH 0/2] AM64: Add support for USB

[Aswath Govindraju]

Add support for USB 3.0 TYPE A port on AM642 SK board

The following series of patches are dependent on,
- https://patchwork.ozlabs.org/project/uboot/list/?series=268093
- https://patchwork.ozlabs.org/project/uboot/list/?series=268092

Aswath Govindraju (1):
  configs: am64x_evm_*_defconfig: Add configs to enable serdes for USB
3.0 support

Kishon Vijay Abraham I (1):
  arm: dts: am642-sk: Add and Enable USB SuperSpeed Host Port in SPL

 arch/arm/dts/k3-am642-r5-sk.dts  | 40 
 arch/arm/dts/k3-am642-sk-u-boot.dtsi | 33 +++
 configs/am64x_evm_a53_defconfig  | 15 +++
 configs/am64x_evm_r5_defconfig   | 13 +
 4 files changed, 101 insertions(+)

-- 
2.17.1

Re: IMX8M OP-TEE

[Igor Opaniuk]

Hi Tim,

On Thu, Oct 14, 2021 at 10:03 PM Tim Harvey  wrote:
>
> On Mon, Oct 11, 2021 at 3:15 PM Tim Harvey  wrote:
> >
> > Greetings,
> >
> > Is anyone successfully booting U-Boot with OP-TEE support on the IMX8M?
> >
> > My understanding is that you need to add tee.bin to the images in the
> > FIT image and include it in loadables following the ATF.
> >
> > While this was done with arch/arm/mach-imx/mkimage_fit_atf.sh before
> > the switch to binman by simply having tee.bin in the U-Boot directory
> > and passing in TEE_LOAD_ADDR (or accepting the default of 0xfe00)
> > once you switch to binman it needs to be added for your board.
> >
> > Additionally in order to use OP-TEE from U-Boot (ie for dek_blob
> > command) you need to add a node with compatible=linaro,optee-tz as
> > well.
> >
> > I've done the following to add OP-TEE for imx8mm_venice:
> > diff --git a/configs/imx8mm_venice_defconfig 
> > b/configs/imx8mm_venice_defconfig
> > index d85827b588..85d2b20810 100644
> > -u-boot.dtsi
> > index e0fa9ff4bf..7a71b974e1 100644
> > --- a/arch/arm/dts/imx8mm-venice-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-venice-u-boot.dtsi
> > @@ -10,6 +10,13 @@
> > multiple-images;
> > };
> >
> > +   firmware {
> > +   optee {
> > +   compatible = "linaro,optee-tz";
> > +   method = "smc";
> > +   };
> > +   };
> > +
> > wdt-reboot {
> > compatible = "wdt-reboot";
> > wdt = <&wdog1>;
> > @@ -152,6 +159,16 @@
> > };
> > };
> >
> > +   tee {
> > +   description = "TEE firmware";
> > +   type = "firmware";
> > +   arch = "arm64";
> > +   compression = "none";
> > +   data = "tee.bin";
> > +   load = <0xbe00>;
> > +   entry = <0xbe00>;
> > +   };
> > +
> > @fdt-SEQ {
> > description = "NAME";
> > type = "flat_dt";
> > @@ -165,7 +182,7 @@
> > @config-SEQ {
> > description = "NAME";
> > firmware = "uboot";
> > -   loadables = "atf";
> > +   loadables = "atf", "tee";
> > fdt = "fdt-SEQ";
> > };
> > };
> >
> >
> > However, when I attempt to boot I hang when the ATF is run.
> >
> > Where does the TEE_LOAD_ADDR come from specifically? I would think
> > this needs to be defined when building tee and needs to match the load
> > address used in the FIT image. It appears that perhaps this is supped
> > to be DDR_BASE + DDR_SIZE - 32MIB but I'm not entirely sure.
> >
> > I'm currently using NXP's ATF (imx_5.4.3_2.0.0) and NXP's TEE
> > (imx_5.4.70_2.3.0) and would also like to understand if NXP's branches
> > are strictly required here and if so what the pros and cons of using
> > them are.
> >
> > Anyone using IMX8MM OP-TEE that could point me in the right direction?
> >
>
> Here's what I've learned so far via various responses, research and testing.
>
> There are multiple boot flows that can be used with OP-TEE:
> 1. SPL -> ATF -> OP-TEE -> U-boot -> LInux
This is the case for ARMv8: TF-A provides runtime service here as
Secure Monitor (running on EL3), arbitrating context switches between
Secure/Non-secure worlds. OP-TEE OS core is running on Secure EL1.

> 2. SPL -> OP-TEE -> U-boot -> Linux
This is the case for ARMv7, where there is only one Secure PL1,
so OP-TEE also fulfills the function of SM (arbitrating context
switches between NW/SW).

>
> I'm not really clear what the pros and cons of each are - can anyone
> shed some light on this?
>
> Method #1 is what I've found the most info on and have mostly gotten
> working so I will go over that here. As IMX8MM runs on Cortex-A Arm
> TrustZone is available and thus TF-A can be used.
>
> By the way, I'm a bit confused as to ATF vs TF-A. From what I can find:
> - ATF (Arm Trusted Firmware) is a Trusted Firmware reference
> implementation of secure world software for Armv7-A, Armv8-A, and
> Armv8-M architectures.
> - TF-A (Trusted Firmware-A) also appears to provide the same thing
> Are these the same? Which one is it that NXP uses for imx-atf [1]
It's the same product, which I guess was renamed to avoid confusion,
as ARM introduced Trusted Firmware M for M-cores.


>
> When OP-TEE is used with TF-A the TF-A gets invoked with the TEE as
> bl32 and main u-boot as bl33. Once it has d

[PATCH 1/2] doc: imx: psb: Fix PERSIST_SECONDARY_BOOT bit location in GPR10

[sbabic]

> The PERSIST_SECONDARY_BOOT is in GPR10 address 0x30390098, adjust the
> text which currently says it is in GPR0 while using the correct address
> of GPR10.
> Signed-off-by: Marek Vasut 
> Cc: Marcel Ziswiler 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Ye Li 
> Cc: uboot-imx 
> Reviewed-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH 2/2] doc: imx: psb: Add documentation for MX8MM behavior with Fast Boot fuse blown

[sbabic]

> On iMX8MM with Fast Boot fuse blown, the SIT and A-copy image are
> placed at different offset than on iMX8MM with Fast Boot fuse NOT
> blown. List both options and both offsets to avoid confusion.
> Signed-off-by: Marek Vasut 
> Cc: Marcel Ziswiler 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Ye Li 
> Cc: uboot-imx 
> Reviewed-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v2 2/5] toradex: configblock: fix interactive mode it handling

[sbabic]

> From: Denys Drozdov 
> Restore "Is the module an IT version? [y/N]" for "cfgblock create"
> interactive mode command, which was leading to invalid detection
> of 0051 Colibri iMX8DX 1GB WB module;
> Fixes: a5b5ad4d859b ("toradex: tdx-cfg-clock: add new i.mx 8m mini/plus skus")
> Related-to: ELB-3482
> Signed-off-by: Denys Drozdov 
> Signed-off-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v2 1/5] toradex: take over maintainership

[sbabic]

> From: Marcel Ziswiler 
> Also take over maintainership of remaining Toradex SoMs as Oleksandr
> has left our company.
> Signed-off-by: Marcel Ziswiler 
> CC: Oleksandr Suvorov 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH] colibri-imx6ull: fix setup of nand gpmi clock

[sbabic]

> NXP used to setup the gpmi clock root from gpmi_clk in early versions
> in their downstream BSP. [1]
> However on mainline the gpmi clock root was always setup from enfc
> since the beginning of the i.MX 6 series SoCs, which is still the same
> today. [2]
> NXP followed the mainline approach at some point and changed
> setup_gpmi_io_clk to setup gpmi clock root from enfc which left faulty
> code behind in our board file. [3]
> This commit follows the change of NXP as it improves the performance of
> the NAND from ~1.2 MiB/s to ~12 MiB/s. [3]
> This change was verified to work in recovery-mode and u-boot loaded
> from NAND on all four Colibri iMX6ULL SKUs from Toradex.
> The frequency used to read the NAND, measured on RE# (Read Enable):
> before this patch: 1.4 MHz
> after this patch:   22 MHz
> in Linux Kernel:50 MHz
> [1] 
> https://source.codeaurora.org/external/imx/uboot-imx/tree/arch/arm/cpu/armv7/mx6/clock.c?h=nxp/imx_v2016.03_4.1.15_2.0.0_ga#n62
> [2] commit 23608e23fd65 ("i.mx: add the initial support for freescale i.MX6Q 
> processor")
> [3] 
> https://source.codeaurora.org/external/imx/uboot-imx/commit/?id=7a82a19ceabfb04bbc1591a67c99751748781c7d
> Signed-off-by: Philippe Schenker 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v5] imx8mm-evk: Generate a single bootable flash.bin again

[sbabic]

> After the conversion to binman in commit 8996e6b7c6a1 ("imx8mm_evk: switch
> to use binman to pack images"), it is necessary to flash both flash.bin and
> u-boot.itb to get a bootable system. Prior to this commit, only flash.bin
> was needed.
> Such new requirement breaks existing distro mechanisms to generate the
> final binary because the extra u-boot.itb is now required.
> Generate a final flash.bin that can be used again as a single
> bootable binary to keep the original behavior.
> After this change the SPL binary is called spl.bin, which is a more
> descriptive name for its purpose, and can still be used standalone
> (for example, for secure boot purposes).
> Also update imx8mm_evk.rst to remove the u-boot.itb copy step.
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Frieder Schrempf 
> Reviewed-by: Heiko Schocher 
> Reviewed-by: Marcel Ziswiler 
> Reviewed-by: Heiko Thiery 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v2 4/5] colibri-imx6ull: imximage.cfg: integrate new 1GiB RAM variant

[sbabic]

> From: Philippe Schenker 
> Integrate new Toradex SKU 0062 Colibri iMX6ULL 1GB IT. This commit
> basically adjusts three parameters of the RAM settings:
> Increase density from 4Gb to 8Gb
> Increase ROW address from 15 to 16
> Increase tRFC (refresh command time) from 260 to 350
> This timing is valid for all Toradex Colibri iMX6ULL SKUs
> Related-to: ELB-4055, ELB-4057
> Signed-off-by: Philippe Schenker 
> Signed-off-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v2 5/5] colibri-imx6ull: add emmc variant

[sbabic]

> From: Max Krummenacher 
> Add code to build the eMMC variant of the Colibri iMX6ULL, i.e. the
> 'Colibri iMX6ULL 1GB' which has a eMMC instead of the raw NAND used
> on other SKUs.
> Related-to: ELB-4056, ELB-4057
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

[PATCH v2 3/5] toradex: tdx-cfg-block: add new i.mx 6ull and 8m plus skus

[sbabic]

> From: Marcel Ziswiler 
> Add new i.MX 6ULL and 8M Plus SKUs to ConfigBlock handling:
> 0062: Colibri iMX6ULL 1GB IT (eMMC)
> 0063: Verdin iMX8M Plus Quad 4GB IT
> 0064: Verdin iMX8M Plus Quad 2GB Wi-Fi / BT IT
> 0065: Verdin iMX8M Plus QuadLite 1GB IT
> 0066: Verdin iMX8M Plus Quad 8GB Wi-Fi / BT
> Signed-off-by: Marcel Ziswiler 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Re: [PATCH] arm: dts: sun50i-h6-orangepi-3: disable aldo2 regulator

[Maxim Karasev]

Hi. Thanks for explanation, I'm new to mailing lists, so I appreciate this.

Also I'm happy to hear that any work is done to address that issue.

>I was thinking about adding a TF-A build option that would skip regulator
>setup altogether, which would then become standard in some happy feature
>when U-Boot takes proper care of regulators.
>Maybe you can just disable this already in your TF-A build, to see if that
>fixes your issues?

It believe it should fix that exact issue, but in my situation (I'm a distro 
packager) such solutions (having a several atf versions) are unacceptable.

>In any case your patch below is unfortunately not a solution.

It's rather the most painless workaround in my case.

On October 13, 2021 7:25:36 PM GMT+03:00, Andre Przywara 
 wrote:
>On Tue,  7 Sep 2021 19:23:26 +0300
>Maxim Karasev  wrote:
>
>Hi Maxim,
>
>please add the respective maintainers in To: or CC:, as reported by
>scripts/get_maintainer.pl.
>Also please add at least "sunxi" or "allwinner" somewhere in the subject
>line, that helps the reduce the response time ;-)
>
>> Mainline TF-A has a broken behavior - it enables all used AXP regulator
>> outputs, without much reason.
>
>Without that code you could not use most peripherals powered by the PMIC
>in U-Boot, the PHY being the most prominent one.
>But yes, it's a long standing issue - at least for the OPi3, which seems
>to be one of the few boards really having an issue with that.
>And the real solution is to drop the regulator handling in TF-A, and use a
>DM compliant AXP driver in U-Boot. Samuel's recent work should have
>brought that a bit closer, but it's still quite some work ahead:
>https://oftc.irclog.whitequark.org/linux-sunxi/2021-10-11#30291278;
>
>> It breaks PHY on Orange Pi 3 and other boards, because they a specific
>> power-on sequence is required. aldo2 which is enabled by TF-A is just a
>> half of PHY's power and the other half that is untouched by TF-A must be
>> enabled simultaneously (even a small difference may cause a break-down).
>
>I wish OrangePi would have designed a bit less of a special snowflake
>here.
>
>> If not TF-A, kernel driver would do everything correctly.
>> 
>> However, some boards rely on this behavior, so it's impossible to get
>> rid of it.
>> 
>> TF-A recently started checking regulator status, and now it enables a
>> regulator only if it's status is "okay". Disabling regulator in U-Boot's
>> dts workarounds the problem.
>
>The problem is that there is no such thing as "U-Boot's dts". I always use
>that DT to pass it on to the kernel (via $fdtcontroladdr), and this is the
>designated way to use UEFI. And that is just one reason we don't accept DT
>hacks just in U-Boot.
>

>
>Cheers,
>Andre
>
>> ---
>>  arch/arm/dts/sun50i-h6-orangepi-3.dts | 4 
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/arch/arm/dts/sun50i-h6-orangepi-3.dts 
>> b/arch/arm/dts/sun50i-h6-orangepi-3.dts
>> index 7e83f6146f..9f91e4ec88 100644
>> --- a/arch/arm/dts/sun50i-h6-orangepi-3.dts
>> +++ b/arch/arm/dts/sun50i-h6-orangepi-3.dts
>> @@ -207,6 +207,10 @@
>>  regulator-min-microvolt = <330>;
>>  regulator-max-microvolt = <330>;
>>  regulator-name = "vcc33-audio-tv-ephy-mac";
>> +/* This regulator must be enabled by the kernel,
>> + * not by u-boot or TF-A, otherwise power-on
>> + * sequence will be wrong and PHY won't work */
>> +status = "disabled";
>>  };
>>  
>>  /* ALDO3 is shorted to CLDO1 */
>

[PATCH] ARM: imx8m: support env in fat and ext4

[Ricardo Salveti]

Change boot device logic to also allow environment stored in fat and in
ext4 when booting from SD or from eMMC.

As the boot device check for SD and for eMMC was depending on
ENV_IS_IN_MMC being defined, change the ifdef blocks at env_get_location
to use IS_ENABLED instead for all modes, returning NOWHERE when no valid
mode is found.

Signed-off-by: Ricardo Salveti 
---
 arch/arm/mach-imx/imx8m/soc.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index f2ddc834d4b..a3ce517a104 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1306,40 +1306,35 @@ void do_error(struct pt_regs *pt_regs, unsigned int esr)
 enum env_location env_get_location(enum env_operation op, int prio)
 {
enum boot_device dev = get_boot_device();
-   enum env_location env_loc = ENVL_UNKNOWN;
 
if (prio)
-   return env_loc;
+   return ENVL_UNKNOWN;
 
switch (dev) {
-#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
case QSPI_BOOT:
-   env_loc = ENVL_SPI_FLASH;
-   break;
-#endif
-#ifdef CONFIG_ENV_IS_IN_NAND
+   if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
+   return ENVL_SPI_FLASH;
+   return ENVL_NOWHERE;
case NAND_BOOT:
-   env_loc = ENVL_NAND;
-   break;
-#endif
-#ifdef CONFIG_ENV_IS_IN_MMC
+   if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND))
+   return ENVL_NAND;
+   return ENVL_NOWHERE;
case SD1_BOOT:
case SD2_BOOT:
case SD3_BOOT:
case MMC1_BOOT:
case MMC2_BOOT:
case MMC3_BOOT:
-   env_loc =  ENVL_MMC;
-   break;
-#endif
+   if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC))
+   return ENVL_MMC;
+   else if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
+   return ENVL_EXT4;
+   else if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT))
+   return ENVL_FAT;
+   return ENVL_NOWHERE;
default:
-#if defined(CONFIG_ENV_IS_NOWHERE)
-   env_loc = ENVL_NOWHERE;
-#endif
-   break;
+   return ENVL_NOWHERE;
}
-
-   return env_loc;
 }
 
 #ifndef ENV_IS_EMBEDDED
-- 
2.33.0

CRC32 endianess

[Wouter Joris]

Dear U-boot maintainers,

I'm working on an Xilinx Zynqmp project ( Checkout tag xilinx-v2019.1 
 ) (ARM 
Cortex A53 ) and I'm facing an endianess mix-up. I'm no C-code guru, so 
I hope you'll stick here with me for a while.


In this example I'm performing a random crc check, the result was placed 
into memory.


 * ZynqMP> crc32 0x8000 0x8002 0x7999
 * crc32 0x8000 0x8002
 * crc32 for 8000 ... 00010001 ==> 0c9cf37c

This is the result of the CRC read-back:

 * ZynqMP> md 7999 1
 * 7999: 7cf39c0c

Also the itest confirms something is wrong with the result.

 * ZynqMP> if itest *7999 == 7cf39c0c; then echo true; else echo false; fi
 * true

 * ZynqMP> if itest *7999 == 0c9cf37c; then echo true; else echo false; fi
 * false

I know there was an historic bug 
 
about the crc endianess describing this exact problem but this issue 
seems to be addressed in later releases, as far as I know.


Uboot Xilinx crc32.c L172 




Can you give any advice how to proceed?

Kind regards,

Wouter Joris


smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] arm64: relocate-rela: Add support for ld.lld

[Alistair Delva]

Cap end of relocations by the binary size.

Linkers like to insert some auxiliary sections between .rela.dyn and
.bss_start. These sections don't make their way to the final binary, but
reloc_rela still tries to relocate them, resulting in attempted read
past the end of file.

When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
default on arm64) breaks the build. After this patch, U-Boot can be
linked successfully with and without CONFIG_STATIC_RELA.

Originally-from: Elena Petrova 
Signed-off-by: Alistair Delva 
Cc: David Brazdil 
Cc: Scott Wood 
Cc: Tom Rini 
---
 tools/relocate-rela.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
index 6a524014b7..f0bc548617 100644
--- a/tools/relocate-rela.c
+++ b/tools/relocate-rela.c
@@ -63,7 +63,7 @@ int main(int argc, char **argv)
 {
FILE *f;
int i, num;
-   uint64_t rela_start, rela_end, text_base;
+   uint64_t rela_start, rela_end, text_base, file_size;
 
if (argc != 5) {
fprintf(stderr, "Statically apply ELF rela relocations\n");
@@ -87,8 +87,7 @@ int main(int argc, char **argv)
return 3;
}
 
-   if (rela_start > rela_end || rela_start < text_base ||
-   (rela_end - rela_start) % sizeof(Elf64_Rela)) {
+   if (rela_start > rela_end || rela_start < text_base) {
fprintf(stderr, "%s: bad rela bounds\n", argv[0]);
return 3;
}
@@ -96,6 +95,21 @@ int main(int argc, char **argv)
rela_start -= text_base;
rela_end -= text_base;
 
+   fseek(f, 0, SEEK_END);
+   file_size = ftell(f);
+   rewind(f);
+
+   if (rela_end > file_size) {
+   // Most likely compiler inserted some section that didn't get
+   // objcopy-ed into the final binary
+   rela_end = file_size;
+   }
+
+   if ((rela_end - rela_start) % sizeof(Elf64_Rela)) {
+   fprintf(stderr, "%s: rela size isn't a multiple of 
Elf64_Rela\n", argv[0]);
+   return 3;
+   }
+
num = (rela_end - rela_start) / sizeof(Elf64_Rela);
 
for (i = 0; i < num; i++) {
-- 
2.30.2

Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration

[Ferry Toth]

Hi,
Op 15-10-2021 om 19:11 schreef Andy Shevchenko:

There are two PCB designs in the wild which use the opposite
signaling for SD card detect. This makes U-Boot working in one case
and failing in the other. Quirk this out by disconnecting SD card
detect pin from the PCB by switching to mode 3.


Tested-by: Ferry Toth  @ Intel Edison-Arduino board


BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
Signed-off-by: Andy Shevchenko 
---
  arch/x86/dts/edison.dts | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 2c8cf6c07102..04e8a4e457c8 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -94,6 +94,7 @@
sdcard: mmc@ff3fa000 {
compatible = "intel,sdhci-tangier";
reg = <0xff3fa000 0x1000>;
+   cd-inverted;
};
  
  	pmu: power@ff00b000 {

@@ -131,6 +132,17 @@
compatible = "intel,pinctrl-tangier";
reg = <0xff0c 0x8000>;
  
+		/*

+* Disconnect SD card detect, so it won't affect the reality
+* on two different PCB designs where it's using the opposite
+* signaling: Edison/Arduino uses Active Low, while SparkFun
+* went with Active High.
+*/
+   sd_cd@0 {
+   pad-offset = <37>;
+   mode-func = <3>;
+   };
+
/*
 * Initial configuration came from the firmware.
 * Which quite likely has been used in the phones, where I2C #8,

Re: [PATCH] efi_loader: Fix link of EFI apps with ld.lld

[Heinrich Schuchardt]

On 10/20/21 11:31 PM, Alistair Delva wrote:

When compiling U-Boot with ld.lld as the linker, the helloworld EFI app
example fails to link:

LD  lib/efi_loader/helloworld_efi.so
ld.lld: error: section: .dynamic is not contiguous with other relro
 sections

LLD will always create RELRO program header regardless of target
emulation, whereas BFD may automatically disable it for unsupported
targets. Add -znorelro to disable it explicitly in all cases.

Signed-off-by: Alistair Delva 
Cc: Heinrich Schuchardt 
Cc: Nick Desaulniers 


Reviewed-by: Heinrich Schuchardt 


---
  scripts/Makefile.lib | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 07696e86bb..39f03398ed 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -403,7 +403,7 @@ $(obj)/%.efi: $(obj)/%_efi.so

  quiet_cmd_efi_ld = LD  $@
  cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \
-   -Bsymbolic -s $^ -o $@
+   -Bsymbolic -znorelro -s $^ -o $@

  EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS)

[PATCH v3] driver: spi: add bcm iproc qspi support.

[Roman Bacik]

From: Rayagonda Kokatanur 

IPROC qspi driver supports both BSPI and MSPI modes.

Signed-off-by: Rayagonda Kokatanur 
Signed-off-by: Bharat Gooty 
Acked-by: Rayagonda Kokatanur 

Signed-off-by: Roman Bacik 
---

Changes in v3:
- fix warning by including linux/delay.h
- change ofdata_to_platdata to of_to_plat
- change priv_auto_alloc_size to priv_auto

Changes in v2:
- remove include spi-nor.h
- define and use named BITs for writing register values
- remove bspi_set_4byte_mode() method

 drivers/spi/Kconfig  |   6 +
 drivers/spi/Makefile |   1 +
 drivers/spi/iproc_qspi.c | 713 +++
 drivers/spi/iproc_qspi.h |  20 ++
 4 files changed, 740 insertions(+)
 create mode 100644 drivers/spi/iproc_qspi.c
 create mode 100644 drivers/spi/iproc_qspi.h

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d07e9a28af82..e76fadef32dd 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -178,6 +178,12 @@ config ICH_SPI
  access the SPI NOR flash on platforms embedding this Intel
  ICH IP core.
 
+config IPROC_QSPI
+   bool "QSPI driver for BCM iProc QSPI Controller"
+   help
+ This selects the BCM iProc QSPI controller.
+ This driver support spi flash single, quad and memory reads.
+
 config KIRKWOOD_SPI
bool "Marvell Kirkwood SPI Driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d2f24bccefd3..869763187062 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
 obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
 obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o
 obj-$(CONFIG_ICH_SPI) +=  ich.o
+obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o
 obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
 obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c
new file mode 100644
index ..08881bf61764
--- /dev/null
+++ b/drivers/spi/iproc_qspi.c
@@ -0,0 +1,713 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020-2021 Broadcom
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "iproc_qspi.h"
+
+/* 175MHz */
+#define QSPI_AXI_CLK   17500
+#define QSPI_DEF_SCK_FREQ  5000
+#define QSPI_WAIT_TIMEOUT_MS   200U
+#define DWORD_ALIGNED(a)   (!(((ulong)(a)) & 3))
+
+/* Chip attributes */
+#define SPBR_MIN   8U
+#define SPBR_MAX   255U
+#define NUM_CDRAM  16U
+
+#define CDRAM_PCS0 2
+#define CDRAM_CONT BIT(7)
+#define CDRAM_BITS_EN  BIT(6)
+#define CDRAM_QUAD_MODEBIT(8)
+#define CDRAM_RBIT_INPUT   BIT(10)
+#define MSPI_SPE   BIT(6)
+#define MSPI_CONT_AFTER_CMDBIT(7)
+
+/* Register fields */
+#define MSPI_SPCR0_MSB_BITS_8  0x0020
+#define BSPI_RAF_CONTROL_START_MASK0x0001
+#define BSPI_RAF_STATUS_SESSION_BUSY_MASK  0x0001
+#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK0x0002
+#define BSPI_BITS_PER_PHASE_ADDR_MARK  0x0001
+#define BSPI_BITS_PER_CYCLE_DATA_SHIFT 0
+#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT 16
+#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT3
+#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT1
+#define BSPI_STRAP_OVERRIDE_SHIFT  0
+
+/* MSPI registers */
+#define MSPI_SPCR0_LSB_REG 0x000
+#define MSPI_SPCR0_MSB_REG 0x004
+#define MSPI_SPCR1_LSB_REG 0x008
+#define MSPI_SPCR1_MSB_REG 0x00c
+#define MSPI_NEWQP_REG 0x010
+#define MSPI_ENDQP_REG 0x014
+#define MSPI_SPCR2_REG 0x018
+#define MSPI_STATUS_REG0x020
+#define MSPI_CPTQP_REG 0x024
+#define MSPI_TXRAM_REG 0x040
+#define MSPI_RXRAM_REG 0x0c0
+#define MSPI_CDRAM_REG 0x140
+#define MSPI_WRITE_LOCK_REG0x180
+#define MSPI_DISABLE_FLUSH_GEN_REG 0x184
+
+/* BSPI registers */
+#define BSPI_REVISION_ID_REG   0x000
+#define BSPI_SCRATCH_REG   0x004
+#define BSPI_MAST_N_BOOT_CTRL_REG  0x008
+#define BSPI_BUSY_STATUS_REG   0x00c
+#define BSPI_INTR_STATUS_REG   0x010
+#define BSPI_B0_STATUS_REG 0x014
+#define BSPI_B0_CTRL_REG   0x018
+#define BSPI_B1_STATUS_REG 0x01c
+#define BSPI_B1_CTRL_REG   0x020
+#define BSPI_STRAP_OVERRIDE_CTRL_REG   0x024
+#d

Re: [PATCH] doc: Remove obsolete README.440-DDR-performance file

[Heinrich Schuchardt]

On 10/19/21 9:25 AM, Thomas Huth wrote:

The PPC 440 support has been removed in commit 98f705c9ce
("powerpc: remove 4xx support") already, so this file is
certainly not required anymore.

Signed-off-by: Thomas Huth 
Reviewed-by: Stefan Roese 
---
  doc/README.440-DDR-performance | 90 --


Shouldn't doc/README.nand-boot-ppc440 be removed too?

Best regards

Heinrich


  1 file changed, 90 deletions(-)
  delete mode 100644 doc/README.440-DDR-performance

diff --git a/doc/README.440-DDR-performance b/doc/README.440-DDR-performance
deleted file mode 100644
index 66b97bc9b5..00
--- a/doc/README.440-DDR-performance
+++ /dev/null
@@ -1,90 +0,0 @@
-AMCC suggested to set the PMU bit to 0 for best performace on the
-PPC440 DDR controller. The 440er common DDR setup files (sdram.c &
-spd_sdram.c) are changed accordingly. So all 440er boards using
-these setup routines will automatically receive this performance
-increase.
-
-Please see below some benchmarks done by AMCC to demonstrate this
-performance changes:
-
-
-
-SDRAM0_CFG0[PMU] = 1 (U-Boot default for Bamboo, Yosemite and Yellowstone)
-
-Stream benchmark results
--
-This system uses 8 bytes per DOUBLE PRECISION word.
--
-Array size = 200, Offset = 0
-Total memory required = 45.8 MB.
-Each test is run 10 times, but only
-the *best* time for each is used.
--
-Your clock granularity/precision appears to be 1 microseconds.
-Each test below will take on the order of 112345 microseconds.
-   (= 112345 clock ticks)
-Increase the size of the arrays if this shows that you are not getting
-at least 20 clock ticks per test.
--
-WARNING -- The above is only a rough guideline.
-For best results, please be sure you know the precision of your system
-timer.
--
-Function  Rate (MB/s)   RMS time Min time Max time
-Copy: 256.7683   0.1248   0.1246   0.1250
-Scale:246.0157   0.1302   0.1301   0.1302
-Add:  255.0316   0.1883   0.1882   0.1885
-Triad:253.1245   0.1897   0.1896   0.1899
-
-
-TTCP Benchmark Results
-ttcp-t: socket
-ttcp-t: connect
-ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000  tcp  ->
-localhost
-ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++
-ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57
-ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw
-
-
-SDRAM0_CFG0[PMU] = 0 (Suggested modification)
-Setting PMU = 0 provides a noticeable performance improvement *2% to
-5% improvement in memory performance.
-*Improves the Mbit/sec for TTCP benchmark by almost 76%.
-
-Stream benchmark results
--
-This system uses 8 bytes per DOUBLE PRECISION word.
--
-Array size = 200, Offset = 0
-Total memory required = 45.8 MB.
-Each test is run 10 times, but only
-the *best* time for each is used.
--
-Your clock granularity/precision appears to be 1 microseconds.
-Each test below will take on the order of 120066 microseconds.
-   (= 120066 clock ticks)
-Increase the size of the arrays if this shows that you are not getting
-at least 20 clock ticks per test.
--
-WARNING -- The above is only a rough guideline.
-For best results, please be sure you know the precision of your system
-timer.
--
-Function  Rate (MB/s)   RMS time Min time Max time
-Copy: 262.5167   0.1221   0.1219   0.1223
-Scale:258.4856   0.1238   0.1238   0.1240
-Add:  262.5404   0.1829   0.1828   0.1831
-Triad:266.8594   0.1800   0.1799   0.1802
-
-TTCP Benchmark Results
-ttcp-t: socket
-ttcp-t: connect
-ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000  tcp  ->
-localhost
-ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++
-ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89
-ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw
-
-
-2006-07-28, Stefan Roese 

Re: [PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config

[Simon Glass]

Hi Rob,

On Mon, 18 Oct 2021 at 16:26, Rob Herring  wrote:
>
> On Wed, Oct 13, 2021 at 11:33 AM Simon Glass  wrote:
> >
> > "
> > Hi Rob,
> >
> > On Tue, 12 Oct 2021 at 09:05, Rob Herring  wrote:
> > >
> > >  On Tue, Oct 12, 2021 at 8:41 AM Simon Glass  wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Mon, 4 Oct 2021 at 13:30, Rob Herring  wrote:
> > > > >
> > > > > On Sun, Oct 03, 2021 at 12:51:53PM -0600, Simon Glass wrote:
> > > > > > U-Boot makes use of the devicetree for its driver model. Devices 
> > > > > > are bound
> > > > > > based on the hardware description in the devicetree.
> > > > > >
> > > > > > Since U-Boot is not an operating system, it has no command line or 
> > > > > > user
> > > > > > space to provide configuration and policy information. This must be 
> > > > > > made
> > > > > > available in some other way.
> > > > > >
> > > > > > Therefore U-Boot uses devicetree for configuration and run-time 
> > > > > > control
> > > > > > and has done for approximately 9 years. This works extremely well 
> > > > > > in the
> > > > > > project and is very flexible. However the bindings have never been
> > > > > > incorporated in the devicetree bindings in the Linux tree. This 
> > > > > > could be
> > > > > > a good time to start this work as we try to create standard 
> > > > > > bindings for
> > > > > > communicating between firmware components.
> > > > > >
> > > > > > Add an initial binding for this node, covering just the config 
> > > > > > node, which
> > > > > > is the main requirement. It is similar in concept to the chosen 
> > > > > > node, but
> > > > > > used for passing information between firmware components, instead 
> > > > > > of from
> > > > > > firmware to operating system.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > > Please be kind in your review. Some words about why this is needed 
> > > > > > are
> > > > > > included in the description in config.yaml file.
> > > > > >
> > > > > > The last attempt to add just one property needed by U-Boot went 
> > > > > > into the
> > > > > > weeds 6 years ago, with what I see as confusion about the role of 
> > > > > > the
> > > > > > chosen node in devicetree[1].
> > > > > >
> > > > > > I am trying again in the hope of reaching resolution rather than 
> > > > > > just
> > > > > > going around in circles with the 'devicetree is a hardware 
> > > > > > description'
> > > > > > argument :-)
> > > > > >
> > > > > > Quoting from the introduction to latest devicetree spec[2]:
> > > > > >
> > > > > > >>>
> > > > > > To initialize and boot a computer system, various software 
> > > > > > components
> > > > > > interact. Firmware might perform low-level initialization of the 
> > > > > > system
> > > > > > hardware before passing control to software such as an operating 
> > > > > > system,
> > > > > > bootloader, or  hypervisor. Bootloaders and hypervisors can, in 
> > > > > > turn,
> > > > > > load and transfer control to operating systems. Standard, consistent
> > > > > > interfaces and conventions facilitate the interactions between these
> > > > > > software components. In this document the term boot program is used 
> > > > > > to
> > > > > > generically refer to a software component that initializes the 
> > > > > > system
> > > > > > state and executes another software component referred to as a 
> > > > > > client
> > > > > > program.
> > > > > > <<<
> > > > > >
> > > > > > This clearly envisages multiple software components in the firmware
> > > > > > domain and in fact that is the case today. They need some way to
> > > > > > communicate configuration data such as memory setup, runtime-feature
> > > > > > selection and developer conveniences. Devicetree seems ideal, at 
> > > > > > least for
> > > > > > components where the performance / memory requirements of 
> > > > > > devicetree are
> > > > > > affordable.
> > > > > >
> > > > > > I hope that the Linux community (which owns the devicetree 
> > > > > > bindings) finds
> > > > > > this initiative valuable and acceptable.
> > > > >
> > > > > Owns? I'm having a sale and can make you a good offer. Buy 1 binding,
> > > > > get 2000 free. :)
> > > >
> > > > Yes, it's the price of that first binding that surely puts everyone off.
> > > >
> > > > (sorry for sitting on this for a week, my spam filter doesn't like
> > > > some mailing lists and I'm working on it)
> > > >
> > > > >
> > > > > >
> > > > > > [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html
> > > > > > [2] 
> > > > > > https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
> > > > > >
> > > > > >  .../devicetree/bindings/u-boot/config.yaml| 137 
> > > > > > ++
> > > > > >  1 file changed, 137 insertions(+)
> > > > > >  create mode 100644 
> > > > > > Documentation/devicetree/bindings/u-boot/config.yaml
> > > > >
> > > > > Might as well put this into dt-schema rather than the kernel. But 
> > > > > might
> > > > > get more review here first

Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model

[Heinrich Schuchardt]

On 9/25/21 2:30 AM, Simon Glass wrote:

This code should never have been added as it builds a new feature on top
of legacy code. This has already been improved with the dependency on BLK.

Add a dependency on DM_ETH also, to avoid needing to deal with this old
code.

Boards which want EFI_LOADER should migrate to driver model first.

Note this patch is included to resolve the following build error:

lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
undeclared (first use in this function); did you mean
‘CONFIG_SYS_SRAM_BASE’?
   680 |   ulong base = CONFIG_SYS_TEXT_BASE;
   |^~~~
   |CONFIG_SYS_SRAM_BASE

Signed-off-by: Simon Glass 


Reviewed-by: Heinrich Schuchardt 

Re: IMX8M OP-TEE

[Tim Harvey]

 On Wed, Oct 20, 2021 at 9:47 AM Igor Opaniuk  wrote:
>
> Hi Tim,
>
> On Thu, Oct 14, 2021 at 10:03 PM Tim Harvey  wrote:
> >
> > On Mon, Oct 11, 2021 at 3:15 PM Tim Harvey  wrote:
> > >
> > > Greetings,
> > >
> > > Is anyone successfully booting U-Boot with OP-TEE support on the IMX8M?
> > >
> > > My understanding is that you need to add tee.bin to the images in the
> > > FIT image and include it in loadables following the ATF.
> > >
> > > While this was done with arch/arm/mach-imx/mkimage_fit_atf.sh before
> > > the switch to binman by simply having tee.bin in the U-Boot directory
> > > and passing in TEE_LOAD_ADDR (or accepting the default of 0xfe00)
> > > once you switch to binman it needs to be added for your board.
> > >
> > > Additionally in order to use OP-TEE from U-Boot (ie for dek_blob
> > > command) you need to add a node with compatible=linaro,optee-tz as
> > > well.
> > >
> > > I've done the following to add OP-TEE for imx8mm_venice:
> > > diff --git a/configs/imx8mm_venice_defconfig 
> > > b/configs/imx8mm_venice_defconfig
> > > index d85827b588..85d2b20810 100644
> > > -u-boot.dtsi
> > > index e0fa9ff4bf..7a71b974e1 100644
> > > --- a/arch/arm/dts/imx8mm-venice-u-boot.dtsi
> > > +++ b/arch/arm/dts/imx8mm-venice-u-boot.dtsi
> > > @@ -10,6 +10,13 @@
> > > multiple-images;
> > > };
> > >
> > > +   firmware {
> > > +   optee {
> > > +   compatible = "linaro,optee-tz";
> > > +   method = "smc";
> > > +   };
> > > +   };
> > > +
> > > wdt-reboot {
> > > compatible = "wdt-reboot";
> > > wdt = <&wdog1>;
> > > @@ -152,6 +159,16 @@
> > > };
> > > };
> > >
> > > +   tee {
> > > +   description = "TEE firmware";
> > > +   type = "firmware";
> > > +   arch = "arm64";
> > > +   compression = "none";
> > > +   data = "tee.bin";
> > > +   load = <0xbe00>;
> > > +   entry = <0xbe00>;
> > > +   };
> > > +
> > > @fdt-SEQ {
> > > description = "NAME";
> > > type = "flat_dt";
> > > @@ -165,7 +182,7 @@
> > > @config-SEQ {
> > > description = "NAME";
> > > firmware = "uboot";
> > > -   loadables = "atf";
> > > +   loadables = "atf", "tee";
> > > fdt = "fdt-SEQ";
> > > };
> > > };
> > >
> > >
> > > However, when I attempt to boot I hang when the ATF is run.
> > >
> > > Where does the TEE_LOAD_ADDR come from specifically? I would think
> > > this needs to be defined when building tee and needs to match the load
> > > address used in the FIT image. It appears that perhaps this is supped
> > > to be DDR_BASE + DDR_SIZE - 32MIB but I'm not entirely sure.
> > >
> > > I'm currently using NXP's ATF (imx_5.4.3_2.0.0) and NXP's TEE
> > > (imx_5.4.70_2.3.0) and would also like to understand if NXP's branches
> > > are strictly required here and if so what the pros and cons of using
> > > them are.
> > >
> > > Anyone using IMX8MM OP-TEE that could point me in the right direction?
> > >
> >
> > Here's what I've learned so far via various responses, research and testing.
> >
> > There are multiple boot flows that can be used with OP-TEE:
> > 1. SPL -> ATF -> OP-TEE -> U-boot -> LInux
> This is the case for ARMv8: TF-A provides runtime service here as
> Secure Monitor (running on EL3), arbitrating context switches between
> Secure/Non-secure worlds. OP-TEE OS core is running on Secure EL1.
>
> > 2. SPL -> OP-TEE -> U-boot -> Linux
> This is the case for ARMv7, where there is only one Secure PL1,
> so OP-TEE also fulfills the function of SM (arbitrating context
> switches between NW/SW).
>

Igor,

Thanks for the explanation - this makes much more sense now!

> >
> > I'm not really clear what the pros and cons of each are - can anyone
> > shed some light on this?
> >
> > Method #1 is what I've found the most info on and have mostly gotten
> > working so I will go over that here. As IMX8MM runs on Cortex-A Arm
> > TrustZone is available and thus TF-A can be used.
> >
> > By the way, I'm a bit confused as to ATF vs TF-A. From what I can find:
> > - ATF (Arm Trusted Firmware) is a Trusted Firmware reference
> > implementation of secure world software for Armv7-A, Armv8-A, and
> > Armv8-M architectures.
> > - TF-A (Trusted Firmware

Re: [PATCH v4 2/4] tools: mkimage: Add Allwinner TOC0 support

[Andre Przywara]

On Tue, 19 Oct 2021 21:44:52 -0500
Samuel Holland  wrote:

> Most Allwinner sunxi SoCs have separate boot ROMs in non-secure and
> secure mode. The "non-secure" or "normal" boot ROM (NBROM) uses the
> existing sunxi_egon image type. The secure boot ROM (SBROM) uses a
> completely different image type, known as TOC0.
> 
> A TOC0 image is composed of a header and two or more items. One item
> is the firmware binary. The others form a chain linking the firmware
> signature to the root-of-trust public key (ROTPK), which has its hash
> burned in the SoC's eFuses. Signatures are made using RSA-2048 + SHA256.
> 
> The pseudo-ASN.1 structure is manually assembled; this is done to work
> around bugs/quirks in the boot ROM, which vary between SoCs. This TOC0
> implementation has been verified to work with the A50, A64, H5, H6,
> and H616 SBROMs, and it may work with other SoCs.
> 
> Signed-off-by: Samuel Holland 

So without understanding anything from the crypto stuff (just knowing
that it's all slightly non-standard thanks to Allwinner), this looks
good to me. Tested on a Remix Mini PC (which ships with the secure fuse
burnt).
Thanks for the changes!

Acked-by: Andre Przywara 

Cheers,
Andre

> ---
> 
> (no changes since v3)
> 
> Changes in v3:
>  - Removed TOOLS_LIBCRYPTO selection for sunxi, since most boards
>do not need it
>  - Added __packed to all new "ABI" structs
>  - Added entry to MAINTAINERS for sunxi tools
> 
> Changes in v2:
>  - Moved certificate and key item structures out of sunxi_image.h
>  - Renamed "main" and "item" variables for clarity
>  - Improved error messages, and added a hint about key generation
>  - Added a comment explaining the purpose of the various key files
>  - Mentioned testing this code on A50 in the commit message
> 
>  MAINTAINERS   |   1 +
>  common/image.c|   1 +
>  include/image.h   |   1 +
>  include/sunxi_image.h |  37 ++
>  tools/Makefile|   3 +-
>  tools/sunxi_toc0.c| 907 ++
>  6 files changed, 949 insertions(+), 1 deletion(-)
>  create mode 100644 tools/sunxi_toc0.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 71f468c00a..0d62829f51 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -475,6 +475,7 @@ F:board/sunxi/
>  F:   drivers/clk/sunxi/
>  F:   drivers/phy/allwinner/
>  F:   drivers/video/sunxi/
> +F:   tools/sunxi*
>  
>  ARM TEGRA
>  M:   Tom Warren 
> diff --git a/common/image.c b/common/image.c
> index 3fa60b5827..d15b47ebbe 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -185,6 +185,7 @@ static const table_entry_t uimage_type[] = {
>   {   IH_TYPE_MTKIMAGE,   "mtk_image",   "MediaTek BootROM loadable 
> Image" },
>   {   IH_TYPE_COPRO, "copro", "Coprocessor Image"},
>   {   IH_TYPE_SUNXI_EGON, "sunxi_egon",  "Allwinner eGON Boot Image" 
> },
> + {   IH_TYPE_SUNXI_TOC0, "sunxi_toc0",  "Allwinner TOC0 Boot Image" 
> },
>   {   -1, "",   "",   },
>  };
>  
> diff --git a/include/image.h b/include/image.h
> index 34d13ada84..1547246ec8 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -227,6 +227,7 @@ enum {
>   IH_TYPE_IMX8IMAGE,  /* Freescale IMX8Boot Image */
>   IH_TYPE_COPRO,  /* Coprocessor Image for remoteproc*/
>   IH_TYPE_SUNXI_EGON, /* Allwinner eGON Boot Image */
> + IH_TYPE_SUNXI_TOC0, /* Allwinner TOC0 Boot Image */
>  
>   IH_TYPE_COUNT,  /* Number of image types */
>  };
> diff --git a/include/sunxi_image.h b/include/sunxi_image.h
> index 5b2055c0af..379ca9196e 100644
> --- a/include/sunxi_image.h
> +++ b/include/sunxi_image.h
> @@ -9,9 +9,13 @@
>   *
>   * Shared between mkimage and the SPL.
>   */
> +
>  #ifndef  SUNXI_IMAGE_H
>  #define  SUNXI_IMAGE_H
>  
> +#include 
> +#include 
> +
>  #define BOOT0_MAGIC  "eGON.BT0"
>  #define BROM_STAMP_VALUE 0x5f0a6c39
>  #define SPL_SIGNATURE"SPL" /* marks "sunxi" SPL header */
> @@ -79,4 +83,37 @@ struct boot_file_head {
>  /* Compile time check to assure proper alignment of structure */
>  typedef char boot_file_head_not_multiple_of_32[1 - 2*(sizeof(struct 
> boot_file_head) % 32)];
>  
> +struct __packed toc0_main_info {
> + uint8_t name[8];
> + __le32  magic;
> + __le32  checksum;
> + __le32  serial;
> + __le32  status;
> + __le32  num_items;
> + __le32  length;
> + uint8_t platform[4];
> + uint8_t reserved[8];
> + uint8_t end[4];
> +};
> +
> +#define TOC0_MAIN_INFO_NAME  "TOC0.GLH"
> +#define TOC0_MAIN_INFO_MAGIC 0x89119800
> +#define TOC0_MAIN_INFO_END   "MIE;"
> +
> +struct __packed toc0_item_info {
> + __le32  name;
> + __le32  offset;
> + __le32  length;
> + __le32  status;
> + __le32  type;
> + __le32  load_addr;
> + uint8_t reserved[4];
> + uint8_t end[4];
> +};
> +
> +#define TOC0_ITEM_