Re: qemu-kvm doesn't work with qemu-x86_64_defconfig

[Bin Meng]

+Simon

On Wed, Jul 28, 2021 at 11:22 PM Matwey V. Kornilov
 wrote:
>
> Hello,
>
> I am trying to build master for qemu-x86_64_defconfig. When I try to
> boot u-boot.rom as the following everything works fine:
>
> > qemu-system-x86_64 -nographic -bios u-boot.rom
>
> U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300)
> Trying to boot from SPI
> Jumping to 64-bit U-Boot: Note many features are missing
>
>
> U-Boot 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300)
>
> CPU:   QEMU Virtual CPU version 2.5+
> DRAM:  128 MiB
> Loading Environment from nowhere... OK
> Incorrect expansion ROM header signature 4daa
> Model: QEMU x86 (I440FX)
> Net:   e1000: 52:54:00:12:34:56
>eth0: e1000#0
> Hit any key to stop autoboot:  0
>
>
> When I try to enable KVM as the following, the boot process hangs:
>
> > qemu-system-x86_64 -enable-kvm -cpu host -nographic -bios u-boot.rom
>
> U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300)
> Trying to boot from SPI
> Jumping to 64-bit U-Boot: Note many features are missing
>
>
> What have I missed? Maybe KVM is just not supported?
>

Yep, at least I did not test u-boot with KVM.

Regards,
Bin

Re: [PATCH] board: ti: k2g: Program PadConfig_202 before locking RSTMUX8

[Lokesh Vutla]

On Mon, 26 Jul 2021 18:22:48 -0500, Suman Anna wrote:
> The PADCONFIG_202 register (0x02621328) is affected by the locking
> of the RSTMUX8 register (0x02620328), and so cannot be configured
> in kernel. This has been confirmed as a hardware bug and affects
> all K2G SoCs.
> 
> Setup the pinmux for this pin before locking the RSTMUX8 register
> to allow the ICSS1 PRU1 Ethernet PHY port to work properly. The
> workaround was added only for the K2G-ICE board to configure the
> pins needed for the PRUSS Ethernet usecase.
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/1] board: ti: k2g: Program PadConfig_202 before locking RSTMUX8
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a6c64d255e
 
--
Thanks and Regards,
Lokesh

Re: [PATCH] arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-mode

[Lokesh Vutla]

On Mon, 26 Jul 2021 11:22:13 -0500, Suman Anna wrote:
> The default U-Boot environment variables and design are all set up to
> have the MCU R5FSS cluster to be in Split-mode. This is the setting
> in v2021.01 U-Boot and the dt nodes are synched with the kernel binding
> property names in commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to
> upstreamed kernel DT property names") merged in v2021.04-rc2.
> 
> The mode for the cluster got switched back to LockStep mode by mistake
> in commit e49787634312 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts
> into U-Boot") also in v2021.04-rc2. This throws the following warning
> messages when early-booting the cores using default env variables,
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/1] arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-mode
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/31b3d7a018
 
--
Thanks and Regards,
Lokesh

Re: [PATCH 0/5] Cleanup MAIN R5F boot from R5 SPL

[Lokesh Vutla]

On Mon, 26 Jul 2021 16:13:06 -0500, Suman Anna wrote:
> The following series cleans up the code related to booting of Main
> R5FSS0 Core0 from R5 SPL, and moves it to A72 U-Boot on J721E SoCs.
> This is no longer supported after the R5 SPL re-architecture that
> splits the System Firmware functionality onto two separate processors.
> This functionality has been merged post v2021.07 tag towards v2021.10-rc1.
> The Main R5FSS0 Core0 is already being booted on A72 U-Boot on J7200
> SoCs, the other SoC family that follows this split system firmware
> architecture.
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/5] arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-Boot
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/05e858aefe
[2/5] arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPL
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/536f633d8a
[3/5] arm: mach-k3: Cleanup common start_non_linux_remote_cores()
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/ea985f6d92
[4/5] arm: dts: k3-j721e-r5: Remove MAIN R5FSS0 cluster from SPL
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/24f3fb6547
[5/5] configs: j721e_evm_r5: Disable K3 R5F remoteproc
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/bcad620f68
 
--
Thanks and Regards,
Lokesh

Re: [PATCH v2 0/6] AM64: Add support for higher speed modes and boot mode in eMMC

[Lokesh Vutla]

On Mon, 26 Jul 2021 20:58:01 +0530, Aswath Govindraju wrote:
> The following series of patches add support for,
> - HS200/HS400 speed modes
> - eMMC boot mode
> - gpt and FDT library overlay
> 
> This series of patches,
> - dependent on
>   https://patchwork.ozlabs.org/project/uboot/list/?series=237442
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/6] arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() 
to spl_mmc_boot_mode()
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2140d6b0ff
[2/6] arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias 
index 1 for main_sdhci1 node
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0817dd5432
[3/6] configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a3d58069c4
[4/6] configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and 
CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in 
eMMC and FAT write.
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/acbda111b2
[5/6] configs: am64x_evm_*_defconfig: Enable configs to support eMMC boot
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/da6a7206be
[6/6] configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT 
library overlay
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f572129b13
 
--
Thanks and Regards,
Lokesh

Re: [PATCH v5 00/20] TI/Cadence: Add Sierra/Torrent SERDES driver

[Lokesh Vutla]

On Wed, 21 Jul 2021 21:28:29 +0530, Kishon Vijay Abraham I wrote:
> Patch series adds Sierra and Torrent SERDES driver for the SERDES
> used in TI's K3 platforms. This SERDES is used by USB3, PCIe and
> Ethernet. This series is mostly an adaptation of drivers added in
> upstream Linux kernel.
> 
> Changes from v4:
> 1) Dropped `[PATCH v4 01/21] drivers: reset: Add devm_to_reset() to
> return dummy "struct reset_ctl"` and will be worked independently of
> this series. This was mainly introduced for handling optional reset
> which is not mandatory for both Sierra and Torrent.
> 2) Fixed sectionauthor name for j721e_evm.rst
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[01/20] dm: core: Add helper to compare node names
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/77cbaf8837
[02/20] dm: test: Add test case to check node name ignoring unit address
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9f6ae6dec2
[03/20] dt-bindings: phy: Add definitions for additional phy types
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/4f2c79e42c
[04/20] dt-bindings: phy: Add defines for AM64 SERDES Wrapper
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2b6b37032c
[05/20] dt-bindings: phy: cadence-torrent: Add defines for refclk driver
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0b5ea853be
[06/20] dt-bindings: ti-serdes-mux: Add defines for AM64 SoC
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2b0f7dee5f
[07/20] phy: cadence: Add driver for Sierra PHY
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/39b823381d
[08/20] phy: cadence: Add driver for Torrent SERDES
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/193c735162
[09/20] phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/1a83f9931e
[10/20] board: ti: j721e: Add support for probing and configuring Torrent 
serdes on J7200
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/6cfabddc3b
[11/20] ARM: dts: k3-j721e: Add support for USB3 in USB0 instance
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/ad256cc894
[12/20] arm: dts: k3-j7200-main: Add DT node for torrent serdes
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/6c4be8eb7e
[13/20] arm: dts: k3-j7200-common-proc-board: Enable SERDES DT
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cbea79867e
[14/20] arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for 
torrent serdes
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/08189ffd15
[15/20] configs: j721e_evm_a72_defconfig: Enable the drivers required for the 
USB3 support
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a9ed736cfa
[16/20] configs: j7200_evm_a72_defconfig: Add config for torrent serdes and 
common clock framework
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0e64ecd703
[17/20] env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in 
J7200 EVM
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/15f4193fff
[18/20] configs: j7200_evm_a72: Add CONFIG_PREBOOT to configure ethernet PHY
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/8fa3286408
[19/20] doc: board: Move j721e document to doc/board/ti/ directory
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/8baeeecbe3
[20/20] doc: board: j721e_evm: Add documentation for firmware loading
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/4689aabbe4
 
--
Thanks and Regards,
Lokesh

Re: [PATCH] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode

[Lokesh Vutla]

On Mon, 5 Apr 2021 20:14:28 +0530, Aswath Govindraju wrote:
> Enable HS400 speed mode by writing to HOST_CONTROL2 register.
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/1] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/bda47bef7c
 
--
Thanks and Regards,
Lokesh

Re: [PATCH] configs: am64x_evm_r5_defconfig: Fix CONFIG_SPL_TEXT_BASE to 0x70000000

[Lokesh Vutla]

On Mon, 26 Jul 2021 20:28:39 +0530, Aswath Govindraju wrote:
> CONFIG_SPL_TEXT_BASE was set to 0x7000 in the commit,
> "26f32c32b250 configs: am64x_evm_*_defconfig: Rearrange the components in
> SRAM to satisfy the limitations for USB DFU boot mode". This change seems
> to have been dropped during a merge commit.
> 
> Therefore, fix this by setting CONFIG_SPL_TEXT_BASE to 0x7000.
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/1] configs: am64x_evm_r5_defconfig: Fix CONFIG_SPL_TEXT_BASE to 0x7000
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/159c901c60
 
--
Thanks and Regards,
Lokesh

Re: [PATCH 0/6] AM64: Add support for higher speed modes and boot mode in eMMC

[Lokesh Vutla]

On Thu, 3 Jun 2021 14:34:22 +0530, Aswath Govindraju wrote:
> The following series of patches add support for,
> - HS200/HS400 speed modes
> - eMMC boot mode
> - gpt and FDT library overlay
> 
> This series of patches,
> - dependent on
>   https://patchwork.ozlabs.org/project/uboot/list/?series=237442
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/6] arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() 
to spl_mmc_boot_mode()
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2140d6b0ff
[2/6] arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias 
index 1 for main_sdhci1 node
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0817dd5432
[3/6] configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a3d58069c4
[4/6] configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and 
CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in 
eMMC and FAT write.
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/acbda111b2
[5/6] configs: am64x_evm_a53_defconfig/am64x_evm_r5_defconfig: Enable configs 
to support eMMC boot
  (no commit info)
[6/6] configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT 
library overlay
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f572129b13
 
--
Thanks and Regards,
Lokesh

Re: [PATCH 0/3] J7200: Add support for HS400 speed mode

[Lokesh Vutla]

On Tue, 25 May 2021 15:08:22 +0530, Aswath Govindraju wrote:
> The following series of patches add support for HS400 speed mode on J7200
> SoC.
> 
> For HS400 support to work, the following series of patches depend on,
> https://patchwork.ozlabs.org/project/uboot/patch/20210405144428.12159-1-a-govindr...@ti.com/
> 
> Aswath Govindraju (3):
>   mmc: sdhci_am654: Read ti,strobe-sel property from device tree
>   arm: dts: k3-j7200-main: Add support for HS400 and update delay select
> values for MMCSD subsystems
>   configs: j7200_evm_*_defconfig: Enable configs for HS400 support
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/3] mmc: sdhci_am654: Read ti, strobe-sel property from device tree
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/46077ef251
[2/3] arm: dts: k3-j7200-main: Add support for HS400 and update delay select 
values for MMCSD subsystems
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/455f9dddc8
[3/3] configs: j7200_evm_*_defconfig: Enable configs for HS400 support
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f490d359d7
 
--
Thanks and Regards,
Lokesh

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Jonathan Gray]

On Wed, Jul 28, 2021 at 09:04:33PM +0300, Artem Panfilov wrote:
> Fix LibreSSL compilation for versions before v2.7.0.

Why 2.7.0?  I had to disable CONFIG_FIT_SIGNATURE to get the qemu
targets to build on OpenBSD-current (3.4.0) as there is no
BN_bn2binpad().  2.7.0 is also over three years old at this point.

> 
> Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is enabled:
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx':
> ecdsa-libcrypto.c:(.text+0x94): undefined reference to
> `OPENSSL_init_ssl'
> ecdsa-libcrypto.c:(.text+0x148): undefined reference to
> `EC_GROUP_order_bits'
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function
> `ecdsa_check_signature.isra.0':
> ecdsa-libcrypto.c:(.text+0x32c): undefined reference to `ECDSA_SIG_set0'
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign':
> ecdsa-libcrypto.c:(.text+0x42c): undefined reference to `ECDSA_SIG_get0'
> ecdsa-libcrypto.c:(.text+0x443): undefined reference to `BN_bn2binpad'
> ecdsa-libcrypto.c:(.text+0x455): undefined reference to `BN_bn2binpad'
> tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_add_verify_data':
> ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to
> `EC_GROUP_order_bits'
> ecdsa-libcrypto.c:(.text+0x642): undefined reference to
> `EC_POINT_get_affine_coordinates'
> 
> Signed-off-by: Artem Panfilov 
> ---
>  lib/ecdsa/ecdsa-libcrypto.c | 80 -
>  1 file changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ecdsa/ecdsa-libcrypto.c b/lib/ecdsa/ecdsa-libcrypto.c
> index 1757a14562..50aa093acd 100644
> --- a/lib/ecdsa/ecdsa-libcrypto.c
> +++ b/lib/ecdsa/ecdsa-libcrypto.c
> @@ -24,6 +24,70 @@
>  #include 
>  #include 
>  
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> + (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x0207fL)
> +#include 
> +
> +static int EC_GROUP_order_bits(const EC_GROUP *group)
> +{
> + int ret = 0;
> + BIGNUM *order;
> +
> + if (!group)
> + return ret;
> +
> + order = BN_new();
> +
> + if (!order) {
> + ERR_clear_error();
> + return ret;
> + }
> +
> + if (!EC_GROUP_get_order(group, order, NULL)) {
> + ERR_clear_error();
> + BN_free(order);
> + return ret;
> + }
> +
> + ret = BN_num_bits(order);
> + BN_free(order);
> + return ret;
> +}
> +
> +static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM **pr, const 
> BIGNUM **ps)
> +{
> + if (pr != NULL)
> + *pr = sig->r;
> + if (ps != NULL)
> + *ps = sig->s;
> +}
> +
> +static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s)
> +{
> + if (r == NULL || s == NULL)
> + return 0;
> + BN_clear_free(sig->r);
> + BN_clear_free(sig->s);
> + sig->r = r;
> + sig->s = s;
> + return 1;
> +}
> +
> +int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen)
> +{
> + int n = BN_num_bytes(a);
> +
> + if (n < 0 || n > tolen)
> + return -1;
> +
> + memset(to, 0, tolen - n);
> + if (BN_bn2bin(a, to + tolen - n) < 0)
> + return -1;
> +
> + return tolen;
> +}
> +#endif
> +
>  /* Image signing context for openssl-libcrypto */
>  struct signer {
>   EVP_PKEY *evp_key;  /* Pointer to EVP_PKEY object */
> @@ -34,9 +98,18 @@ struct signer {
>  
>  static int alloc_ctx(struct signer *ctx, const struct image_sign_info *info)
>  {
> + int ret = 0;
> +
>   memset(ctx, 0, sizeof(*ctx));
>  
> - if (!OPENSSL_init_ssl(0, NULL)) {
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
> + ret = SSL_library_init();
> +#else
> + ret = OPENSSL_init_ssl(0, NULL);
> +#endif
> +
> + if (!ret) {
>   fprintf(stderr, "Failure to init SSL library\n");
>   return -1;
>   }
> @@ -285,7 +358,12 @@ static int do_add(struct signer *ctx, void *fdt, const 
> char *key_node_name)
>   x = BN_new();
>   y = BN_new();
>   point = EC_KEY_get0_public_key(ctx->ecdsa_key);
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
> +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
> + EC_POINT_get_affine_coordinates_GFp(group, point, x, y, NULL);
> +#else
>   EC_POINT_get_affine_coordinates(group, point, x, y, NULL);
> +#endif
>  
>   ret = fdt_setprop_string(fdt, key_node, "ecdsa,curve", curve_name);
>   if (ret < 0)
> -- 
> 2.25.1
> 
> 

[PATCH] lib: rsa: Extract public key from private key if keyfile argument is used

[Donald Chan]

If the 'keyfile' (-G) argument is used, there is little value to require
'keydir' (-k) argument since the public key can also be extracted from the
private key itself.

Signed-off-by: Donald Chan 
---
 lib/rsa/rsa-sign.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index f4ed11e74a..f70f352311 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -49,16 +49,16 @@ static int rsa_err(const char *msg)
 }
 
 /**
- * rsa_pem_get_pub_key() - read a public key from a .crt file
+ * rsa_pem_get_pub_key() - read a public key from a private key file or .crt 
file
  *
- * @keydir:Directory containins the key
- * @name   Name of key file (will have a .crt extension)
+ * @keydir:Directory containing the key, can be NULL
+ * @name   Name of key file (will apply a .crt extension if keydir is not 
NULL)
  * @evpp   Returns EVP_PKEY object, or NULL on failure
  * @return 0 if ok, -ve on error (in which case *evpp will be set to NULL)
  */
 static int rsa_pem_get_pub_key(const char *keydir, const char *name, EVP_PKEY 
**evpp)
 {
-   char path[1024];
+   char path[1024] = {0};
EVP_PKEY *key = NULL;
X509 *cert;
FILE *f;
@@ -68,7 +68,10 @@ static int rsa_pem_get_pub_key(const char *keydir, const 
char *name, EVP_PKEY **
return -EINVAL;
 
*evpp = NULL;
-   snprintf(path, sizeof(path), "%s/%s.crt", keydir, name);
+   if (keydir && name)
+   snprintf(path, sizeof(path), "%s/%s.crt", keydir, name);
+   else if (name)
+   snprintf(path, sizeof(path), "%s", name);
f = fopen(path, "r");
if (!f) {
fprintf(stderr, "Couldn't open RSA certificate: '%s': %s\n",
@@ -76,7 +79,13 @@ static int rsa_pem_get_pub_key(const char *keydir, const 
char *name, EVP_PKEY **
return -EACCES;
}
 
-   /* Read the certificate */
+   /* See if it contains a PEM private key? */
+   if (PEM_read_PrivateKey(f, evpp, NULL, path)) {
+   fclose(f);
+   return 0;
+   }
+
+   /* Not a PEM private key, read the certificate */
cert = NULL;
if (!PEM_read_X509(f, , NULL, NULL)) {
rsa_err("Couldn't read certificate");
@@ -672,7 +681,12 @@ int rsa_add_verify_data(struct image_sign_info *info, void 
*keydest)
if (ret)
return ret;
}
-   ret = rsa_get_pub_key(info->keydir, info->keyname, e, );
+   if (info->keydir && info->keyname)
+   ret = rsa_get_pub_key(info->keydir, info->keyname, e, );
+   else if (info->keyfile)
+   ret = rsa_get_pub_key(NULL, info->keyfile, e, );
+   else
+   ret = -EINVAL;
if (ret)
goto err_get_pub_key;
 #if OPENSSL_VERSION_NUMBER < 0x1010L || \
-- 
2.16.6

Re: [PATCH 2/2] x86: crownbay: Disable CONFIG_SPI_FLASH_SMART_HWCAPS

[Simon Glass]

On Wed, 28 Jul 2021 at 04:29, Bin Meng  wrote:
>
> Since commit 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
> SPI flash on Intel Crown Bay board does not work anymore.
>
> Disable CONFIG_SPI_FLASH_SMART_HWCAPS until a proper fix is made to
> the spi-nor core.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/crownbay_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Simon Glass]

Hi,

On Wed, 28 Jul 2021 at 17:55, Tom Rini  wrote:
>
> On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> >
> >
> > On 7/27/21 12:07 AM, Tom Rini wrote:
> > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > >
> > > > This feature should never have been made available when driver model
> > > > or devicetree are disabled. Add these as conditions, so that we don't
> > > > create even more barriers to migration.
> > > >
> > > > Add a note about the substantial size increment associated with this
> > > > option.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL
> > > > - Note the approximate size of this feature in the help
> > > >
> > > >   lib/efi_loader/Kconfig | 4 +++-
> > > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > index 6242caceb7f..466abfed300 100644
> > > > --- a/lib/efi_loader/Kconfig
> > > > +++ b/lib/efi_loader/Kconfig
> > > > @@ -1,6 +1,6 @@
> > > >   config EFI_LOADER
> > > >   bool "Support running UEFI applications"
> > > > - depends on OF_LIBFDT && ( \
> > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> >
> > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid
> > of this symbol?
>
> No, but I did send out a message about that today as we're very close.
> Much closer than I had expected us to be.

Note we will still have SPL_DM, I think.

>
> > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM?
>
> Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
> https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
> so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and sniper.
>
> > Why are these separate symbols? Isn't this symbol to be eliminated, too?
>
> Simon?

If we do eliminate DM it will be in a separate series. Like Tom I am
pleasantly surprised at how close we are.

But please let's consider patches on their merits. It is fine to reply
with a wishlist but even better to reply with a follow-up patch.

Somewhat related, I think we need to create a separate symbol which
means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing.

Also I think we should push of-platdata, since otherwise we're going
to hit the same problem of migrating SPL boards to DM one day.

>
> > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate
> > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends
> > on CONFIG_DM) would make more sense to me. But only in a patch
> > eliminating the non-BLK code.
>
> I just know that off-hand, partition + disk + block has some corner
> case, but maybe that corner case is unintentional in terms of usage
> today.
>
> > > >   ARM && (SYS_CPU = arm1136 || \
> > > >   SYS_CPU = arm1176 || \
> > > >   SYS_CPU = armv7   || \
> > > > @@ -25,6 +25,8 @@ config EFI_LOADER
> > > > will expose the UEFI API to a loaded application, enabling 
> > > > it to
> > > > reuse U-Boot's device drivers.
> > > >
> > > > +   For ARM 32-bit, this adds about 90KB to the size of U-Boot.
> > > > +
> >
> > There is no unit ISO prefix K. Do you mean KiB?
> >
> > 90 KiB may be the value today. Will you update it regularly? Otherwise
> > don't put a number here.
> >
> > I can't see that the effect on size is truly architecture specific. Why
> > do you refer to 32bit ARM?
> >
> > Such a comment would better fit into a documentation chapter on
> > downsizing U-Boot.
>
> Yes, we should probably drop that specific note.

>From my POV I really like these notes in Kconfig. They appear in a few
places and provide people with rough guidance. I'd like to see more of
them. I don't know how we can keep them up-to-date, although I'd argue
that they should stay constant, if we are holding to our no-bloat
ideal.

Perhaps the problem here is that EFI_LOADER is quite monolithic and
still under development, so the size is TBD. On that basic I'm fine to
drop it.

Regards,
Simon

Re: [PATCH 2/2] x86: dts: Define a default TSC timer frequency

[Simon Glass]

On Tue, 27 Jul 2021 at 22:00, Bin Meng  wrote:
>
> If for some reason, TSC timer frequency cannot be determined from
> hardware, nor is it specified in the device tree, U-Boot will panic
> resulting in endless reset during boot.
>
> Let's define a default TSC timer frequency using the Kconfig value
> CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
> /include/ otherwise the macro is not pre-processed).
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts| 2 +-
>  arch/x86/dts/baytrail_som-db5800-som-6867.dts | 2 +-
>  arch/x86/dts/cherryhill.dts   | 2 +-
>  arch/x86/dts/chromebook_coral.dts | 3 ++-
>  arch/x86/dts/chromebook_link.dts  | 2 +-
>  arch/x86/dts/chromebook_samus.dts | 2 +-
>  arch/x86/dts/chromebox_panther.dts| 2 +-
>  arch/x86/dts/conga-qeval20-qa3-e3845.dts  | 2 +-
>  arch/x86/dts/coreboot.dts | 7 ++-
>  arch/x86/dts/cougarcanyon2.dts| 2 +-
>  arch/x86/dts/crownbay.dts | 2 +-
>  arch/x86/dts/edison.dts   | 2 +-
>  arch/x86/dts/efi-x86_app.dts  | 7 ++-
>  arch/x86/dts/efi-x86_payload.dts  | 7 ++-
>  arch/x86/dts/galileo.dts  | 7 ++-
>  arch/x86/dts/minnowmax.dts| 2 +-
>  arch/x86/dts/qemu-x86_i440fx.dts  | 6 +-
>  arch/x86/dts/qemu-x86_q35.dts | 6 +-
>  arch/x86/dts/slimbootloader.dts   | 2 +-
>  arch/x86/dts/tsc_timer.dtsi   | 1 +
>  20 files changed, 25 insertions(+), 43 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 1/2] spi: ich: Limit slave->max_read_size

[Simon Glass]

On Wed, 28 Jul 2021 at 04:29, Bin Meng  wrote:
>
> Since commit 43c145b8b3ee ("spi: ich: Correct max-size bug in 
> ich_spi_adjust_size()")
> (in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
> in software sequencer mode.
>
> ICH controller can only transfer a small number of bytes at once.
> Before commit 43c145b8b3ee, the logic happens to make sure data.nbytes
> is limited to slave->max_write_size but after commit 43c145b8b3ee
> data.nbytes is no longer limited because slave->max_read_size is not
> initialized with a valid number.
>
> Fixes: 43c145b8b3ee ("spi: ich: Correct max-size bug in 
> ich_spi_adjust_size()")
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/spi/ich.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: Debugging dtoc?

[Simon Glass]

Hi Tom,

On Wed, 28 Jul 2021 at 17:28, Simon Glass  wrote:
>
> Hi again,
>
> On Mon, 26 Jul 2021 at 08:06, Simon Glass  wrote:
> >
> > Hi Tom,
> >
> > On Sun, 25 Jul 2021 at 15:10, Tom Rini  wrote:
> > >
> > > So, I'm trying to fix the problem on am335x_evm (and some family
> > > configs) with needing SPL_OF_CONTROL enabled.  This is mostly fine just
> > > enabling the option, except on am335x_evm itself, which is the
> > > kitchen-sink config and overflows memory.  I've gone with switching to
> > > SPL_OF_PLATDATA there as am335x in general has all of the U_BOOT_DRVINFO
> > > entries it needs I believe.  But, with the following patch:
> > >
> > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > index 4cf5f9928d58..514f682cac99 100644
> > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > @@ -8,6 +8,7 @@
> > >  _per {
> > >
> > > segment@30 {
> > > +   u-boot,dm-pre-reloc;
> > >
> > > target-module@e000 {
> > > u-boot,dm-pre-reloc;
> > > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > > b/configs/am335x_boneblack_vboot_defconfig
> > > index a0baeec79edd..ffeefd1a0087 100644
> > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > >  # CONFIG_CMD_SETEXPR is not set
> > >  CONFIG_BOOTP_DNS2=y
> > >  CONFIG_OF_CONTROL=y
> > > +CONFIG_SPL_OF_CONTROL=y
> > >  CONFIG_ENV_OVERWRITE=y
> > >  CONFIG_ENV_IS_IN_MMC=y
> > >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> > > index a33efff42a74..f35b2a02f56b 100644
> > > --- a/configs/am335x_evm_defconfig
> > > +++ b/configs/am335x_evm_defconfig
> > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > >  
> > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > >  # CONFIG_SPL_EFI_PARTITION is not set
> > >  CONFIG_OF_CONTROL=y
> > > +CONFIG_SPL_OF_CONTROL=y
> > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> > > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > +CONFIG_SPL_OF_PLATDATA=y
> > >  CONFIG_ENV_OVERWRITE=y
> > >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > >  CONFIG_SPL_ENV_IS_NOWHERE=y
> > >  CONFIG_VERSION_VARIABLE=y
> > >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > >  CONFIG_BOOTCOUNT_LIMIT=y
> > >  CONFIG_CLK=y
> > >  CONFIG_CLK_CDCE9XX=y
> > > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > > b/configs/am335x_evm_spiboot_defconfig
> > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > --- a/configs/am335x_evm_spiboot_defconfig
> > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > >  CONFIG_CMD_MTDPARTS=y
> > >  # CONFIG_SPL_EFI_PARTITION is not set
> > >  CONFIG_OF_CONTROL=y
> > > +CONFIG_SPL_OF_CONTROL=y
> > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> > > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > >  CONFIG_ENV_OVERWRITE=y
> > >  # CONFIG_ENV_IS_IN_FAT is not set
> > >
> > > I get the following failure and I don't see how to debug this:
> > >   DTOCspl/dts/dt-plat.c
> > > Traceback (most recent call last):
> > >   File "./tools/dtoc/dtoc", line 115, in 
> > > args.phase, instantiate=args.instantiate)
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 1223, in run_steps
> > > outfile.method(plat)
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 1081, in generate_plat
> > > self.output_node_plat(node)
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 1023, in output_node_plat
> > > self._output_values(node)
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 812, in _output_values
> > > self._output_prop(node, node.props[pname])
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 798, in _output_prop
> > > self._output_list(node, prop)
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 628, in _output_list
> > > vals.append(get_value(prop.type, val))
> > >   File 
> > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", line 
> > > 126, in get_value
> > > val = '%#x' % fdt_util.fdt32_to_cpu(value)
> > >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/fdt_util.py", 
> > > line 28, in fdt32_to_cpu
> > > return struct.unpack('>I', val)[0]
> > > TypeError: a 

[PATCH 3/3] dtoc: Support widening a bool value

[Simon Glass]

At present if we see 'ranges' property (with no value) we assume it is a
boolean, as per the devicetree spec.

But another node may define 'ranges' with a value, forcing us to widen it
to an int array. At present this is not supported and causes an error.

Fix this and add some test cases.

Signed-off-by: Simon Glass 
Reported-by: Tom Rini 
---

 arch/sandbox/dts/sandbox.dtsi|  2 ++
 test/dm/of_platdata.c|  3 +++
 tools/dtoc/fdt.py| 12 
 tools/dtoc/test/dtoc_test_simple.dts |  2 ++
 tools/dtoc/test_dtoc.py  |  3 +++
 tools/dtoc/test_fdt.py   | 18 --
 6 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 31db50db352..200fcab6a41 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -231,6 +231,7 @@
boolval;
intval = <1>;
intarray = <2 3 4>;
+   maybe-empty-int = <>;
byteval = [05];
bytearray = [06];
longbytearray = [09 0a 0b 0c 0d 0e 0f 10 11];
@@ -254,6 +255,7 @@
u-boot,dm-pre-reloc;
compatible = "sandbox,spl-test";
stringarray = "one";
+   maybe-empty-int = <1>;
};
 
spl-test5 {
diff --git a/test/dm/of_platdata.c b/test/dm/of_platdata.c
index e3fa01afddf..0463cf0b433 100644
--- a/test/dm/of_platdata.c
+++ b/test/dm/of_platdata.c
@@ -40,6 +40,8 @@ static int dm_test_of_plat_props(struct unit_test_state *uts)
ut_asserteq(3, plat->intarray[1]);
ut_asserteq(4, plat->intarray[2]);
ut_asserteq(5, plat->byteval);
+   ut_asserteq(1, ARRAY_SIZE(plat->maybe_empty_int));
+   ut_asserteq(0, plat->maybe_empty_int[0]);
ut_asserteq(3, ARRAY_SIZE(plat->bytearray));
ut_asserteq(6, plat->bytearray[0]);
ut_asserteq(0, plat->bytearray[1]);
@@ -78,6 +80,7 @@ static int dm_test_of_plat_props(struct unit_test_state *uts)
ut_asserteq_str("one", plat->stringarray[0]);
ut_asserteq_str("", plat->stringarray[1]);
ut_asserteq_str("", plat->stringarray[2]);
+   ut_asserteq(1, plat->maybe_empty_int[0]);
 
ut_assertok(uclass_next_device_err());
plat = dev_get_plat(dev);
diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 429e95f9a96..32a7aa98290 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -153,6 +153,18 @@ class Prop:
 specific.
 """
 if self.type.needs_widening(newprop.type):
+
+# A boolean has an empty value: if it exists it is True and if not
+# it is False. So when widening we always start with an empty list
+# since the only valid integer property would be an empty list of
+# integers.
+# e.g. this is a boolean:
+#some-prop;
+# and it would be widened to int list by:
+#some-prop = <1 2>;
+if self.type == Type.BOOL:
+self.type = Type.INT
+self.value = [self.GetEmpty(self.type)]
 if self.type == Type.INT and newprop.type == Type.BYTE:
 if type(self.value) == list:
 new_value = []
diff --git a/tools/dtoc/test/dtoc_test_simple.dts 
b/tools/dtoc/test/dtoc_test_simple.dts
index b5c1274bb7c..5a6fa88d5cc 100644
--- a/tools/dtoc/test/dtoc_test_simple.dts
+++ b/tools/dtoc/test/dtoc_test_simple.dts
@@ -14,6 +14,7 @@
u-boot,dm-pre-reloc;
compatible = "sandbox,spl-test";
boolval;
+   maybe-empty-int = <>;
intval = <1>;
intarray = <2 3 4>;
byteval = [05];
@@ -42,6 +43,7 @@
compatible = "sandbox,spl-test";
stringarray = "one";
longbytearray = [09 0a 0b 0c 0d 0e 0f 10];
+   maybe-empty-int = <1>;
};
 
i2c@0 {
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 44d5d0c354a..752061f27a4 100755
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -299,6 +299,7 @@ struct dtd_sandbox_spl_test {
 \tfdt32_t\t\tintarray[3];
 \tfdt32_t\t\tintval;
 \tunsigned char\tlongbytearray[9];
+\tfdt32_t\t\tmaybe_empty_int[1];
 \tunsigned char\tnotstring[5];
 \tconst char *\tstringarray[3];
 \tconst char *\tstringval;
@@ -358,6 +359,7 @@ static struct dtd_sandbox_spl_test dtv_spl_test = {
 \t.intval\t\t\t= 0x1,
 \t.longbytearray\t\t= {0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10,
 \t\t0x11},
+\t.maybe_empty_int\t= {0x0},
 \t.notstring\t\t= {0x20, 0x21, 0x22, 0x10, 0x0},
 \t.stringarray\t\t= {"multi-word", "message", ""},
 \t.stringval\t\t= "message",
@@ -398,6 +400,7 @@ U_BOOT_DRVINFO(spl_test2) = {
 static struct dtd_sandbox_spl_test dtv_spl_test3 = {
 \t.longbytearray\t\t= {0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10,
 \t\t0x0},
+\t.maybe_empty_int\t= 

[PATCH 2/3] dtoc: Fix widening an int array to an int

[Simon Glass]

An int array can hold a single int so we should not need to do anything
in the widening operation. However due to a quirk in the code, an int[3]
widened with an int produced an int[4]. Fix this and add a test.

Fix a comment typo while we are here.

Signed-off-by: Simon Glass 
Reported-by: Tom Rini 
---

 test/dm/of_platdata.c   |  4 +---
 tools/dtoc/fdt.py   | 15 ---
 tools/dtoc/test_dtoc.py |  6 +++---
 tools/dtoc/test_fdt.py  | 11 ++-
 4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/test/dm/of_platdata.c b/test/dm/of_platdata.c
index 0f89c7a7da8..e3fa01afddf 100644
--- a/test/dm/of_platdata.c
+++ b/test/dm/of_platdata.c
@@ -35,11 +35,10 @@ static int dm_test_of_plat_props(struct unit_test_state 
*uts)
plat = dev_get_plat(dev);
ut_assert(plat->boolval);
ut_asserteq(1, plat->intval);
-   ut_asserteq(4, ARRAY_SIZE(plat->intarray));
+   ut_asserteq(3, ARRAY_SIZE(plat->intarray));
ut_asserteq(2, plat->intarray[0]);
ut_asserteq(3, plat->intarray[1]);
ut_asserteq(4, plat->intarray[2]);
-   ut_asserteq(0, plat->intarray[3]);
ut_asserteq(5, plat->byteval);
ut_asserteq(3, ARRAY_SIZE(plat->bytearray));
ut_asserteq(6, plat->bytearray[0]);
@@ -61,7 +60,6 @@ static int dm_test_of_plat_props(struct unit_test_state *uts)
ut_asserteq(5, plat->intarray[0]);
ut_asserteq(0, plat->intarray[1]);
ut_asserteq(0, plat->intarray[2]);
-   ut_asserteq(0, plat->intarray[3]);
ut_asserteq(8, plat->byteval);
ut_asserteq(3, ARRAY_SIZE(plat->bytearray));
ut_asserteq(1, plat->bytearray[0]);
diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 9749966d5fb..429e95f9a96 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -163,13 +163,14 @@ class Prop:
 self.value = new_value
 self.type = newprop.type
 
-if type(newprop.value) == list and type(self.value) != list:
-self.value = [self.value]
-
-if type(self.value) == list and len(newprop.value) > len(self.value):
-val = self.GetEmpty(self.type)
-while len(self.value) < len(newprop.value):
-self.value.append(val)
+if type(newprop.value) == list:
+if type(self.value) != list:
+self.value = [self.value]
+
+if len(newprop.value) > len(self.value):
+val = self.GetEmpty(self.type)
+while len(self.value) < len(newprop.value):
+self.value.append(val)
 
 @classmethod
 def GetEmpty(self, type):
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 863ede90b7a..44d5d0c354a 100755
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -296,7 +296,7 @@ struct dtd_sandbox_spl_test {
 \tbool\t\tboolval;
 \tunsigned char\tbytearray[3];
 \tunsigned char\tbyteval;
-\tfdt32_t\t\tintarray[4];
+\tfdt32_t\t\tintarray[3];
 \tfdt32_t\t\tintval;
 \tunsigned char\tlongbytearray[9];
 \tunsigned char\tnotstring[5];
@@ -354,7 +354,7 @@ static struct dtd_sandbox_spl_test dtv_spl_test = {
 \t.boolval\t\t= true,
 \t.bytearray\t\t= {0x6, 0x0, 0x0},
 \t.byteval\t\t= 0x5,
-\t.intarray\t\t= {0x2, 0x3, 0x4, 0x0},
+\t.intarray\t\t= {0x2, 0x3, 0x4},
 \t.intval\t\t\t= 0x1,
 \t.longbytearray\t\t= {0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10,
 \t\t0x11},
@@ -377,7 +377,7 @@ static struct dtd_sandbox_spl_test dtv_spl_test2 = {
 \t.acpi_name\t\t= "_SB.GPO0",
 \t.bytearray\t\t= {0x1, 0x23, 0x34},
 \t.byteval\t\t= 0x8,
-\t.intarray\t\t= {0x5, 0x0, 0x0, 0x0},
+\t.intarray\t\t= {0x5, 0x0, 0x0},
 \t.intval\t\t\t= 0x3,
 \t.longbytearray\t\t= {0x9, 0xa, 0xb, 0xc, 0x0, 0x0, 0x0, 0x0,
 \t\t0x0},
diff --git a/tools/dtoc/test_fdt.py b/tools/dtoc/test_fdt.py
index 856392b1bd9..857861c14ed 100755
--- a/tools/dtoc/test_fdt.py
+++ b/tools/dtoc/test_fdt.py
@@ -379,7 +379,7 @@ class TestProp(unittest.TestCase):
 self.assertEqual(Type.INT, prop.type)
 self.assertEqual(1, fdt32_to_cpu(prop.value))
 
-# Convert singla value to array
+# Convert single value to array
 prop2 = self.node.props['intarray']
 prop.Widen(prop2)
 self.assertEqual(Type.INT, prop.type)
@@ -422,6 +422,15 @@ class TestProp(unittest.TestCase):
 self.assertTrue(isinstance(prop.value, list))
 self.assertEqual(3, len(prop.value))
 
+# Widen an array of ints with an int (should do nothing)
+prop = self.node.props['intarray']
+prop2 = node2.props['intarray']
+self.assertEqual(Type.INT, prop.type)
+self.assertEqual(3, len(prop.value))
+prop.Widen(prop2)
+self.assertEqual(Type.INT, prop.type)
+self.assertEqual(3, len(prop.value))
+
 def testAdd(self):
 """Test adding properties"""
 self.fdt.pack()
-- 
2.32.0.432.gabb21c7263-goog

[PATCH 1/3] dtoc: Rename is_wider_than() to reduce confusion

[Simon Glass]

The current name is confusing because the logic is actually backwards from
what you might expect. Rename it to needs_widening() and update the
comments.

Signed-off-by: Simon Glass 
---

 tools/dtoc/fdt.py | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 3996971e39c..9749966d5fb 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -24,16 +24,19 @@ from patman import tools
 
 # A list of types we support
 class Type(IntEnum):
+# Types in order from widest to narrowest
 (BYTE, INT, STRING, BOOL, INT64) = range(5)
 
-def is_wider_than(self, other):
-"""Check if another type is 'wider' than this one
+def needs_widening(self, other):
+"""Check if this type needs widening to hold a value from another type
 
-A wider type is one that holds more information than an earlier one,
-similar to the concept of type-widening in C.
+A wider type is one that can hold a wider array of information than
+another one, or is less restrictive, so it can hold the information of
+another type as well as its own. This is similar to the concept of
+type-widening in C.
 
 This uses a simple arithmetic comparison, since type values are in 
order
-from narrowest (BYTE) to widest (INT64).
+from widest (BYTE) to narrowest (INT64).
 
 Args:
 other: Other type to compare against
@@ -149,7 +152,7 @@ class Prop:
 update the current property to be like the second, since it is less
 specific.
 """
-if self.type.is_wider_than(newprop.type):
+if self.type.needs_widening(newprop.type):
 if self.type == Type.INT and newprop.type == Type.BYTE:
 if type(self.value) == list:
 new_value = []
-- 
2.32.0.432.gabb21c7263-goog

[PATCH 0/3] dtoc: Improve support for 'ranges' property

[Simon Glass]

An empty ranges property confuses dtoc at present and it dies with an
error. This series fixes this and a few related things.


Simon Glass (3):
  dtoc: Rename is_wider_than() to reduce confusion
  dtoc: Fix widening an int array to an int
  dtoc: Support widening a bool value

 arch/sandbox/dts/sandbox.dtsi|  2 ++
 test/dm/of_platdata.c|  7 ++---
 tools/dtoc/fdt.py| 40 +++-
 tools/dtoc/test/dtoc_test_simple.dts |  2 ++
 tools/dtoc/test_dtoc.py  |  9 ---
 tools/dtoc/test_fdt.py   | 29 +---
 6 files changed, 68 insertions(+), 21 deletions(-)

-- 
2.32.0.432.gabb21c7263-goog

Re: [PATCH] arm: mediatek: merge board Kconfigs into mach-mediatek

[Tom Rini]

On Mon, Jul 19, 2021 at 01:07:02PM +0200, Guillaume La Roque wrote:

> On MediaTek boards we cannot override the SYS_BOARD / SYS_CONFIG_NAME
> variables from defconfig.
> This is because in board/mediatek/mt/Kconfig this value was override
> by default due to the if CONFIG_TARGET_MT condition.
> 
> Merge all the Kconfigs to the mach-medatek/Kconfig.
> 
> This way:
> - we only define SYS_{SOC,VENDOR} once
> - all board definitions are in a single place, simplifying the build logic.
> 
> Signed-off-by: Guillaume La Roque 
> ---
>  arch/arm/mach-mediatek/Kconfig   | 42 +++-
>  arch/mips/mach-mtmips/Kconfig|  3 ++
>  arch/mips/mach-mtmips/mt7620/Kconfig |  8 +-
>  arch/mips/mach-mtmips/mt7628/Kconfig | 11 +++-
>  board/mediatek/mt7620/Kconfig| 12 
>  board/mediatek/mt7622/Kconfig| 17 ---
>  board/mediatek/mt7623/Kconfig| 13 -
>  board/mediatek/mt7628/Kconfig| 12 
>  board/mediatek/mt7629/Kconfig| 17 ---
>  board/mediatek/mt8183/Kconfig| 13 -
>  board/mediatek/mt8512/Kconfig| 14 --
>  board/mediatek/mt8516/Kconfig| 13 -
>  board/mediatek/mt8518/Kconfig| 14 --
>  13 files changed, 55 insertions(+), 134 deletions(-)
>  delete mode 100644 board/mediatek/mt7620/Kconfig
>  delete mode 100644 board/mediatek/mt7622/Kconfig
>  delete mode 100644 board/mediatek/mt7623/Kconfig
>  delete mode 100644 board/mediatek/mt7628/Kconfig
>  delete mode 100644 board/mediatek/mt7629/Kconfig
>  delete mode 100644 board/mediatek/mt8183/Kconfig
>  delete mode 100644 board/mediatek/mt8512/Kconfig
>  delete mode 100644 board/mediatek/mt8516/Kconfig
>  delete mode 100644 board/mediatek/mt8518/Kconfig

This breaks:
gardena-smart-gateway-mt7688 linkit-smart-7688 vocore2

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 8/9] Add an option for EBBR

[Tom Rini]

On Thu, Jul 29, 2021 at 02:12:19AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 7/2/21 8:36 PM, Simon Glass wrote:
> > Add a new Kconfig option for EBBR so that the naming is more explicit.
> > Make it select EFI_LOADER which is required for EBBR to work.
> > 
> > Copy over the same 'default' setting so that there is no change in
> > which boards enable it.
> > 
> > Signed-off-by: Simon Glass 
> > ---
> > 
> > Changes in v2:
> > - Split out new patch to create an option for EBBR
> > 
> >   common/Kconfig.boot| 16 
> >   lib/efi_loader/Kconfig |  1 -
> >   2 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/common/Kconfig.boot b/common/Kconfig.boot
> > index 89a3161f1fa..111032e1202 100644
> > --- a/common/Kconfig.boot
> > +++ b/common/Kconfig.boot
> > @@ -300,6 +300,22 @@ config LEGACY_IMAGE_FORMAT
> >   loaded. If a board needs the legacy image format support in this
> >   case, enable it here.
> > 
> > +config EBBR
> > +   bool "Enable support for Embeeded Boot Base Requirements (EBBR)"
> > +   select EFI_LOADER
> > +   default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
> 
> This won't work. You cannot have UEFI neither on big-endian systems nor
> on any other architecture not mentioned in the UEFI specification.
> 
> Why do you want to exclude arm1136 and arm1176?

This is just moving the default y logic from EFI_LOADER over here.

> > +   help
> > + Enable this to support ARM's EBBR boot method. This bases everything
> > + on UEFI protocols.´
> 
> EBBR is explitely not ARM specific. EBBR is not a boot method but a
> subset of the UEFI specification.
> 
> > +
> > + This Embedded Base Boot Requirements (EBBR) specification defines an
> > + interface between platform firmware and an operating system that is
> > + suitable for embedded platforms. EBBR-compliant platforms present a
> > + consistent interface that will boot an EBBR-compliant operating
> > + system without any custom tailoring required. For example, an Arm
> > + A-class embedded platform will benefit from a standard interface that
> > + supports features such as secure boot and firmware update.
> 
> Which user will ever have heard of the EBBR specification? Referencing
> it in Kconfig will lead to confusion.
> 
> This new symbol is redundant. If you think that a better name for
> EFI_LOADER is needed, please suggest one.

At this point in time, yes, there's no need for a separate EBBR symbol
as everything we need to be compliant comes down to "enable EFI_LOADER".
It is possible that in the future we may need / want a specific symbol
to ensure we have all of the required EBBR functionality as some of it
may end up being non-default.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 6/9] sandbox: add config for efi capsule authentication test

[AKASHI Takahiro]

On Wed, Jul 28, 2021 at 10:21:56PM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 7/27/21 11:10 AM, AKASHI Takahiro wrote:
> > This new configuration, which was derived from sandbox_defconfig, will be
> > used solely to run efi capsule authentication test as the test requires
> > a public key (esl file) to be embedded in U-Boot binary.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >   configs/sandbox_capsule_auth_defconfig | 307 +
> >   1 file changed, 307 insertions(+)
> >   create mode 100644 configs/sandbox_capsule_auth_defconfig
> > 
> > diff --git a/configs/sandbox_capsule_auth_defconfig 
> > b/configs/sandbox_capsule_auth_defconfig
> > new file mode 100644
> > index ..8e0ffb1a6995
> > --- /dev/null
> > +++ b/configs/sandbox_capsule_auth_defconfig
> > @@ -0,0 +1,307 @@
> > +CONFIG_SYS_TEXT_BASE=0
> > +CONFIG_NR_DRAM_BANKS=1
> > +CONFIG_SYS_MEMTEST_START=0x0010
> > +CONFIG_SYS_MEMTEST_END=0x00101000
> > +CONFIG_ENV_SIZE=0x2000
> > +CONFIG_DEFAULT_DEVICE_TREE="sandbox"
> > +CONFIG_PRE_CON_BUF_ADDR=0xf
> > +CONFIG_BOOTSTAGE_STASH_ADDR=0x0
> > +CONFIG_DEBUG_UART=y
> > +CONFIG_DISTRO_DEFAULTS=y
> > +CONFIG_FIT=y
> > +CONFIG_FIT_SIGNATURE=y
> > +CONFIG_FIT_RSASSA_PSS=y
> > +CONFIG_FIT_CIPHER=y
> > +CONFIG_FIT_VERBOSE=y
> > +CONFIG_BOOTSTAGE=y
> > +CONFIG_BOOTSTAGE_REPORT=y
> > +CONFIG_BOOTSTAGE_FDT=y
> > +CONFIG_BOOTSTAGE_STASH=y
> > +CONFIG_BOOTSTAGE_STASH_SIZE=0x4096
> > +CONFIG_CONSOLE_RECORD=y
> > +CONFIG_CONSOLE_RECORD_OUT_SIZE=0x1000
> > +CONFIG_PRE_CONSOLE_BUFFER=y
> > +CONFIG_LOG=y
> > +CONFIG_DISPLAY_BOARDINFO_LATE=y
> > +CONFIG_MISC_INIT_F=y
> > +CONFIG_STACKPROTECTOR=y
> > +CONFIG_ANDROID_AB=y
> > +CONFIG_CMD_CPU=y
> > +CONFIG_CMD_LICENSE=y
> > +CONFIG_CMD_BOOTZ=y
> > +CONFIG_CMD_BOOTEFI_HELLO=y
> > +CONFIG_CMD_ABOOTIMG=y
> > +# CONFIG_CMD_ELF is not set
> > +CONFIG_CMD_ASKENV=y
> > +CONFIG_CMD_GREPENV=y
> > +CONFIG_CMD_ERASEENV=y
> > +CONFIG_CMD_ENV_CALLBACK=y
> > +CONFIG_CMD_ENV_FLAGS=y
> > +CONFIG_CMD_NVEDIT_EFI=y
> > +CONFIG_CMD_NVEDIT_INFO=y
> > +CONFIG_CMD_NVEDIT_LOAD=y
> > +CONFIG_CMD_NVEDIT_SELECT=y
> > +CONFIG_LOOPW=y
> > +CONFIG_CMD_MD5SUM=y
> > +CONFIG_CMD_MEMINFO=y
> > +CONFIG_CMD_MEM_SEARCH=y
> > +CONFIG_CMD_MX_CYCLIC=y
> > +CONFIG_CMD_MEMTEST=y
> > +CONFIG_CMD_BIND=y
> > +CONFIG_CMD_DEMO=y
> > +CONFIG_CMD_GPIO=y
> > +CONFIG_CMD_PWM=y
> > +CONFIG_CMD_GPT=y
> > +CONFIG_CMD_GPT_RENAME=y
> > +CONFIG_CMD_IDE=y
> > +CONFIG_CMD_I2C=y
> > +CONFIG_CMD_LSBLK=y
> > +CONFIG_CMD_MUX=y
> > +CONFIG_CMD_OSD=y
> > +CONFIG_CMD_PCI=y
> > +CONFIG_CMD_READ=y
> > +CONFIG_CMD_REMOTEPROC=y
> > +CONFIG_CMD_SPI=y
> > +CONFIG_CMD_USB=y
> > +CONFIG_CMD_AXI=y
> > +CONFIG_CMD_AB_SELECT=y
> > +CONFIG_BOOTP_DNS2=y
> > +CONFIG_CMD_PCAP=y
> > +CONFIG_CMD_TFTPPUT=y
> > +CONFIG_CMD_TFTPSRV=y
> > +CONFIG_CMD_RARP=y
> > +CONFIG_CMD_CDP=y
> > +CONFIG_CMD_SNTP=y
> > +CONFIG_CMD_DNS=y
> > +CONFIG_CMD_LINK_LOCAL=y
> > +CONFIG_CMD_ETHSW=y
> > +CONFIG_CMD_BMP=y
> > +CONFIG_CMD_BOOTCOUNT=y
> > +CONFIG_CMD_EFIDEBUG=y
> > +CONFIG_CMD_RTC=y
> > +CONFIG_CMD_TIME=y
> > +CONFIG_CMD_TIMER=y
> > +CONFIG_CMD_SOUND=y
> > +CONFIG_CMD_QFW=y
> > +CONFIG_CMD_PSTORE=y
> > +CONFIG_CMD_PSTORE_MEM_ADDR=0x300
> > +CONFIG_CMD_BOOTSTAGE=y
> > +CONFIG_CMD_PMIC=y
> > +CONFIG_CMD_REGULATOR=y
> > +CONFIG_CMD_AES=y
> > +CONFIG_CMD_TPM=y
> > +CONFIG_CMD_TPM_TEST=y
> > +CONFIG_CMD_BTRFS=y
> > +CONFIG_CMD_CBFS=y
> > +CONFIG_CMD_CRAMFS=y
> > +CONFIG_CMD_EXT4_WRITE=y
> > +CONFIG_CMD_SQUASHFS=y
> > +CONFIG_CMD_MTDPARTS=y
> > +CONFIG_CMD_STACKPROTECTOR_TEST=y
> > +CONFIG_MAC_PARTITION=y
> > +CONFIG_AMIGA_PARTITION=y
> > +CONFIG_OF_CONTROL=y
> > +CONFIG_OF_LIVE=y
> > +CONFIG_OF_HOSTFILE=y
> > +CONFIG_ENV_IS_NOWHERE=y
> > +CONFIG_ENV_IS_IN_EXT4=y
> > +CONFIG_ENV_EXT4_INTERFACE="host"
> > +CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
> > +CONFIG_ENV_IMPORT_FDT=y
> > +CONFIG_BOOTP_SEND_HOSTNAME=y
> > +CONFIG_NETCONSOLE=y
> > +CONFIG_IP_DEFRAG=y
> > +CONFIG_DM_DMA=y
> > +CONFIG_REGMAP=y
> > +CONFIG_SYSCON=y
> > +CONFIG_DEVRES=y
> > +CONFIG_DEBUG_DEVRES=y
> > +CONFIG_SIMPLE_PM_BUS=y
> > +CONFIG_ADC=y
> > +CONFIG_ADC_SANDBOX=y
> > +CONFIG_AXI=y
> > +CONFIG_AXI_SANDBOX=y
> > +CONFIG_BOOTCOUNT_LIMIT=y
> > +CONFIG_DM_BOOTCOUNT=y
> > +CONFIG_DM_BOOTCOUNT_RTC=y
> > +CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
> > +CONFIG_BUTTON=y
> > +CONFIG_BUTTON_ADC=y
> > +CONFIG_BUTTON_GPIO=y
> > +CONFIG_CLK=y
> > +CONFIG_CLK_COMPOSITE_CCF=y
> > +CONFIG_CLK_SCMI=y
> > +CONFIG_CLK_K210=y
> > +CONFIG_CLK_K210_SET_RATE=y
> > +CONFIG_SANDBOX_CLK_CCF=y
> > +CONFIG_CPU=y
> > +CONFIG_DM_DEMO=y
> > +CONFIG_DM_DEMO_SIMPLE=y
> > +CONFIG_DM_DEMO_SHAPE=y
> > +CONFIG_DFU_SF=y
> > +CONFIG_DMA=y
> > +CONFIG_DMA_CHANNELS=y
> > +CONFIG_SANDBOX_DMA=y
> > +CONFIG_FASTBOOT_FLASH=y
> > +CONFIG_FASTBOOT_FLASH_MMC_DEV=0
> > +CONFIG_GPIO_HOG=y
> > +CONFIG_DM_GPIO_LOOKUP_LABEL=y
> > +CONFIG_PM8916_GPIO=y
> > +CONFIG_SANDBOX_GPIO=y
> > +CONFIG_DM_HWSPINLOCK=y
> > +CONFIG_HWSPINLOCK_SANDBOX=y
> > +CONFIG_I2C_CROS_EC_TUNNEL=y
> > +CONFIG_I2C_CROS_EC_LDO=y
> > 

Re: [PATCH v2 9/9] efi: Make EBBR optional

[Heinrich Schuchardt]

On 7/2/21 10:38 PM, Simon Glass wrote:

Hi Tom,

On Fri, 2 Jul 2021 at 14:11, Tom Rini  wrote:


On Fri, Jul 02, 2021 at 12:36:20PM -0600, Simon Glass wrote:


Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.

Resync the CONFIG options also.

Signed-off-by: Simon Glass 


NAK.  It's very much intentional that we have EFI_LOADER, and then
looking ahead, any other options that would be required to be EBBR
compliant, be enabled by default on platforms that can support them,
rather than optional.


As you can tell, I'm not convinced that EBBR is a good idea, even
though I can see it is expedient. Anyway I do appreciate your clear
guidance and direction on this sort of thing and I'm sure many others > do also.


Having a bunch of non-standardized methods to start an operating system
is not really compelling. Currently UEFI is the only widespread,
operating system independent boot standard.

Best regards

Heinrich



Regards,
Simon

[PATCH] lib: rsa: Extract public key from private key if keyfile argument is used

[Chan, Donald]

If the 'keyfile' (-G) argument is used, there is little value to require
'keydir' (-k) argument since the public key can also be extracted from the
private key itself.

Signed-off-by: Donald Chan 
---
 lib/rsa/rsa-sign.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index f4ed11e74a..f70f352311 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -49,16 +49,16 @@ static int rsa_err(const char *msg)
 }
 
 /**
- * rsa_pem_get_pub_key() - read a public key from a .crt file
+ * rsa_pem_get_pub_key() - read a public key from a private key file or .crt 
file
  *
- * @keydir:Directory containins the key
- * @name   Name of key file (will have a .crt extension)
+ * @keydir:Directory containing the key, can be NULL
+ * @name   Name of key file (will apply a .crt extension if keydir is not 
NULL)
  * @evpp   Returns EVP_PKEY object, or NULL on failure
  * @return 0 if ok, -ve on error (in which case *evpp will be set to NULL)
  */
 static int rsa_pem_get_pub_key(const char *keydir, const char *name, EVP_PKEY 
**evpp)
 {
-   char path[1024];
+   char path[1024] = {0};
EVP_PKEY *key = NULL;
X509 *cert;
FILE *f;
@@ -68,7 +68,10 @@ static int rsa_pem_get_pub_key(const char *keydir, const 
char *name, EVP_PKEY **
return -EINVAL;
 
*evpp = NULL;
-   snprintf(path, sizeof(path), "%s/%s.crt", keydir, name);
+   if (keydir && name)
+   snprintf(path, sizeof(path), "%s/%s.crt", keydir, name);
+   else if (name)
+   snprintf(path, sizeof(path), "%s", name);
f = fopen(path, "r");
if (!f) {
fprintf(stderr, "Couldn't open RSA certificate: '%s': %s\n",
@@ -76,7 +79,13 @@ static int rsa_pem_get_pub_key(const char *keydir, const 
char *name, EVP_PKEY **
return -EACCES;
}
 
-   /* Read the certificate */
+   /* See if it contains a PEM private key? */
+   if (PEM_read_PrivateKey(f, evpp, NULL, path)) {
+   fclose(f);
+   return 0;
+   }
+
+   /* Not a PEM private key, read the certificate */
cert = NULL;
if (!PEM_read_X509(f, , NULL, NULL)) {
rsa_err("Couldn't read certificate");
@@ -672,7 +681,12 @@ int rsa_add_verify_data(struct image_sign_info *info, void 
*keydest)
if (ret)
return ret;
}
-   ret = rsa_get_pub_key(info->keydir, info->keyname, e, );
+   if (info->keydir && info->keyname)
+   ret = rsa_get_pub_key(info->keydir, info->keyname, e, );
+   else if (info->keyfile)
+   ret = rsa_get_pub_key(NULL, info->keyfile, e, );
+   else
+   ret = -EINVAL;
if (ret)
goto err_get_pub_key;
 #if OPENSSL_VERSION_NUMBER < 0x1010L || \
-- 
2.16.6

Re: [PATCH v2 8/9] Add an option for EBBR

[Heinrich Schuchardt]

On 7/2/21 8:36 PM, Simon Glass wrote:

Add a new Kconfig option for EBBR so that the naming is more explicit.
Make it select EFI_LOADER which is required for EBBR to work.

Copy over the same 'default' setting so that there is no change in
which boards enable it.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Split out new patch to create an option for EBBR

  common/Kconfig.boot| 16 
  lib/efi_loader/Kconfig |  1 -
  2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 89a3161f1fa..111032e1202 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -300,6 +300,22 @@ config LEGACY_IMAGE_FORMAT
  loaded. If a board needs the legacy image format support in this
  case, enable it here.

+config EBBR
+   bool "Enable support for Embeeded Boot Base Requirements (EBBR)"
+   select EFI_LOADER
+   default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8


This won't work. You cannot have UEFI neither on big-endian systems nor
on any other architecture not mentioned in the UEFI specification.

Why do you want to exclude arm1136 and arm1176?


+   help
+ Enable this to support ARM's EBBR boot method. This bases everything
+ on UEFI protocols.´


EBBR is explitely not ARM specific. EBBR is not a boot method but a
subset of the UEFI specification.


+
+ This Embedded Base Boot Requirements (EBBR) specification defines an
+ interface between platform firmware and an operating system that is
+ suitable for embedded platforms. EBBR-compliant platforms present a
+ consistent interface that will boot an EBBR-compliant operating
+ system without any custom tailoring required. For example, an Arm
+ A-class embedded platform will benefit from a standard interface that
+ supports features such as secure boot and firmware update.


Which user will ever have heard of the EBBR specification? Referencing
it in Kconfig will lead to confusion.

This new symbol is redundant. If you think that a better name for
EFI_LOADER is needed, please suggest one.

Best regards

Heinrich


+
  config SUPPORT_RAW_INITRD
bool "Enable raw initrd images"
help
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 466abfed300..bc5fb3f5e03 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -10,7 +10,6 @@ config EFI_LOADER
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
-   default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
select LIB_UUID
select HAVE_BLOCK_DEVICE
select REGEX

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Tom Rini]

On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 7/27/21 12:07 AM, Tom Rini wrote:
> > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > 
> > > This feature should never have been made available when driver model
> > > or devicetree are disabled. Add these as conditions, so that we don't
> > > create even more barriers to migration.
> > > 
> > > Add a note about the substantial size increment associated with this
> > > option.
> > > 
> > > Signed-off-by: Simon Glass 
> > > ---
> > > 
> > > Changes in v2:
> > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL
> > > - Note the approximate size of this feature in the help
> > > 
> > >   lib/efi_loader/Kconfig | 4 +++-
> > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > index 6242caceb7f..466abfed300 100644
> > > --- a/lib/efi_loader/Kconfig
> > > +++ b/lib/efi_loader/Kconfig
> > > @@ -1,6 +1,6 @@
> > >   config EFI_LOADER
> > >   bool "Support running UEFI applications"
> > > - depends on OF_LIBFDT && ( \
> > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> 
> Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid
> of this symbol?

No, but I did send out a message about that today as we're very close.
Much closer than I had expected us to be.

> Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM?

Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and sniper.

> Why are these separate symbols? Isn't this symbol to be eliminated, too?

Simon?

> lib/efi_loader/efi_disk.c is the only place where we maintain duplicate
> code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends
> on CONFIG_DM) would make more sense to me. But only in a patch
> eliminating the non-BLK code.

I just know that off-hand, partition + disk + block has some corner
case, but maybe that corner case is unintentional in terms of usage
today.

> > >   ARM && (SYS_CPU = arm1136 || \
> > >   SYS_CPU = arm1176 || \
> > >   SYS_CPU = armv7   || \
> > > @@ -25,6 +25,8 @@ config EFI_LOADER
> > > will expose the UEFI API to a loaded application, enabling it 
> > > to
> > > reuse U-Boot's device drivers.
> > > 
> > > +   For ARM 32-bit, this adds about 90KB to the size of U-Boot.
> > > +
> 
> There is no unit ISO prefix K. Do you mean KiB?
> 
> 90 KiB may be the value today. Will you update it regularly? Otherwise
> don't put a number here.
> 
> I can't see that the effect on size is truly architecture specific. Why
> do you refer to 32bit ARM?
> 
> Such a comment would better fit into a documentation chapter on
> downsizing U-Boot.

Yes, we should probably drop that specific note.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Heinrich Schuchardt]

On 7/27/21 12:07 AM, Tom Rini wrote:

On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:


This feature should never have been made available when driver model
or devicetree are disabled. Add these as conditions, so that we don't
create even more barriers to migration.

Add a note about the substantial size increment associated with this
option.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL
- Note the approximate size of this feature in the help

  lib/efi_loader/Kconfig | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 6242caceb7f..466abfed300 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,6 @@
  config EFI_LOADER
bool "Support running UEFI applications"
-   depends on OF_LIBFDT && ( \
+   depends on OF_LIBFDT && DM && OF_CONTROL && ( \


Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid
of this symbol?

Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM?
Why are these separate symbols? Isn't this symbol to be eliminated, too?

lib/efi_loader/efi_disk.c is the only place where we maintain duplicate
code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends
on CONFIG_DM) would make more sense to me. But only in a patch
eliminating the non-BLK code.


ARM && (SYS_CPU = arm1136 || \
SYS_CPU = arm1176 || \
SYS_CPU = armv7   || \
@@ -25,6 +25,8 @@ config EFI_LOADER
  will expose the UEFI API to a loaded application, enabling it to
  reuse U-Boot's device drivers.

+ For ARM 32-bit, this adds about 90KB to the size of U-Boot.
+


There is no unit ISO prefix K. Do you mean KiB?

90 KiB may be the value today. Will you update it regularly? Otherwise
don't put a number here.

I can't see that the effect on size is truly architecture specific. Why
do you refer to 32bit ARM?

Such a comment would better fit into a documentation chapter on
downsizing U-Boot.

Best regards

Heinrich


  if EFI_LOADER

  config CMD_BOOTEFI_BOOTMGR


Note that we have platforms today with EFI_LOADER without OF_CONTROL, so
this isn't strictly the right requirements.  What do you think here
Heinrich?

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Tom Rini]

On Thu, Jul 29, 2021 at 02:37:10AM +0300, Artem Panfilov wrote:
> 
> On 29.07.2021 01:56, Tom Rini wrote:
> > Part of the question is then, were you enabling the SSL-related parts
> > before this change?  Or did the way the code is now being
> > enabled/disabled trigger this now being enabled when it wasn't before?
> >
> This commit broke the build:
> https://gitlab.com/u-boot/u-boot/-/commit/cb9faa6f98ae56d70d59505dad290dd3d381cb7b

OK.  How?  Or rather, what part of that is causing previously unbuilt
code to now be built?

> Our testing board defconfig:
> https://gitlab.com/u-boot/u-boot/-/blob/master/configs/hsdk_defconfig

OK.

> I also found this patch that was committed 4 months ago.
> It includes OpenSSL compatibility for old versions:
> https://gitlab.com/u-boot/u-boot/-/commit/fbc777429fa35312a9ea5f106692172d3153e659

Yes, true.  And that's two 1-line if/else.  That's a reasonable to me
level of effort to keep supporting older hosts.  Your patch is adding in
60 lines.  I really do want to dig a bit more here.

And honestly, part of my concerns also go around "who is going to
maintain / test this area?".  We don't have these older versions in CI
(or we would have seen the problem before merging).  Are you
volunteering to support the relevant code areas here but on older
openssl/libressl ?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Artem Panfilov]

On 29.07.2021 01:56, Tom Rini wrote:
> Part of the question is then, were you enabling the SSL-related parts
> before this change?  Or did the way the code is now being
> enabled/disabled trigger this now being enabled when it wasn't before?
>
This commit broke the build:
https://gitlab.com/u-boot/u-boot/-/commit/cb9faa6f98ae56d70d59505dad290dd3d381cb7b

Our testing board defconfig:
https://gitlab.com/u-boot/u-boot/-/blob/master/configs/hsdk_defconfig

I also found this patch that was committed 4 months ago.
It includes OpenSSL compatibility for old versions:
https://gitlab.com/u-boot/u-boot/-/commit/fbc777429fa35312a9ea5f106692172d3153e659

---
Artem

Re: Debugging dtoc?

[Simon Glass]

Hi again,

On Mon, 26 Jul 2021 at 08:06, Simon Glass  wrote:
>
> Hi Tom,
>
> On Sun, 25 Jul 2021 at 15:10, Tom Rini  wrote:
> >
> > So, I'm trying to fix the problem on am335x_evm (and some family
> > configs) with needing SPL_OF_CONTROL enabled.  This is mostly fine just
> > enabling the option, except on am335x_evm itself, which is the
> > kitchen-sink config and overflows memory.  I've gone with switching to
> > SPL_OF_PLATDATA there as am335x in general has all of the U_BOOT_DRVINFO
> > entries it needs I believe.  But, with the following patch:
> >
> > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > index 4cf5f9928d58..514f682cac99 100644
> > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > @@ -8,6 +8,7 @@
> >  _per {
> >
> > segment@30 {
> > +   u-boot,dm-pre-reloc;
> >
> > target-module@e000 {
> > u-boot,dm-pre-reloc;
> > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > b/configs/am335x_boneblack_vboot_defconfig
> > index a0baeec79edd..ffeefd1a0087 100644
> > --- a/configs/am335x_boneblack_vboot_defconfig
> > +++ b/configs/am335x_boneblack_vboot_defconfig
> > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> >  # CONFIG_CMD_SETEXPR is not set
> >  CONFIG_BOOTP_DNS2=y
> >  CONFIG_OF_CONTROL=y
> > +CONFIG_SPL_OF_CONTROL=y
> >  CONFIG_ENV_OVERWRITE=y
> >  CONFIG_ENV_IS_IN_MMC=y
> >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> > index a33efff42a74..f35b2a02f56b 100644
> > --- a/configs/am335x_evm_defconfig
> > +++ b/configs/am335x_evm_defconfig
> > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> >  
> > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> >  # CONFIG_SPL_EFI_PARTITION is not set
> >  CONFIG_OF_CONTROL=y
> > +CONFIG_SPL_OF_CONTROL=y
> >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > +CONFIG_SPL_OF_PLATDATA=y
> >  CONFIG_ENV_OVERWRITE=y
> >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> >  CONFIG_SPL_ENV_IS_NOWHERE=y
> >  CONFIG_VERSION_VARIABLE=y
> >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > +# CONFIG_SPL_SIMPLE_BUS is not set
> >  CONFIG_BOOTCOUNT_LIMIT=y
> >  CONFIG_CLK=y
> >  CONFIG_CLK_CDCE9XX=y
> > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > b/configs/am335x_evm_spiboot_defconfig
> > index 8f0c330674a9..4a2a56a9af9e 100644
> > --- a/configs/am335x_evm_spiboot_defconfig
> > +++ b/configs/am335x_evm_spiboot_defconfig
> > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> >  CONFIG_CMD_MTDPARTS=y
> >  # CONFIG_SPL_EFI_PARTITION is not set
> >  CONFIG_OF_CONTROL=y
> > +CONFIG_SPL_OF_CONTROL=y
> >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> >  CONFIG_ENV_OVERWRITE=y
> >  # CONFIG_ENV_IS_IN_FAT is not set
> >
> > I get the following failure and I don't see how to debug this:
> >   DTOCspl/dts/dt-plat.c
> > Traceback (most recent call last):
> >   File "./tools/dtoc/dtoc", line 115, in 
> > args.phase, instantiate=args.instantiate)
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 1223, in run_steps
> > outfile.method(plat)
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 1081, in generate_plat
> > self.output_node_plat(node)
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 1023, in output_node_plat
> > self._output_values(node)
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 812, in _output_values
> > self._output_prop(node, node.props[pname])
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 798, in _output_prop
> > self._output_list(node, prop)
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 628, in _output_list
> > vals.append(get_value(prop.type, val))
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > line 126, in get_value
> > val = '%#x' % fdt_util.fdt32_to_cpu(value)
> >   File "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/fdt_util.py", 
> > line 28, in fdt32_to_cpu
> > return struct.unpack('>I', val)[0]
> > TypeError: a bytes-like object is required, not 'bool'
> > scripts/Makefile.spl:352: recipe for target 'spl/dts/dt-plat.c' failed
> > make[1]: *** [spl/dts/dt-plat.c] Error 1
> > make[1]: *** Deleting file 'spl/dts/dt-plat.c'
> > Makefile:1999: recipe for target 'spl/u-boot-spl' failed
> > make: *** [spl/u-boot-spl] Error 2
>
> That seems 

Re: [PATCH v2 3/9] disk: Tidy up #ifdefs in part_efi

[Heinrich Schuchardt]

On 7/2/21 8:36 PM, Simon Glass wrote:

This file does not correctly handle the various cases, sometimes
producing warnings about partition_basic_data_guid being defined but not
used. Fix it.

There was some discussion about adjusting Kconfig or making
HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is
not feasible. Such changes can be undertaken separate from the goal of
this series.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Update commit message

  disk/part_efi.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 0fb7ff0b6bb..fdca91a6974 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -29,12 +29,13 @@

  DECLARE_GLOBAL_DATA_PTR;

-/*
- * GUID for basic data partions.
- */
+#ifdef CONFIG_HAVE_BLOCK_DEVICE
+
+/* GUID for basic data partitons */
+#if CONFIG_IS_ENABLED(EFI_PARTITION)


We are using -fdata-sections. Doesn't the linker eliminate unused statics?

Best regards

Heinrich


  static const efi_guid_t partition_basic_data_guid = PARTITION_BASIC_DATA_GUID;
+#endif

-#ifdef CONFIG_HAVE_BLOCK_DEVICE
  /**
   * efi_crc32() - EFI version of crc32 function
   * @buf: buffer to calculate crc32 of
@@ -1126,4 +1127,4 @@ U_BOOT_PART_TYPE(a_efi) = {
.print  = part_print_ptr(part_print_efi),
.test   = part_test_efi,
  };
-#endif
+#endif /* CONFIG_HAVE_BLOCK_DEVICE */

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Artem Panfilov]

On 28.07.2021 23:07, Tom Rini wrote:
> There is a fine line at least that I'm willing to walk in terms of
> supporting ancient OSes directly and also not making things overly
> complicated in our own tree.  That said, openssl tends to be one of the
> ones where it does get hard to support old versions.  LibreSSL 2.7.5 was
> released December 15th, 2018 and is the end of the 2.7.x line it seems.
>
> I'm interested to hear what the case is where the right call is the say
> you're building modern software for real world use against such old
> libraries.
Hi Tom,
I have a specific test case where I test if it's still possible to
build upstream master u-boot on our infrastructure (progression testing).
I also test runtime on our boards.

I understand that nowadays everyone uses docker container,
but ​we have limited docker nodes right now on our site.

If you don't want to support OpenSSL < 1.1.0 and do not test it,
then I suggest dropping it all over the tree because it doesn't
make sense and looks misleading with such a partial solution.

Best regards,
Artem

[PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Artem Panfilov]

Fix LibreSSL compilation for versions before v2.7.0.

Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is enabled:
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx':
ecdsa-libcrypto.c:(.text+0x94): undefined reference to
`OPENSSL_init_ssl'
ecdsa-libcrypto.c:(.text+0x148): undefined reference to
`EC_GROUP_order_bits'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function
`ecdsa_check_signature.isra.0':
ecdsa-libcrypto.c:(.text+0x32c): undefined reference to `ECDSA_SIG_set0'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign':
ecdsa-libcrypto.c:(.text+0x42c): undefined reference to `ECDSA_SIG_get0'
ecdsa-libcrypto.c:(.text+0x443): undefined reference to `BN_bn2binpad'
ecdsa-libcrypto.c:(.text+0x455): undefined reference to `BN_bn2binpad'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_add_verify_data':
ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to
`EC_GROUP_order_bits'
ecdsa-libcrypto.c:(.text+0x642): undefined reference to
`EC_POINT_get_affine_coordinates'

Signed-off-by: Artem Panfilov 
---
 lib/ecdsa/ecdsa-libcrypto.c | 80 -
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/lib/ecdsa/ecdsa-libcrypto.c b/lib/ecdsa/ecdsa-libcrypto.c
index 1757a14562..50aa093acd 100644
--- a/lib/ecdsa/ecdsa-libcrypto.c
+++ b/lib/ecdsa/ecdsa-libcrypto.c
@@ -24,6 +24,70 @@
 #include 
 #include 
 
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+   (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
0x0207fL)
+#include 
+
+static int EC_GROUP_order_bits(const EC_GROUP *group)
+{
+   int ret = 0;
+   BIGNUM *order;
+
+   if (!group)
+   return ret;
+
+   order = BN_new();
+
+   if (!order) {
+   ERR_clear_error();
+   return ret;
+   }
+
+   if (!EC_GROUP_get_order(group, order, NULL)) {
+   ERR_clear_error();
+   BN_free(order);
+   return ret;
+   }
+
+   ret = BN_num_bits(order);
+   BN_free(order);
+   return ret;
+}
+
+static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM **pr, const 
BIGNUM **ps)
+{
+   if (pr != NULL)
+   *pr = sig->r;
+   if (ps != NULL)
+   *ps = sig->s;
+}
+
+static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s)
+{
+   if (r == NULL || s == NULL)
+   return 0;
+   BN_clear_free(sig->r);
+   BN_clear_free(sig->s);
+   sig->r = r;
+   sig->s = s;
+   return 1;
+}
+
+int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen)
+{
+   int n = BN_num_bytes(a);
+
+   if (n < 0 || n > tolen)
+   return -1;
+
+   memset(to, 0, tolen - n);
+   if (BN_bn2bin(a, to + tolen - n) < 0)
+   return -1;
+
+   return tolen;
+}
+#endif
+
 /* Image signing context for openssl-libcrypto */
 struct signer {
EVP_PKEY *evp_key;  /* Pointer to EVP_PKEY object */
@@ -34,9 +98,18 @@ struct signer {
 
 static int alloc_ctx(struct signer *ctx, const struct image_sign_info *info)
 {
+   int ret = 0;
+
memset(ctx, 0, sizeof(*ctx));
 
-   if (!OPENSSL_init_ssl(0, NULL)) {
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
+   ret = SSL_library_init();
+#else
+   ret = OPENSSL_init_ssl(0, NULL);
+#endif
+
+   if (!ret) {
fprintf(stderr, "Failure to init SSL library\n");
return -1;
}
@@ -285,7 +358,12 @@ static int do_add(struct signer *ctx, void *fdt, const 
char *key_node_name)
x = BN_new();
y = BN_new();
point = EC_KEY_get0_public_key(ctx->ecdsa_key);
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
+   EC_POINT_get_affine_coordinates_GFp(group, point, x, y, NULL);
+#else
EC_POINT_get_affine_coordinates(group, point, x, y, NULL);
+#endif
 
ret = fdt_setprop_string(fdt, key_node, "ecdsa,curve", curve_name);
if (ret < 0)
-- 
2.25.1

[PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Artem Panfilov]

Fix LibreSSL compilation for versions before v2.7.0.

Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is enabled:
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx':
ecdsa-libcrypto.c:(.text+0x94): undefined reference to
`OPENSSL_init_ssl'
ecdsa-libcrypto.c:(.text+0x148): undefined reference to
`EC_GROUP_order_bits'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function
`ecdsa_check_signature.isra.0':
ecdsa-libcrypto.c:(.text+0x32c): undefined reference to `ECDSA_SIG_set0'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign':
ecdsa-libcrypto.c:(.text+0x42c): undefined reference to `ECDSA_SIG_get0'
ecdsa-libcrypto.c:(.text+0x443): undefined reference to `BN_bn2binpad'
ecdsa-libcrypto.c:(.text+0x455): undefined reference to `BN_bn2binpad'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_add_verify_data':
ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to
`EC_GROUP_order_bits'
ecdsa-libcrypto.c:(.text+0x642): undefined reference to
`EC_POINT_get_affine_coordinates'

Signed-off-by: Artem Panfilov 
---
 lib/ecdsa/ecdsa-libcrypto.c | 80 -
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/lib/ecdsa/ecdsa-libcrypto.c b/lib/ecdsa/ecdsa-libcrypto.c
index 1757a14562..50aa093acd 100644
--- a/lib/ecdsa/ecdsa-libcrypto.c
+++ b/lib/ecdsa/ecdsa-libcrypto.c
@@ -24,6 +24,70 @@
 #include 
 #include 
 
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+   (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
0x0207fL)
+#include 
+
+static int EC_GROUP_order_bits(const EC_GROUP *group)
+{
+   int ret = 0;
+   BIGNUM *order;
+
+   if (!group)
+   return ret;
+
+   order = BN_new();
+
+   if (!order) {
+   ERR_clear_error();
+   return ret;
+   }
+
+   if (!EC_GROUP_get_order(group, order, NULL)) {
+   ERR_clear_error();
+   BN_free(order);
+   return ret;
+   }
+
+   ret = BN_num_bits(order);
+   BN_free(order);
+   return ret;
+}
+
+static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM **pr, const 
BIGNUM **ps)
+{
+   if (pr != NULL)
+   *pr = sig->r;
+   if (ps != NULL)
+   *ps = sig->s;
+}
+
+static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s)
+{
+   if (r == NULL || s == NULL)
+   return 0;
+   BN_clear_free(sig->r);
+   BN_clear_free(sig->s);
+   sig->r = r;
+   sig->s = s;
+   return 1;
+}
+
+int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen)
+{
+   int n = BN_num_bytes(a);
+
+   if (n < 0 || n > tolen)
+   return -1;
+
+   memset(to, 0, tolen - n);
+   if (BN_bn2bin(a, to + tolen - n) < 0)
+   return -1;
+
+   return tolen;
+}
+#endif
+
 /* Image signing context for openssl-libcrypto */
 struct signer {
EVP_PKEY *evp_key;  /* Pointer to EVP_PKEY object */
@@ -34,9 +98,18 @@ struct signer {
 
 static int alloc_ctx(struct signer *ctx, const struct image_sign_info *info)
 {
+   int ret = 0;
+
memset(ctx, 0, sizeof(*ctx));
 
-   if (!OPENSSL_init_ssl(0, NULL)) {
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
+   ret = SSL_library_init();
+#else
+   ret = OPENSSL_init_ssl(0, NULL);
+#endif
+
+   if (!ret) {
fprintf(stderr, "Failure to init SSL library\n");
return -1;
}
@@ -285,7 +358,12 @@ static int do_add(struct signer *ctx, void *fdt, const 
char *key_node_name)
x = BN_new();
y = BN_new();
point = EC_KEY_get0_public_key(ctx->ecdsa_key);
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
+   EC_POINT_get_affine_coordinates_GFp(group, point, x, y, NULL);
+#else
EC_POINT_get_affine_coordinates(group, point, x, y, NULL);
+#endif
 
ret = fdt_setprop_string(fdt, key_node, "ecdsa,curve", curve_name);
if (ret < 0)
-- 
2.25.1

Re: u-boot saveenv to redundant fat does not persist env

[Pierre-Alexis Ciavaldini]

Hi,

When I did, mender complained about it :
include/config_mender.h:41:3: error: #error CONFIG_SYS_REDUNDAND_ENVIRONMENT is 
required for Mender to work. Make sure that: 1) All the instructions at https:
41 | # error CONFIG_SYS_REDUNDAND_ENVIRONMENT is required for Mender to work. 
Make sure that: 1) All the instructions at 
https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot
 have been followed. 2) All required layers are included in bblayers.conf, 
including any board specific layers such as meta-mender-. Check also 
https://docs.mender.io/troubleshoot/yocto-project-build for Known Issues when 
upgrading.

I guess I could disable the check, but even so I'm not sure it would work as 
uboot.env does not get written ?
Thank you,
PA

On Jul 28 2021, at 5:23 pm, Tom Rini  wrote:
> On Wed, Jul 28, 2021 at 04:41:56PM +0200, Pierre-Alexis Ciavaldini wrote:
>
> > Hi Tom,
> >
> > /etc/fw_env.config has this contents:
> > /boot/u-boot/uboot.env 0x 0x4000
> > /boot/u-boot/uboot-redund.env 0x 0x4000
>
> And what if you turn off redundant environment support? Mender does
> strongly recommend that, but you can just turn it off. Does that get
> you working environment from file and fw_setenv/fw_printenv working?
>
> >
> > Thank you,
> > PA
> >
> > On Jul 28 2021, at 4:39 pm, Tom Rini  wrote:
> > > On Tue, Jul 27, 2021 at 04:44:20PM +0200, Pierre-Alexis Ciavaldini wrote:
> > > > Hi,
> > > >
> > > > I'm trying to integrate u-boot in our project that is a custom scripted 
> > > > build without yocto, for use with mender.
> > > > The complete discussion can be found here : 
> > > > https://hub.mender.io/t/pi3-usb-boot-support/595/54?u=peac
> > > > The problem is that when issuing saveenv in u-boot, it responds with 
> > > > "Saving Environment to FAT... OK" but then using fw_printenv in the 
> > > > booted linux, does not show saved variables.
> > > >
> > > > The system currently boots because i've tricked it by getting the 
> > > > compiled-in env over uart (env print -a) and made a uboot.env using 
> > > > mkenvimage manually to enable fw_printenv to work.
> > > > I've noticed that when deleting "/boot/u-boot/uboot.env", u-boot's 
> > > > saveenv does not re-create it, so it seems to me that saveenv does not 
> > > > write uboot.env.
> > > > Here's the complete project files : 
> > > > https://git.iostud.io/cosmos/u-boot/-/tree/cosmos
> > > > relevant modified files are:
> > > > - configs/rpi_4_32b_defconfig
> > > > - include/config_mender_defines.h
> > > > - include/env_mender.h
> > > > - include/configs/rpi.h
> > > > - include/env_default.h
> > > > - include/config_mender.h
> > > >
> > > > Any help or investigating direction would be greatly appreciated.
> > >
> > > What does your /etc/fw_env.config file look like?
> > > --
> > > Tom
> > >
> >
>
> --
> Tom
>

Re: u-boot saveenv to redundant fat does not persist env

[Pierre-Alexis Ciavaldini]

Hi Tom,

/etc/fw_env.config has this contents:
/boot/u-boot/uboot.env 0x 0x4000
/boot/u-boot/uboot-redund.env 0x 0x4000

Thank you,
PA

On Jul 28 2021, at 4:39 pm, Tom Rini  wrote:
> On Tue, Jul 27, 2021 at 04:44:20PM +0200, Pierre-Alexis Ciavaldini wrote:
> > Hi,
> >
> > I'm trying to integrate u-boot in our project that is a custom scripted 
> > build without yocto, for use with mender.
> > The complete discussion can be found here : 
> > https://hub.mender.io/t/pi3-usb-boot-support/595/54?u=peac
> > The problem is that when issuing saveenv in u-boot, it responds with 
> > "Saving Environment to FAT... OK" but then using fw_printenv in the booted 
> > linux, does not show saved variables.
> >
> > The system currently boots because i've tricked it by getting the 
> > compiled-in env over uart (env print -a) and made a uboot.env using 
> > mkenvimage manually to enable fw_printenv to work.
> > I've noticed that when deleting "/boot/u-boot/uboot.env", u-boot's saveenv 
> > does not re-create it, so it seems to me that saveenv does not write 
> > uboot.env.
> > Here's the complete project files : 
> > https://git.iostud.io/cosmos/u-boot/-/tree/cosmos
> > relevant modified files are:
> > - configs/rpi_4_32b_defconfig
> > - include/config_mender_defines.h
> > - include/env_mender.h
> > - include/configs/rpi.h
> > - include/env_default.h
> > - include/config_mender.h
> >
> > Any help or investigating direction would be greatly appreciated.
>
> What does your /etc/fw_env.config file look like?
> --
> Tom
>

Re: [PATCH v2 5/9] Allow efi_loader header to be included always

[Tom Rini]

On Fri, Jul 02, 2021 at 12:36:16PM -0600, Simon Glass wrote:

> It is bad practice to put function declarations behind an #ifdef since
> it makes it impossible to use IS_ENABLED() in the C code. The main reason
> for doing this is when an empty static inline function is desired when
> the feature is disabled.
> 
> To this end, this header provides two different versions of various
> functions and macros. Collect them together in one place for clarity.
> Allow all the rest of the header to be included, regardless of the
> setting of EFI_LOADER.
> 
> With the inclusion of blk.h the 'struct blk_desc' declaration is
> unnecessary. Drop it while we are here.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 6/9] lib: Create a new Kconfig option for charset conversion

[Tom Rini]

On Fri, Jul 02, 2021 at 12:36:17PM -0600, Simon Glass wrote:

> Rather than looking at two KConfig options in the Makefile, create a new
> Kconfig option for compiling lib/charset.c
> 
> Enable it for UFS also, which needs this support.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 4/9] Use LIB_UUID with ACPIGEN and FS_BTRFS

[Tom Rini]

On Fri, Jul 02, 2021 at 12:36:15PM -0600, Simon Glass wrote:

> Since the ACPI-generation code makes use of UUIDs we typically need to
> enabled UUID support for it to build. Add a new Kconfig condition.
> 
> Use it for BTRFS also.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 3/9] disk: Tidy up #ifdefs in part_efi

[Tom Rini]

On Fri, Jul 02, 2021 at 12:36:14PM -0600, Simon Glass wrote:

> This file does not correctly handle the various cases, sometimes
> producing warnings about partition_basic_data_guid being defined but not
> used. Fix it.
> 
> There was some discussion about adjusting Kconfig or making
> HAVE_BLOCK_DEVICE a prerequisite for PARTITIONS, but apparently this is
> not feasible. Such changes can be undertaken separate from the goal of
> this series.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/9] Makefile: Drop include/asm directory as well as symlink

[Tom Rini]

On Fri, Jul 02, 2021 at 12:36:13PM -0600, Simon Glass wrote:

> At present when using 'make mrproper' on an out-of-tree build, a warning
> is shown about include/asm being a directory. With old versions of U-Boot
> it is a file, but more recently it has become a directory.
> 
> Remove this directory first, since that covers both cases.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 01/17] README: Fix hyphenation in the directory docs

[Tom Rini]

On Sat, Jul 10, 2021 at 09:14:21PM -0600, Simon Glass wrote:

> Hyphens are missing in various places where the intent is to create an
> adjective. Fix it.
> 
> Signed-off-by: Simon Glass 

For the series, applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Tom Rini]

On Thu, Jul 29, 2021 at 01:29:35AM +0300, Artem Panfilov wrote:
> 
> On 28.07.2021 23:07, Tom Rini wrote:
> > There is a fine line at least that I'm willing to walk in terms of
> > supporting ancient OSes directly and also not making things overly
> > complicated in our own tree.  That said, openssl tends to be one of the
> > ones where it does get hard to support old versions.  LibreSSL 2.7.5 was
> > released December 15th, 2018 and is the end of the 2.7.x line it seems.
> >
> > I'm interested to hear what the case is where the right call is the say
> > you're building modern software for real world use against such old
> > libraries.
> Hi Tom,
> I have a specific test case where I test if it's still possible to
> build upstream master u-boot on our infrastructure (progression testing).
> I also test runtime on our boards.
> 
> I understand that nowadays everyone uses docker container,
> but ​we have limited docker nodes right now on our site.
> 
> If you don't want to support OpenSSL < 1.1.0 and do not test it,
> then I suggest dropping it all over the tree because it doesn't
> make sense and looks misleading with such a partial solution.

Part of the question is then, were you enabling the SSL-related parts
before this change?  Or did the way the code is now being
enabled/disabled trigger this now being enabled when it wasn't before?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: bootm: Disable LMB reservation for command line and board info on arm64

[Jan Kiszka]

On 21.07.21 08:08, Jan Kiszka wrote:
> On 21.07.21 01:34, Marek Vasut wrote:
>> On 7/20/21 11:08 AM, Jan Kiszka wrote:
>> [...]
 diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
 index f60ee3a7e6..23b99a541c 100644
 --- a/arch/arm/lib/bootm.c
 +++ b/arch/arm/lib/bootm.c
 @@ -43,6 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;
     static struct tag *params;
   +#ifndef CONFIG_ARM64
   static ulong get_sp(void)
   {
   ulong ret;
 @@ -86,6 +87,7 @@ void arch_lmb_reserve(struct lmb *lmb)
   break;
   }
   }
 +#endif
     __weak void board_quiesce_devices(void)
   {

>>> This causes troubles for [1], but I have no clue yet, what is happening.
>>> Without the patch, we start like this:
>>>
>>> Found U-Boot script /boot/boot.scr
>>> 889 bytes read in 21 ms (41 KiB/s)
>>> ## Executing script at 8300
>>> Loading /usr/lib/linux-image-4.19.94/ti/k3-am6548-iot2050-advanced.dtb...
>>> 78306 bytes read in 25 ms (3 MiB/s)
>>> Loading /boot/vmlinux-4.19.94...
>>> 13537288 bytes read in 107 ms (120.7 MiB/s)
>>> ## Flattened Device Tree blob at 8200
>>>     Booting using the fdt blob at 0x8200
>>>     Loading Device Tree to fdefa000, end fdf101e1 ... OK
>>>
>>> Starting kernel ...
>>>
>>>
>>> With the patch applied, I'm getting stuck like this:
>>>
>>> Found U-Boot script /boot/boot.scr
>>> 889 bytes read in 21 ms (41 KiB/s)
>>> ## Executing script at 8300
>>> Loading /usr/lib/linux-image-4.19.94/ti/k3-am6548-iot2050-advanced.dtb...
>>> 78306 bytes read in 25 ms (3 MiB/s)
>>> Loading /boot/vmlinux-4.19.94...
>>> 13537288 bytes read in 109 ms (118.4 MiB/s)
>>> ## Flattened Device Tree blob at 8200
>>>     Booting using the fdt blob at 0x8200
>>>     Loading Device Tree to fffe9000, end f1e1 ...
>>>
>>>
>>> Obviously, the DT target adress changed, possibly to an
>>> unsupported/reserved address. But I do not understand the mechanics
>>> behind all this yet. Any hints welcome on what goes wrong here and
>>> whether something needs to be adjusted in our board settings.
>>
>> Can you share the output of bdinfo on this board ?
> 
> Sure (with your commit reverted for now):
> 
> IOT2050> bdinfo
> boot_params = 0x
> DRAM bank   = 0x
> -> start= 0x8000
> -> size = 0x8000
> flashstart  = 0x
> flashsize   = 0x
> flashoffset = 0x
> baudrate= 115200 bps
> relocaddr   = 0xfff2d000
> reloc off   = 0x7f72d000
> Build   = 64-bit
> current eth = unknown
> ethaddr = 70:77:77:77:57:70
> IP addr = 
> fdt_blob= 0xfdef9f10
> new_fdt = 0xfdef9f10
> fdt_size= 0x00012ea0
> lmb_dump_all:
>  memory.cnt  = 0x1
>  memory[0]  [0x8000-0x], 0x8000 bytes flags: 0
>  reserved.cnt  = 0x2
>  reserved[0][0x9e80-0xa21f], 0x03a0 bytes flags: 4
>  reserved[1][0xfdef86c0-0x], 0x02107940 bytes flags: 0
> arch_number = 0x
> TLB addr= 0x
> irq_sp  = 0xfdef9b20
> sp start= 0xfdef9b20
> Early malloc usage: 23c8 / 8000
> 
> 
> There is some "TLB" block apparently overlapping when we move the DT.
> What's this? Looking at the code, not a TLB with the usual meaning but
> rather the page table U-Boot uses for itself, right?
> 
> Were we just lucky so far with side effects of the LMB reservation on
> this platform (and I suspect that it affect k3 in general, not only our
> board)?
> 

Just rebased over master, kept Marek's change, and rerun bdinfo:

IOT2050> bdinfo
boot_params = 0x
DRAM bank   = 0x
-> start= 0x8000
-> size = 0x4000
flashstart  = 0x
flashsize   = 0x
flashoffset = 0x
baudrate= 115200 bps
relocaddr   = 0xbff41000
reloc off   = 0x3f741000
Build   = 64-bit
fdt_blob= 0xbdf0d750
new_fdt = 0xbdf0d750
fdt_size= 0x00013660
lmb_dump_all:
 memory.cnt  = 0x1
 memory[0]  [0x8000-0xbfff], 0x4000 bytes flags: 0
 reserved.cnt  = 0x1
 reserved[0][0x9e80-0xa21f], 0x03a0 bytes flags: 4
arch_number = 0x
TLB addr= 0xbfff
irq_sp  = 0xbdf0d360
sp start= 0xbdf0d360
Early malloc usage: 23c8 / 8000
IOT2050> boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
911 bytes read in 28 ms (31.3 KiB/s)
## Executing script at 8300
Loading /usr/lib/linux-image-4.19.94/ti/k3-am6528-iot2050-basic.dtb...
77409 bytes read in 34 ms (2.2 MiB/s)
Loading /boot/vmlinux-4.19.94...
13537288 bytes read in 587 ms (22 MiB/s)
## Flattened Device Tree blob at 8200
   Booting using the fdt blob at 0x8200
   Loading Device Tree to bffea000, end 

Re: [PATCH v2 6/9] sandbox: add config for efi capsule authentication test

[Heinrich Schuchardt]

On 7/27/21 11:10 AM, AKASHI Takahiro wrote:

This new configuration, which was derived from sandbox_defconfig, will be
used solely to run efi capsule authentication test as the test requires
a public key (esl file) to be embedded in U-Boot binary.

Signed-off-by: AKASHI Takahiro 
---
  configs/sandbox_capsule_auth_defconfig | 307 +
  1 file changed, 307 insertions(+)
  create mode 100644 configs/sandbox_capsule_auth_defconfig

diff --git a/configs/sandbox_capsule_auth_defconfig 
b/configs/sandbox_capsule_auth_defconfig
new file mode 100644
index ..8e0ffb1a6995
--- /dev/null
+++ b/configs/sandbox_capsule_auth_defconfig
@@ -0,0 +1,307 @@
+CONFIG_SYS_TEXT_BASE=0
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SYS_MEMTEST_START=0x0010
+CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="sandbox"
+CONFIG_PRE_CON_BUF_ADDR=0xf
+CONFIG_BOOTSTAGE_STASH_ADDR=0x0
+CONFIG_DEBUG_UART=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_RSASSA_PSS=y
+CONFIG_FIT_CIPHER=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_BOOTSTAGE=y
+CONFIG_BOOTSTAGE_REPORT=y
+CONFIG_BOOTSTAGE_FDT=y
+CONFIG_BOOTSTAGE_STASH=y
+CONFIG_BOOTSTAGE_STASH_SIZE=0x4096
+CONFIG_CONSOLE_RECORD=y
+CONFIG_CONSOLE_RECORD_OUT_SIZE=0x1000
+CONFIG_PRE_CONSOLE_BUFFER=y
+CONFIG_LOG=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_MISC_INIT_F=y
+CONFIG_STACKPROTECTOR=y
+CONFIG_ANDROID_AB=y
+CONFIG_CMD_CPU=y
+CONFIG_CMD_LICENSE=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_BOOTEFI_HELLO=y
+CONFIG_CMD_ABOOTIMG=y
+# CONFIG_CMD_ELF is not set
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_ERASEENV=y
+CONFIG_CMD_ENV_CALLBACK=y
+CONFIG_CMD_ENV_FLAGS=y
+CONFIG_CMD_NVEDIT_EFI=y
+CONFIG_CMD_NVEDIT_INFO=y
+CONFIG_CMD_NVEDIT_LOAD=y
+CONFIG_CMD_NVEDIT_SELECT=y
+CONFIG_LOOPW=y
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEM_SEARCH=y
+CONFIG_CMD_MX_CYCLIC=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_BIND=y
+CONFIG_CMD_DEMO=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_PWM=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_GPT_RENAME=y
+CONFIG_CMD_IDE=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_LSBLK=y
+CONFIG_CMD_MUX=y
+CONFIG_CMD_OSD=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_READ=y
+CONFIG_CMD_REMOTEPROC=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_AXI=y
+CONFIG_CMD_AB_SELECT=y
+CONFIG_BOOTP_DNS2=y
+CONFIG_CMD_PCAP=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_TFTPSRV=y
+CONFIG_CMD_RARP=y
+CONFIG_CMD_CDP=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_ETHSW=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_BOOTCOUNT=y
+CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_RTC=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_SOUND=y
+CONFIG_CMD_QFW=y
+CONFIG_CMD_PSTORE=y
+CONFIG_CMD_PSTORE_MEM_ADDR=0x300
+CONFIG_CMD_BOOTSTAGE=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_AES=y
+CONFIG_CMD_TPM=y
+CONFIG_CMD_TPM_TEST=y
+CONFIG_CMD_BTRFS=y
+CONFIG_CMD_CBFS=y
+CONFIG_CMD_CRAMFS=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_SQUASHFS=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_STACKPROTECTOR_TEST=y
+CONFIG_MAC_PARTITION=y
+CONFIG_AMIGA_PARTITION=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_OF_HOSTFILE=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_ENV_IS_IN_EXT4=y
+CONFIG_ENV_EXT4_INTERFACE="host"
+CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
+CONFIG_ENV_IMPORT_FDT=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_NETCONSOLE=y
+CONFIG_IP_DEFRAG=y
+CONFIG_DM_DMA=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_DEVRES=y
+CONFIG_DEBUG_DEVRES=y
+CONFIG_SIMPLE_PM_BUS=y
+CONFIG_ADC=y
+CONFIG_ADC_SANDBOX=y
+CONFIG_AXI=y
+CONFIG_AXI_SANDBOX=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_DM_BOOTCOUNT=y
+CONFIG_DM_BOOTCOUNT_RTC=y
+CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
+CONFIG_BUTTON=y
+CONFIG_BUTTON_ADC=y
+CONFIG_BUTTON_GPIO=y
+CONFIG_CLK=y
+CONFIG_CLK_COMPOSITE_CCF=y
+CONFIG_CLK_SCMI=y
+CONFIG_CLK_K210=y
+CONFIG_CLK_K210_SET_RATE=y
+CONFIG_SANDBOX_CLK_CCF=y
+CONFIG_CPU=y
+CONFIG_DM_DEMO=y
+CONFIG_DM_DEMO_SIMPLE=y
+CONFIG_DM_DEMO_SHAPE=y
+CONFIG_DFU_SF=y
+CONFIG_DMA=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_SANDBOX_DMA=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_GPIO_HOG=y
+CONFIG_DM_GPIO_LOOKUP_LABEL=y
+CONFIG_PM8916_GPIO=y
+CONFIG_SANDBOX_GPIO=y
+CONFIG_DM_HWSPINLOCK=y
+CONFIG_HWSPINLOCK_SANDBOX=y
+CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I2C_CROS_EC_LDO=y
+CONFIG_DM_I2C_GPIO=y
+CONFIG_SYS_I2C_SANDBOX=y
+CONFIG_I2C_MUX=y
+CONFIG_SPL_I2C_MUX=y
+CONFIG_I2C_ARB_GPIO_CHALLENGE=y
+CONFIG_CROS_EC_KEYB=y
+CONFIG_I8042_KEYB=y
+CONFIG_LED=y
+CONFIG_LED_BLINK=y
+CONFIG_LED_GPIO=y
+CONFIG_DM_MAILBOX=y
+CONFIG_SANDBOX_MBOX=y
+CONFIG_MISC=y
+CONFIG_CROS_EC=y
+CONFIG_CROS_EC_I2C=y
+CONFIG_CROS_EC_LPC=y
+CONFIG_CROS_EC_SANDBOX=y
+CONFIG_CROS_EC_SPI=y
+CONFIG_P2SB=y
+CONFIG_PWRSEQ=y
+CONFIG_SPL_PWRSEQ=y
+CONFIG_I2C_EEPROM=y
+CONFIG_MMC_PCI=y
+CONFIG_MMC_SANDBOX=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MTD=y
+CONFIG_SPI_FLASH_SANDBOX=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_SST=y

Re: [PATCH] lib: rsa: Extract public key from private key if keyfile argument is used

[Tom Rini]

On Wed, Jul 28, 2021 at 08:17:37PM +, Chan, Donald wrote:

> If the 'keyfile' (-G) argument is used, there is little value to require
> 'keydir' (-k) argument since the public key can also be extracted from the
> private key itself.
> 
> Signed-off-by: Donald Chan 
> ---
>  lib/rsa/rsa-sign.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)

This is again corrupted.  I think you may need to get git send-email
configured to work.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Tom Rini]

On Wed, Jul 28, 2021 at 03:00:44PM -0500, Alex G. wrote:
> Hi Artem,
> 
> I'm re-adding the u-boot mailing list to the CC field, as I see your email
> contains no sensitive information.
> 
> On 7/28/21 2:30 PM, Artem Panfilov wrote:
> > We have broken CI builds on your bare-metal CentOS 7 servers with latest
> > master. I think it is good reason to have  a support. Our corporate
> > clients have CentOS 7 too.
> 
> I thought we solved problems associated with bare builds on ancient OSes by
> using containerized builds. There's is CI infrastructure based on this on
> source.denx.de that uses docker. As things change, and we eventually move to
> GNU TLS, a lot more things might break for old build hosts. I believe it's
> worth looking at containerized builds.
> 
> Given that a solution exists for your problem, I think the argument for this
> patch quite weak.

There is a fine line at least that I'm willing to walk in terms of
supporting ancient OSes directly and also not making things overly
complicated in our own tree.  That said, openssl tends to be one of the
ones where it does get hard to support old versions.  LibreSSL 2.7.5 was
released December 15th, 2018 and is the end of the 2.7.x line it seems.

I'm interested to hear what the case is where the right call is the say
you're building modern software for real world use against such old
libraries.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Alex G.]

Hi Artem,

I'm re-adding the u-boot mailing list to the CC field, as I see your 
email contains no sensitive information.


On 7/28/21 2:30 PM, Artem Panfilov wrote:
We have broken CI builds on your bare-metal CentOS 7 servers with latest 
master. I think it is good reason to have  a support. Our corporate 
clients have CentOS 7 too.


I thought we solved problems associated with bare builds on ancient OSes 
by using containerized builds. There's is CI infrastructure based on 
this on source.denx.de that uses docker. As things change, and we 
eventually move to GNU TLS, a lot more things might break for old build 
hosts. I believe it's worth looking at containerized builds.


Given that a solution exists for your problem, I think the argument for 
this patch quite weak.


There is no nice way to handle openssl difference. You could check other 
commits related to openssl compatibility. They all looks ugly.


Another solution is to disable CONFIG_TOOLS_LIBCRYPTO by default that 
broke our builds.


Do you need cryptographic features in mkimage? If not just disable 
TOOLS_LIBCRYPTO in your builds.


Alex


Best regards,
Artem

ср, 28 июл. 2021 г., 22:16 Alex G. >:




On 7/28/21 1:10 PM, Artem Panfilov wrote:
 > Fix LibreSSL compilation for versions before v2.7.0.
 >
 > Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is
enabled:
 > tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx':
 > ecdsa-libcrypto.c:(.text+0x94): undefined reference to
 > `OPENSSL_init_ssl'
 > ecdsa-libcrypto.c:(.text+0x148): undefined reference to
 > `EC_GROUP_order_bits'
 > tools/lib/ecdsa/ecdsa-libcrypto.o: In function
 > `ecdsa_check_signature.isra.0':
 > ecdsa-libcrypto.c:(.text+0x32c): undefined reference to
`ECDSA_SIG_set0'
 > tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign':
 > ecdsa-libcrypto.c:(.text+0x42c): undefined reference to
`ECDSA_SIG_get0'
 > ecdsa-libcrypto.c:(.text+0x443): undefined reference to
`BN_bn2binpad'
 > ecdsa-libcrypto.c:(.text+0x455): undefined reference to
`BN_bn2binpad'
 > tools/lib/ecdsa/ecdsa-libcrypto.o: In function
`ecdsa_add_verify_data':
 > ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to
 > `EC_GROUP_order_bits'
 > ecdsa-libcrypto.c:(.text+0x642): undefined reference to
 > `EC_POINT_get_affine_coordinates'
 >
 > Signed-off-by: Artem Panfilov mailto:panfilov.art...@gmail.com>>
 > ---
 >   lib/ecdsa/ecdsa-libcrypto.c | 80
-
 >   1 file changed, 79 insertions(+), 1 deletion(-)
 >
 > diff --git a/lib/ecdsa/ecdsa-libcrypto.c
b/lib/ecdsa/ecdsa-libcrypto.c
 > index 1757a14562..50aa093acd 100644
 > --- a/lib/ecdsa/ecdsa-libcrypto.c
 > +++ b/lib/ecdsa/ecdsa-libcrypto.c
 > @@ -24,6 +24,70 @@
 >   #include 
 >   #include 
 >
 > +#if OPENSSL_VERSION_NUMBER < 0x1010L || \
 > +     (defined(LIBRESSL_VERSION_NUMBER) &&
LIBRESSL_VERSION_NUMBER < 0x0207fL)


Is there a reasonable use case for supporting an external library that
is more than three years old at this point?

Otherwise NAK, as such #ifdefs don't really help with readability. I
think Simon will agree here.

There's also the issue of deciding what version we have at compile
time,
which ignores the dynamic linking nature of .so libs. This leads into
soname versioning territory. Let's not go there.

Alex

 > +#include 
 > +
 > +static int EC_GROUP_order_bits(const EC_GROUP *group)
 > +{
 > +     int ret = 0;
 > +     BIGNUM *order;
 > +
 > +     if (!group)
 > +             return ret;
 > +
 > +     order = BN_new();
 > +
 > +     if (!order) {
 > +             ERR_clear_error();
 > +             return ret;
 > +     }
 > +
 > +     if (!EC_GROUP_get_order(group, order, NULL)) {
 > +             ERR_clear_error();
 > +             BN_free(order);
 > +             return ret;
 > +     }
 > +
 > +     ret = BN_num_bits(order);
 > +     BN_free(order);
 > +     return ret;
 > +}
 > +
 > +static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM
**pr, const BIGNUM **ps)
 > +{
 > +     if (pr != NULL)
 > +             *pr = sig->r;
 > +     if (ps != NULL)
 > +             *ps = sig->s;
 > +}
 > +
 > +static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s)
 > +{
 > +     if (r == NULL || s == NULL)
 > +             return 0;
 > +     BN_clear_free(sig->r);
 > +     BN_clear_free(sig->s);
 > +     sig->r = r;
 > +     sig->s = s;
 > +     return 1;
 > +}
 > +
 > +int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen)
 > +{
 > +     int n = BN_num_bytes(a);
 > +
 > +     if (n < 0 || n > tolen)
 > +    

Re: U-Boot boards needing CONFIG_DM migration

[Tom Rini]

On Wed, Jul 28, 2021 at 04:09:48PM -0300, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Wed, Jul 28, 2021 at 3:58 PM Stefano Babic  wrote:
> 
> > Its status was erroneously set in patchwork - I'll pick it up.
> 
> Thanks.  Peter Robinson's series to convert warp is also missing in master:
> https://www.mail-archive.com/u-boot@lists.denx.de/msg403736.html

I thought I had seen something about warp too.  Any idea what happened
in the imx tree?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0

[Alex G.]

On 7/28/21 1:10 PM, Artem Panfilov wrote:

Fix LibreSSL compilation for versions before v2.7.0.

Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is enabled:
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx':
ecdsa-libcrypto.c:(.text+0x94): undefined reference to
`OPENSSL_init_ssl'
ecdsa-libcrypto.c:(.text+0x148): undefined reference to
`EC_GROUP_order_bits'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function
`ecdsa_check_signature.isra.0':
ecdsa-libcrypto.c:(.text+0x32c): undefined reference to `ECDSA_SIG_set0'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign':
ecdsa-libcrypto.c:(.text+0x42c): undefined reference to `ECDSA_SIG_get0'
ecdsa-libcrypto.c:(.text+0x443): undefined reference to `BN_bn2binpad'
ecdsa-libcrypto.c:(.text+0x455): undefined reference to `BN_bn2binpad'
tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_add_verify_data':
ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to
`EC_GROUP_order_bits'
ecdsa-libcrypto.c:(.text+0x642): undefined reference to
`EC_POINT_get_affine_coordinates'

Signed-off-by: Artem Panfilov 
---
  lib/ecdsa/ecdsa-libcrypto.c | 80 -
  1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/lib/ecdsa/ecdsa-libcrypto.c b/lib/ecdsa/ecdsa-libcrypto.c
index 1757a14562..50aa093acd 100644
--- a/lib/ecdsa/ecdsa-libcrypto.c
+++ b/lib/ecdsa/ecdsa-libcrypto.c
@@ -24,6 +24,70 @@
  #include 
  #include 
  
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \

+   (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
0x0207fL)



Is there a reasonable use case for supporting an external library that 
is more than three years old at this point?


Otherwise NAK, as such #ifdefs don't really help with readability. I 
think Simon will agree here.


There's also the issue of deciding what version we have at compile time, 
which ignores the dynamic linking nature of .so libs. This leads into 
soname versioning territory. Let's not go there.


Alex


+#include 
+
+static int EC_GROUP_order_bits(const EC_GROUP *group)
+{
+   int ret = 0;
+   BIGNUM *order;
+
+   if (!group)
+   return ret;
+
+   order = BN_new();
+
+   if (!order) {
+   ERR_clear_error();
+   return ret;
+   }
+
+   if (!EC_GROUP_get_order(group, order, NULL)) {
+   ERR_clear_error();
+   BN_free(order);
+   return ret;
+   }
+
+   ret = BN_num_bits(order);
+   BN_free(order);
+   return ret;
+}
+
+static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM **pr, const 
BIGNUM **ps)
+{
+   if (pr != NULL)
+   *pr = sig->r;
+   if (ps != NULL)
+   *ps = sig->s;
+}
+
+static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s)
+{
+   if (r == NULL || s == NULL)
+   return 0;
+   BN_clear_free(sig->r);
+   BN_clear_free(sig->s);
+   sig->r = r;
+   sig->s = s;
+   return 1;
+}
+
+int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen)
+{
+   int n = BN_num_bytes(a);
+
+   if (n < 0 || n > tolen)
+   return -1;
+
+   memset(to, 0, tolen - n);
+   if (BN_bn2bin(a, to + tolen - n) < 0)
+   return -1;
+
+   return tolen;
+}
+#endif
+
  /* Image signing context for openssl-libcrypto */
  struct signer {
EVP_PKEY *evp_key;  /* Pointer to EVP_PKEY object */
@@ -34,9 +98,18 @@ struct signer {
  
  static int alloc_ctx(struct signer *ctx, const struct image_sign_info *info)

  {
+   int ret = 0;
+
memset(ctx, 0, sizeof(*ctx));
  
-	if (!OPENSSL_init_ssl(0, NULL)) {

+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
+   ret = SSL_library_init();
+#else
+   ret = OPENSSL_init_ssl(0, NULL);
+#endif
+
+   if (!ret) {
fprintf(stderr, "Failure to init SSL library\n");
return -1;
}
@@ -285,7 +358,12 @@ static int do_add(struct signer *ctx, void *fdt, const 
char *key_node_name)
x = BN_new();
y = BN_new();
point = EC_KEY_get0_public_key(ctx->ecdsa_key);
+#if OPENSSL_VERSION_NUMBER < 0x1010L || \
+(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x0207fL)
+   EC_POINT_get_affine_coordinates_GFp(group, point, x, y, NULL);
+#else
EC_POINT_get_affine_coordinates(group, point, x, y, NULL);
+#endif
  
  	ret = fdt_setprop_string(fdt, key_node, "ecdsa,curve", curve_name);

if (ret < 0)

Re: U-Boot boards needing CONFIG_DM migration

[Fabio Estevam]

Hi Stefano,

On Wed, Jul 28, 2021 at 3:58 PM Stefano Babic  wrote:

> Its status was erroneously set in patchwork - I'll pick it up.

Thanks.  Peter Robinson's series to convert warp is also missing in master:
https://www.mail-archive.com/u-boot@lists.denx.de/msg403736.html

Thanks

Re: U-Boot boards needing CONFIG_DM migration

[Stefano Babic]

On 28.07.21 19:40, Fabio Estevam wrote:

Hi Tom,

On Wed, Jul 28, 2021 at 2:04 PM Tom Rini  wrote:


Hey all,

I'm sending this email to people that are either listed as maintainers
for the following boards, or have shown interest in that general area
before.  These boards are the only ones left in tree right now that do
not have CONFIG_DM enabled:
flea3 aspenite zmx25 mx28evk mx28evk_auart_console mx28evk_nand


I have sent the mx28evk DM conversion series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg398398.html

and

https://www.mail-archive.com/u-boot@lists.denx.de/msg398399.html

but it seems it got missed.


Its status was erroneously set in patchwork - I'll pick it up.


Could you or Stefano please apply it?






I plan to support only mx28evk_defconfig and I am fine to remove the
other mx28evk defconfig variants.

Thanks



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
=

Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader

[Simon Glass]

Hi Tom,


On Wed, 28 Jul 2021 at 11:37, Tom Rini  wrote:
>
> On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 28 Jul 2021 at 08:35, Tom Rini  wrote:
> > >
> > > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 11 Jul 2021 at 20:19, Simon Glass  wrote:
> > > > >
> > > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > > no standard way of implementing it for a board. At present the various
> > > > > required pieces must be built up separately, to produce a working
> > > > > implementation. In particular, there is no built-in support for 
> > > > > selecting
> > > > > A/B boot or recovery mode.
> > > > >
> > > > > This series introduces VPL, a verified program loader. Its purpose is 
> > > > > to
> > > > > run the verified-boot process and decide which SPL binary should be 
> > > > > run.
> > > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > > verified boot. So far, only the phase itself is added along with some
> > > > > Kconfig options. The next step is to create a build for sandbox.
> > > > >
> > > > > Changes in v3:
> > > > > - Move VPL Kconfig options to a separate patch
> > > > > - Add full build support for VPL
> > > > >
> > > > > Changes in v2:
> > > > > - Add some more VPL Kconfig options
> > > > >
> > > > > Simon Glass (7):
> > > > >   doc: Convert SPL documentation to ReST
> > > > >   doc: Expand SPL docs to explain the phase and config
> > > > >   test: Tidy up test building with SPL
> > > > >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > >   binman: Add VPL support
> > > > >   Introduce Verifying Program Loader (VPL)
> > > > >   vpl: Add Kconfig options for VPL
> > > >
> > > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > > if that helps.
> > >
> > > Perhaps some of these general questions would be answered with seeing an
> > > implementation for not just sandbox, but real hardware too.  But I'm
> > > missing what this provides exactly that we can't do already, or that
> > > would justify a whole new stage rather than just some updates within
> > > existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
> > > Checking in with a TPM to confirm good measurements?  Having written
> > > that out, now I really do want to see this implemented on real hardware
> > > much more so than sandbox.
> >
> > Yes it was actually implemented on coral, an x86 Chromebook which is
> > in-tree. I have various patches to come but the docs are at [1]
> >
> > The core reason for it is that SPL sets up SDRAM (and perhaps other
> > things) so needs to be updateable, so we cannot boot the vboot logic
> > in SPL. TPL often has very small size limits so it is difficult to put
> > it in there. I am thinking that VPL can be an optional phase used only
> > if verified boot is enabled. That makes it easy since it has a defined
> > purpose which can be enabled/disabled.
> >
> > BTW in doing this I wonder whether we should look again at the
> > SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> >
> > Regards,
> > Simon
> >
> > [1] 
> > https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
>
> There's always a "no updates before HERE" line to draw, as you need a
> fall-back option.  Since you mention SDRAM, does that mean both TPL and
> VPL are running in SRAM/similar space?  If so, why isn't this just part
> of TPL, for when you have "a lot" of pre-SDRAM memory to use?

It depends on the architecture. For coral (and other modern x86
devices) there is 32KB which is enough to run TPL but not enough to
run VPL. So TPL sets up 'Cache-as-RAM' which provides additional SRAM.
Other architectures may have their own constraints.

But another key difference is that we use OF_PLATDATA in TPL and that
is fine for the basic init needed there. But VPL needs lots of drivers
as well as info about the firmware image layout so it adds to the work
needed to get them running in that environment. So ideally, VPL can be
built without OF_PLATDATA.

Or put it another way, TPL needs to be as small as possible so it can
run on the widest array of devices. VPL is an optional phase (only
used with verified boot) so we should not pollute TPL with that. I
have a lot of other thoughts about all of this, some of which are in
the VBE doc...

Regards,
SImon

Re: [PATCH] lib: rsa: Extract public key from private key if keyfile argument is used

[Tom Rini]

On Sun, Jul 18, 2021 at 09:52:03AM -0700, Chan, Donald wrote:

> If the 'keyfile' (-G) argument is used, there is little value to require
> 'keydir' (-k) argument since the public key can also be extracted from the
> private key itself.
> 
> Signed-off-by: Donald Chan 
> ---
>  lib/rsa/rsa-sign.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index f4ed11e74a..f70f352311 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -49,16 +49,16 @@ static int rsa_err(const char *msg)
>  }
> 
>  /**
> - * rsa_pem_get_pub_key() - read a public key from a .crt file
> + * rsa_pem_get_pub_key() - read a public key from a private key file or
> .crt file
>   *
> - * @keydir:  Directory containins the key
> - * @name Name of key file (will have a .crt extension)
> + * @keydir:  Directory containing the key, can be NULL
> + * @name Name of key file (will apply a .crt extension if keydir is not
> NULL)
>   * @evpp Returns EVP_PKEY object, or NULL on failure
>   * @return 0 if ok, -ve on error (in which case *evpp will be set to NULL)
>   */
>  static int rsa_pem_get_pub_key(const char *keydir, const char *name,
> EVP_PKEY **evpp)
>  {
> - char path[1024];
> + char path[1024] = {0};
>   EVP_PKEY *key = NULL;
>   X509 *cert;
>   FILE *f;
> @@ -68,7 +68,10 @@ static int rsa_pem_get_pub_key(const char *keydir, const
> char *name, EVP_PKEY **
>   return -EINVAL;
> 
>   *evpp = NULL;
> - snprintf(path, sizeof(path), "%s/%s.crt", keydir, name);
> + if (keydir && name)
> + snprintf(path, sizeof(path), "%s/%s.crt", keydir, name);
> + else if (name)
> + snprintf(path, sizeof(path), "%s", name);
>   f = fopen(path, "r");
>   if (!f) {
>   fprintf(stderr, "Couldn't open RSA certificate: '%s': %s\n",
> @@ -76,7 +79,13 @@ static int rsa_pem_get_pub_key(const char *keydir, const
> char *name, EVP_PKEY **
>   return -EACCES;
>   }
> 
> - /* Read the certificate */
> + /* See if it contains a PEM private key? */
> + if (PEM_read_PrivateKey(f, evpp, NULL, path)) {
> + fclose(f);
> + return 0;
> + }
> +
> + /* Not a PEM private key, read the certificate */
>   cert = NULL;
>   if (!PEM_read_X509(f, , NULL, NULL)) {
>   rsa_err("Couldn't read certificate");
> @@ -672,7 +681,12 @@ int rsa_add_verify_data(struct image_sign_info *info,
> void *keydest)
>   if (ret)
>   return ret;
>   }
> - ret = rsa_get_pub_key(info->keydir, info->keyname, e, );
> + if (info->keydir && info->keyname)
> + ret = rsa_get_pub_key(info->keydir, info->keyname, e, );
> + else if (info->keyfile)
> + ret = rsa_get_pub_key(NULL, info->keyfile, e, );
> + else
> + ret = -EINVAL;
>   if (ret)
>   goto err_get_pub_key;
>  #if OPENSSL_VERSION_NUMBER < 0x1010L || \

This seems reasonable, but the formatting of the patch was destroyed
somewhere along the way, can you please resend?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spi: spi-mem-nodm: Fix read data size issue

[Tom Rini]

On Wed, Jul 28, 2021 at 11:19:40PM +0530, Pratyush Yadav wrote:
> +Tom, Simon,
> 
> On 28/07/21 08:50PM, Bin Meng wrote:
> > When slave drivers don't set the max_read_size, the spi-mem should
> > directly use data.nbytes and not limit to any size. But current
> > logic will limit to the max_write_size.
> 
> With the push towards using DM, do we really need to maintain the nodm 
> version anymore? Are there any users left? If there are, I think they 
> should migrate to using DM instead of trying to fix depreciated code.

The users here are likely SPL without DM and SPL_DM is not required.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spi: spi-mem-nodm: Fix read data size issue

[Pratyush Yadav]

+Tom, Simon,

On 28/07/21 08:50PM, Bin Meng wrote:
> When slave drivers don't set the max_read_size, the spi-mem should
> directly use data.nbytes and not limit to any size. But current
> logic will limit to the max_write_size.

With the push towards using DM, do we really need to maintain the nodm 
version anymore? Are there any users left? If there are, I think they 
should migrate to using DM instead of trying to fix depreciated code.

Thoughts?

> 
> This commit mirrors the same changes in the dm version done in
> commit 535b1fdb8e5e ("spi: spi-mem: Fix read data size issue").
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/spi/spi-mem-nodm.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/spi/spi-mem-nodm.c b/drivers/spi/spi-mem-nodm.c
> index a228c808c7..77ddb19a9f 100644
> --- a/drivers/spi/spi-mem-nodm.c
> +++ b/drivers/spi/spi-mem-nodm.c
> @@ -93,12 +93,14 @@ int spi_mem_adjust_op_size(struct spi_slave *slave,
>   if (slave->max_write_size && len > slave->max_write_size)
>   return -EINVAL;
>  
> - if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size)
> - op->data.nbytes = min(op->data.nbytes,
> -   slave->max_read_size);
> - else if (slave->max_write_size)
> + if (op->data.dir == SPI_MEM_DATA_IN) {
> + if (slave->max_read_size)
> + op->data.nbytes = min(op->data.nbytes,
> +   slave->max_read_size);
> + } else if (slave->max_write_size) {
>   op->data.nbytes = min(op->data.nbytes,
> slave->max_write_size - len);
> + }
>  
>   if (!op->data.nbytes)
>   return -EINVAL;
> -- 
> 2.25.1
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: U-Boot boards needing CONFIG_DM migration

[Tom Rini]

On Wed, Jul 28, 2021 at 02:40:41PM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Wed, Jul 28, 2021 at 2:04 PM Tom Rini  wrote:
> >
> > Hey all,
> >
> > I'm sending this email to people that are either listed as maintainers
> > for the following boards, or have shown interest in that general area
> > before.  These boards are the only ones left in tree right now that do
> > not have CONFIG_DM enabled:
> > flea3 aspenite zmx25 mx28evk mx28evk_auart_console mx28evk_nand
> 
> I have sent the mx28evk DM conversion series:
> https://www.mail-archive.com/u-boot@lists.denx.de/msg398398.html
> 
> and
> 
> https://www.mail-archive.com/u-boot@lists.denx.de/msg398399.html
> 
> but it seems it got missed. Could you or Stefano please apply it?
> 
> I plan to support only mx28evk_defconfig and I am fine to remove the
> other mx28evk defconfig variants.

Ah yes, I remember now.  Please send a follow-up to delete those other
configs (and remove them from the MAINTAINERS file).  It's early enough
in the release cycle that I assume Stefano can get them.  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH] mtd: spi-nor-core: Handle SPI_RX_SLOW in spi_nor_adjust_hwcaps()

[Pratyush Yadav]

On 28/07/21 11:56PM, Bin Meng wrote:
> When CONFIG_SPI_FLASH_SMART_HWCAPS is on, SPI_RX_SLOW flag of the
> SPI controller is not honored. This adds the missing logic there.
> 
> With this patch, SPI flash read works again with ICH SPI controller
> on Intel Crown Bay board.
> 
> Signed-off-by: Bin Meng 
> 
> ---
> The quirky stuff of ICH SPI controller is that it only supports normal
> read (opcode 3) but not fast read (opcode 11), so that's why SPI_RX_SLOW
> was introduced before.
> 
> At present the ICH SPI driver does not implement the supports_op() hook.
> I can add a check against opcode 11 there, however I see a comment in
> spi_nor_check_op() saying that SPI controller implementation should not
> check the opcode.
> 
> /*
>  * First test with 4 address bytes. The opcode itself might be a 3B
>  * addressing opcode but we don't care, because SPI controller
>  * implementation should not check the opcode, but just the sequence.
>  */
> 
>  drivers/mtd/spi/spi-nor-core.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 99e2f16349..e9b46c39b5 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -2855,6 +2855,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
> const struct spi_nor_flash_parameter *params,
> u32 *hwcaps)
>  {
> + struct spi_slave *spi = nor->spi;
>   unsigned int cap;
>  
>   /*
> @@ -2879,6 +2880,10 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
>   if (!(*hwcaps & BIT(cap)))
>   continue;
>  
> + if ((spi->mode & SPI_RX_SLOW) &&
> + (BIT(cap) == SNOR_HWCAPS_READ_FAST))
> + *hwcaps &= ~BIT(cap);
> +

NACK.

We already check for SPI_RX_SLOW in spi_nor_scan():

  /* Some devices cannot do fast-read, no matter what DT tells us */
  if ((info->flags & SPI_NOR_NO_FR) || (spi->mode & SPI_RX_SLOW))
params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;

I think the real bug here is that the smart spi_nor_adjust_hwcaps() does 
not respect the flash's hwcaps, and only looks to the controller on what 
can be supported. Doing the below should fix this:

  diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
  index 8dd44c0f1e..4323b49651 100644
  --- a/drivers/mtd/spi/spi-nor-core.c
  +++ b/drivers/mtd/spi/spi-nor-core.c
  @@ -2741,7 +2741,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
 * Enable all caps by default. We will mask them after checking what's
 * really supported using spi_mem_supports_op().
 */
  - *hwcaps = SNOR_HWCAPS_ALL;
  + *hwcaps = SNOR_HWCAPS_ALL & params->hwcaps.mask;
   
/* X-X-X modes are not supported yet, mask them all. */
*hwcaps &= ~SNOR_HWCAPS_X_X_X;

Can you please test and confirm if it does indeed fix the issue for you?

>   rdidx = spi_nor_hwcaps_read2cmd(BIT(cap));
>   if (rdidx >= 0 &&
>   spi_nor_check_readop(nor, >reads[rdidx]))
> -- 
> 2.25.1
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: U-Boot boards needing CONFIG_DM migration

[Fabio Estevam]

Hi Tom,

On Wed, Jul 28, 2021 at 2:04 PM Tom Rini  wrote:
>
> Hey all,
>
> I'm sending this email to people that are either listed as maintainers
> for the following boards, or have shown interest in that general area
> before.  These boards are the only ones left in tree right now that do
> not have CONFIG_DM enabled:
> flea3 aspenite zmx25 mx28evk mx28evk_auart_console mx28evk_nand

I have sent the mx28evk DM conversion series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg398398.html

and

https://www.mail-archive.com/u-boot@lists.denx.de/msg398399.html

but it seems it got missed. Could you or Stefano please apply it?

I plan to support only mx28evk_defconfig and I am fine to remove the
other mx28evk defconfig variants.

Thanks

Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader

[Tom Rini]

On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 28 Jul 2021 at 08:35, Tom Rini  wrote:
> >
> > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 11 Jul 2021 at 20:19, Simon Glass  wrote:
> > > >
> > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > no standard way of implementing it for a board. At present the various
> > > > required pieces must be built up separately, to produce a working
> > > > implementation. In particular, there is no built-in support for 
> > > > selecting
> > > > A/B boot or recovery mode.
> > > >
> > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > run the verified-boot process and decide which SPL binary should be run.
> > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > verified boot. So far, only the phase itself is added along with some
> > > > Kconfig options. The next step is to create a build for sandbox.
> > > >
> > > > Changes in v3:
> > > > - Move VPL Kconfig options to a separate patch
> > > > - Add full build support for VPL
> > > >
> > > > Changes in v2:
> > > > - Add some more VPL Kconfig options
> > > >
> > > > Simon Glass (7):
> > > >   doc: Convert SPL documentation to ReST
> > > >   doc: Expand SPL docs to explain the phase and config
> > > >   test: Tidy up test building with SPL
> > > >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > >   binman: Add VPL support
> > > >   Introduce Verifying Program Loader (VPL)
> > > >   vpl: Add Kconfig options for VPL
> > >
> > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > if that helps.
> >
> > Perhaps some of these general questions would be answered with seeing an
> > implementation for not just sandbox, but real hardware too.  But I'm
> > missing what this provides exactly that we can't do already, or that
> > would justify a whole new stage rather than just some updates within
> > existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
> > Checking in with a TPM to confirm good measurements?  Having written
> > that out, now I really do want to see this implemented on real hardware
> > much more so than sandbox.
> 
> Yes it was actually implemented on coral, an x86 Chromebook which is
> in-tree. I have various patches to come but the docs are at [1]
> 
> The core reason for it is that SPL sets up SDRAM (and perhaps other
> things) so needs to be updateable, so we cannot boot the vboot logic
> in SPL. TPL often has very small size limits so it is difficult to put
> it in there. I am thinking that VPL can be an optional phase used only
> if verified boot is enabled. That makes it easy since it has a defined
> purpose which can be enabled/disabled.
> 
> BTW in doing this I wonder whether we should look again at the
> SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> 
> Regards,
> Simon
> 
> [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst

There's always a "no updates before HERE" line to draw, as you need a
fall-back option.  Since you mention SDRAM, does that mean both TPL and
VPL are running in SRAM/similar space?  If so, why isn't this just part
of TPL, for when you have "a lot" of pre-SDRAM memory to use?

-- 
Tom


signature.asc
Description: PGP signature

U-Boot boards needing CONFIG_DM migration

[Tom Rini]

Hey all,

I'm sending this email to people that are either listed as maintainers
for the following boards, or have shown interest in that general area
before.  These boards are the only ones left in tree right now that do
not have CONFIG_DM enabled:
flea3 aspenite zmx25 mx28evk mx28evk_auart_console mx28evk_nand
mx28evk_spi bg0900 edminiv2 warp UCP1020 MPC8349EMDS MPC8349EMDS_PCI64
MPC8349EMDS_SDRAM MPC8349EMDS_SLAVE

Currently, the migration deadline was v2020.01 and from what I've said
in previous releases, I'm posting removal patches at deadline (which is
visible for a year before) + 2 years.  That said, now that we're down to
this few boards that don't have CONFIG_DM enabled, I want to reach out
now.  Is there interest in updating these boards?  Or should they be
removed now and save some time?

Thanks!

-- 
Tom


signature.asc
Description: PGP signature

eMMC probe issue

[vinoth]

Hi,My SoC configuration is as below:Core: Arm A65 (v8)U-boot version: 
2021-AprExecution and debug environment: Synopsys VDK simulator

My SoC has Synopsys SDHCI. To enable the same in u-boot, I've enabled the 
following options in defconfig:CONFIG_MMC=y
CONFIG_DM_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_CMD_MMC=y
CONFIG_MMC_SDHCI_ABC=y

The last entry above is specific to my SoC. SoC specific sdhci file has been 
added in drivers/mmc folder and to necessary Kconfig / Makefile. Object dump 
has been checked to ensure that the default sdhci.c and soc_specific_sdhci.c is 
part o the binary. Compatible-id has been defined as necessary in the 
device-tree and soc_specific_sdhci.c.
After u-boot board_f / board_r initialisation, dm_dump_all() was executed from 
cli_simple.c to check the probe status. Following was the uart output:
 Class     Index  Probed  Driver                
Name--- root          0 
 [ + ]   root_driver           root_driver rsa_mod_ex    0  [   ]   mod_exp_sw  
          |-- mod_exp_sw simple_bus    0  [   ]   simple_bus            |-- 
dwc_eqos_tlm_bb virtio        0  [   ]   virtio-mmio           |-- 
virtio_block@2180 virtio        1  [   ]   virtio-mmio           |-- 
virtio_block@21c0 serial        0  [ + ]   ns16550_serial        |-- 
uart@0070d000 mmc           0  [ + ]   abc_xyz_sdhci_5.1    `-- mmc@00716000 
blk           0  [   ]   mmc_blk                   `-- m...@00716000.blk

Two questions:1. After this output, the command prompt is also printed in the 
terminal and then a synchronous (data abort) exception is hit. It looks like 
memory has been corrupted sometime back and the problem shows up later. if i 
remove mmc from the device tree, then the exception issue does not happen. Can 
you point me to the areas i need to check / debug for identifying this problem?
2. Another aspect i observed was that after enabling MMC related macros in 
defconfig, the generated binary size reduced by ~200 kiloBytes (even though two 
.c files have been added). I've checked the map file but could not deduce the 
reason for this size reduction. Can you point me to the areas to check?

-RegardsVin

Re: U-Boot Digest, Vol 158, Issue 63

[Tom Rini]

On Wed, Jul 28, 2021 at 12:22:57PM -0400, Oleksandr G Zhadan wrote:
> Hello,
> 
> Please see inline.
> 
> On 7/26/21 9:40 AM, u-boot-requ...@lists.denx.de wrote:
> > Message: 13
> > Date: Mon, 26 Jul 2021 07:34:06 -0600
> > From: Simon Glass
> > To: U-Boot Mailing List
> > Cc: Tom Rini, Simon Glass,
> > Albert Aribaud, Andy Fleming
> > , Joe Hershberger, Marek
> > Vasut, Mario Six, Oleksandr
> > Zhadan and Michael Durrant, Pavel
> > Herrmann, Priyanka Jain
> > , Rob Herring, Stefan
> > Roese, Stefano Babic, Wolfgang Denk
> > 
> > Subject: [PATCH 00/33] pci: Drop all pre-driver model code
> > Message-ID:<20210726133440.634682-1-...@chromium.org>
> > 
> > The hard work to actually enable DM_PCI everywhere was done recently. This
> > series attempts to drop most of the code that it no-longer needed now that
> > PCI has been converted to driver model.
> 
> > It also drops the UCP1020 board since it has various unique build issues.
> 
> What issues are we talking about?Please name it.
> 
> Today's u-boot clone builds and runs fine in our module without any warnings
> except:
> 
> > git clone https://source.denx.de/u-boot/u-boot.git u-boot-20210728
> 
> > cd u-boot-20210728
> 
> > make UCP1020_defconfig
> 
> > CROSS_COMPILE=powerpc-linux- make 2>222
> 
>  > cat 222
> = WARNING ==
> This board does not use CONFIG_DM. CONFIG_DM will be
> compulsory starting with the v2020.01 release.
> Failure to update may result in board removal.
> See doc/driver-model/migration.rst for more info.
> 
> = WARNING ==
> This board does not use CONFIG_DM_ETH (Driver Model
> for Ethernet drivers). Please update the board to use
> CONFIG_DM_ETH before the v2020.07 release. Failure to
> update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> ===
> 
> > It doesn't even support driver model so it seems reasonable to just remove
> > it.
> 1. Sure it's my fault that I didn't notice the warnings that CONFIG_DM is
> the only choice to build and run u-boot.
> 
> 2. Why is CONFIG_DM still present in `make menuconfig` options?
> 
> 3. We only use u-boot as the first stage bootloader to start the kernel. We
> need minimal device controllers support. We don't need anything like PCI,
> USB, etc.
> 
> 4. At least you need to add doc/driver-model/migration.rst to the source
> tree from https://source.denx.de/u-boot/u-boot.git if you point to it in
> your warnings.
> 
> And
> 
> 5. I have seen NO reason to remove ANY support board without REAL reasons to
> do so.

So, unfortunately this was the only board that was not triggering the
PCI migration warning as well because of how it was using the legacy PCI
subsystem.  For today, if you want to continue to be in mainline, just
removing the PCI and other options that you don't use, and submitting
that patch is sufficient.

> SUMMARY:
> 
> 1. UCP1020_defconfig does not have any compiler warnings on build (at least
> 2021.07.28 clone).
> 
> 2. If now the only choice is CONFIG_DM, then it should be removed as an
> option from "make menuconfig", and we will definitely fix the related
> warnings/errors.
> 
> 3. IMPO board support can be removed if it breaks when built and/or breaks
> any other builds.

Note that CONFIG_DM is still an option because it won't be until after
the v2022.01 window (when that migration warning you noted above) will
have been present for about 3 years.  It's still an option as we're down
to 15 boards (UCP included) that need migration still.  Having just
counted that, I'm quite likely to fire off a separate email now and see
if there's interest in these boards being updated or not, now that we're
down to so few boards.

-- 
Tom


signature.asc
Description: PGP signature

Re: U-Boot Digest, Vol 158, Issue 63

[Oleksandr G Zhadan]

Hello,

Please see inline.

On 7/26/21 9:40 AM, u-boot-requ...@lists.denx.de wrote:

Message: 13
Date: Mon, 26 Jul 2021 07:34:06 -0600
From: Simon Glass
To: U-Boot Mailing List
Cc: Tom Rini, Simon Glass,
Albert Aribaud, Andy Fleming
, Joe Hershberger, Marek
Vasut, Mario Six, Oleksandr
Zhadan and Michael Durrant, Pavel
Herrmann, Priyanka Jain
, Rob Herring, Stefan
Roese, Stefano Babic, Wolfgang Denk

Subject: [PATCH 00/33] pci: Drop all pre-driver model code
Message-ID:<20210726133440.634682-1-...@chromium.org>

The hard work to actually enable DM_PCI everywhere was done recently. This
series attempts to drop most of the code that it no-longer needed now that
PCI has been converted to driver model.



It also drops the UCP1020 board since it has various unique build issues.


What issues are we talking about?Please name it.

Today's u-boot clone builds and runs fine in our module without any 
warnings except:


> git clone https://source.denx.de/u-boot/u-boot.git u-boot-20210728

> cd u-boot-20210728

> make UCP1020_defconfig

> CROSS_COMPILE=powerpc-linux- make 2>222

 > cat 222
= WARNING ==
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
See doc/driver-model/migration.rst for more info.

= WARNING ==
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
===


It doesn't even support driver model so it seems reasonable to just remove
it.
1. Sure it's my fault that I didn't notice the warnings that CONFIG_DM 
is the only choice to build and run u-boot.


2. Why is CONFIG_DM still present in `make menuconfig` options?

3. We only use u-boot as the first stage bootloader to start the kernel. 
We need minimal device controllers support. We don't need anything like 
PCI, USB, etc.


4. At least you need to add doc/driver-model/migration.rst to the source 
tree from https://source.denx.de/u-boot/u-boot.git if you point to it in 
your warnings.


And

5. I have seen NO reason to remove ANY support board without REAL 
reasons to do so.



SUMMARY:

1. UCP1020_defconfig does not have any compiler warnings on build (at 
least 2021.07.28 clone).


2. If now the only choice is CONFIG_DM, then it should be removed as an 
option from "make menuconfig", and we will definitely fix the related 
warnings/errors.


3. IMPO board support can be removed if it breaks when built and/or 
breaks any other builds.



Thank you,

Oleks




The DM_PCI option disappears and only PCI is left.


--
Oleksandr Zhadan
ol...@arcturusnetworks.com
416.621.0125 x.235
}|{/\|)/\|-|

Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader

[Simon Glass]

Hi Michael,

On Wed, 28 Jul 2021 at 09:54, Michael Nazzareno Trimarchi
 wrote:
>
> Hi
>
> On Wed, Jul 28, 2021 at 5:34 PM Simon Glass  wrote:
> >
> > Hi Tom,
> >
> > On Wed, 28 Jul 2021 at 08:35, Tom Rini  wrote:
> > >
> > > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 11 Jul 2021 at 20:19, Simon Glass  wrote:
> > > > >
> > > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > > no standard way of implementing it for a board. At present the various
> > > > > required pieces must be built up separately, to produce a working
> > > > > implementation. In particular, there is no built-in support for 
> > > > > selecting
> > > > > A/B boot or recovery mode.
> > > > >
> > > > > This series introduces VPL, a verified program loader. Its purpose is 
> > > > > to
> > > > > run the verified-boot process and decide which SPL binary should be 
> > > > > run.
> > > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > > verified boot. So far, only the phase itself is added along with some
> > > > > Kconfig options. The next step is to create a build for sandbox.
> > > > >
>
> Let's try to understand. So we can have:
>
> TPL (redundant most of cpus support it) -> VPL -\
>
>   -> SPL1 -\ = > UBOOT_B e/o fitImage
>
> | -> ATF1
> | -> TEE1
>
>   -> SPL2  -\ => UBOOT_A e/o fitImage
> | => ATF2
> | => TEE2

I'm not quite sure how to read that diagram. I think we should have
SPLA_ and SPL_B (and perhaps SPL_RECOVERY) so it matches with U-Boot
proper.

>
> If you have this kind of system TPL and VPL can be combined. Is this
> the scenario we will use with this patchset?

Only if there is space to store both the early-init code and the
verified boot. So for coral this is not possible.

But if I understand things correctly, then yes this is the idea.

Regards,
Simon



>
> The funny thing here is that a lot of people ask to update the TPL. After
> adding the VPL the communication will happen using hob memory area?
>
> One of the most interesting parts will be to tag the TPL(x) to know what of 
> them
> the bootrom load.
>
> Michael
>
>
> > > > > Changes in v3:
> > > > > - Move VPL Kconfig options to a separate patch
> > > > > - Add full build support for VPL
> > > > >
> > > > > Changes in v2:
> > > > > - Add some more VPL Kconfig options
> > > > >
> > > > > Simon Glass (7):
> > > > >   doc: Convert SPL documentation to ReST
> > > > >   doc: Expand SPL docs to explain the phase and config
> > > > >   test: Tidy up test building with SPL
> > > > >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > >   binman: Add VPL support
> > > > >   Introduce Verifying Program Loader (VPL)
> > > > >   vpl: Add Kconfig options for VPL
> > > >
> > > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > > if that helps.
> > >
> > > Perhaps some of these general questions would be answered with seeing an
> > > implementation for not just sandbox, but real hardware too.  But I'm
> > > missing what this provides exactly that we can't do already, or that
> > > would justify a whole new stage rather than just some updates within
> > > existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
> > > Checking in with a TPM to confirm good measurements?  Having written
> > > that out, now I really do want to see this implemented on real hardware
> > > much more so than sandbox.
> >
> > Yes it was actually implemented on coral, an x86 Chromebook which is
> > in-tree. I have various patches to come but the docs are at [1]
> >
> > The core reason for it is that SPL sets up SDRAM (and perhaps other
> > things) so needs to be updateable, so we cannot boot the vboot logic
> > in SPL. TPL often has very small size limits so it is difficult to put
> > it in there. I am thinking that VPL can be an optional phase used only
> > if verified boot is enabled. That makes it easy since it has a defined
> > purpose which can be enabled/disabled.
> >
> > BTW in doing this I wonder whether we should look again at the
> > SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> >
> > Regards,
> > Simon
> >
> > [1] 
> > https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
>
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com

Re: [PATCH v10 12/27] mtd: spi-nor-core: Rework hwcaps selection

[Bin Meng]

Hi Pratyush,

On Wed, Jul 28, 2021 at 6:44 PM Pratyush Yadav  wrote:
>
> On 28/07/21 06:13PM, Bin Meng wrote:
> > Hi Pratyush,
> >
> > On Sat, Jun 26, 2021 at 3:20 AM Pratyush Yadav  wrote:
> > >
> > > The spi-mem layer provides a spi_mem_supports_op() function to check
> > > whether a specific operation is supported by the controller or not.
> > > This is much more accurate than the hwcaps selection logic based on
> > > SPI_{RX,TX}_ flags.
> > >
> > > Rework the hwcaps selection logic to use spi_mem_supports_op().
> > >
> > > To make sure the build doesn't break for boards not using CONFIG_DM_SPI,
> > > add a simple SPI_{RX,TX}_ based hwcaps selection logic in spi-mem-nodm
> > > similar to spi_mem_default_supports_op(). This change is only
> > > compile-tested.
> > >
> > > To avoid SPL size problems on the x530 board, the old hwcaps selection
> > > is still kept around. Leaving the code in-place was getting difficult to
> > > read and understand, so the code is restructured to have it all in one
> > > isolated function. As a result of this, the parameter hwcaps to
> > > spi_nor_setup() is no longer needed. Remove it.
> > >
> > > Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
> > > selection for the spi-mem case, 2019-08-06)
> > >
> > > Signed-off-by: Pratyush Yadav 
> > > ---
> > >  drivers/mtd/spi/Kconfig|   9 ++
> > >  drivers/mtd/spi/spi-nor-core.c | 244 ++---
> > >  drivers/spi/spi-mem-nodm.c |  62 +
> > >  include/linux/mtd/spi-nor.h|  17 ++-
> > >  4 files changed, 280 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > > index f8db8e5213..a701167dcc 100644
> > > --- a/drivers/mtd/spi/Kconfig
> > > +++ b/drivers/mtd/spi/Kconfig
> > > @@ -88,6 +88,15 @@ config SPI_FLASH_SFDP_SUPPORT
> > >  SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
> > >  tables as per JESD216 standard.
> > >
> > > +config SPI_FLASH_SMART_HWCAPS
> > > +   bool "Smart hardware capability detection based on SPI MEM 
> > > supports_op() hook"
> > > +   default y
> >
> > This commit unfortunately breaks ICH SPI driver working with SPI
> > flashes on Intel boards.
> >
> > Switching off this option makes it work again.
> >
> > I think this is due to that ICH SPI driver has set the flags
> > SPI_RX_SLOW | SPI_TX_BYTE but these 2 flags are not handled in the new
> > codes.
> > Any quick ideas on how to fix this?
>
> So can the controller can only support 1S-1S-1S mode? Or can the
> controller support more modes but the board does not have the other
> lines connected?
>
> For the former case, you should populate the supports_op() hook and
> reject ops that are not 1S-1S-1S. For the latter case, you should set
> spi-{rx,tx}-bus-width = <1> in device tree.

Thank you. I just sent a RFC patch that fixed this issue.

>
> Make sure you call spi_mem_default_supports_op() from your supports_op()
> hook otherwise the slave->mode bits are not taken into account.
>
> >
> > > +   help
> > > +Enable support for smart hardware capability detection based on 
> > > SPI
> > > +MEM supports_op() hook that lets controllers express whether they
> > > +can support a type of operation in a much more refined way 
> > > compared
> > > +to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> > > +
> >
> > [snip]
> >

Regards,
Bin

[RFC PATCH] mtd: spi-nor-core: Handle SPI_RX_SLOW in spi_nor_adjust_hwcaps()

[Bin Meng]

When CONFIG_SPI_FLASH_SMART_HWCAPS is on, SPI_RX_SLOW flag of the
SPI controller is not honored. This adds the missing logic there.

With this patch, SPI flash read works again with ICH SPI controller
on Intel Crown Bay board.

Signed-off-by: Bin Meng 

---
The quirky stuff of ICH SPI controller is that it only supports normal
read (opcode 3) but not fast read (opcode 11), so that's why SPI_RX_SLOW
was introduced before.

At present the ICH SPI driver does not implement the supports_op() hook.
I can add a check against opcode 11 there, however I see a comment in
spi_nor_check_op() saying that SPI controller implementation should not
check the opcode.

/*
 * First test with 4 address bytes. The opcode itself might be a 3B
 * addressing opcode but we don't care, because SPI controller
 * implementation should not check the opcode, but just the sequence.
 */

 drivers/mtd/spi/spi-nor-core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 99e2f16349..e9b46c39b5 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2855,6 +2855,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
  const struct spi_nor_flash_parameter *params,
  u32 *hwcaps)
 {
+   struct spi_slave *spi = nor->spi;
unsigned int cap;
 
/*
@@ -2879,6 +2880,10 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
if (!(*hwcaps & BIT(cap)))
continue;
 
+   if ((spi->mode & SPI_RX_SLOW) &&
+   (BIT(cap) == SNOR_HWCAPS_READ_FAST))
+   *hwcaps &= ~BIT(cap);
+
rdidx = spi_nor_hwcaps_read2cmd(BIT(cap));
if (rdidx >= 0 &&
spi_nor_check_readop(nor, >reads[rdidx]))
-- 
2.25.1

Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader

[Michael Nazzareno Trimarchi]

Hi

On Wed, Jul 28, 2021 at 5:34 PM Simon Glass  wrote:
>
> Hi Tom,
>
> On Wed, 28 Jul 2021 at 08:35, Tom Rini  wrote:
> >
> > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 11 Jul 2021 at 20:19, Simon Glass  wrote:
> > > >
> > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > no standard way of implementing it for a board. At present the various
> > > > required pieces must be built up separately, to produce a working
> > > > implementation. In particular, there is no built-in support for 
> > > > selecting
> > > > A/B boot or recovery mode.
> > > >
> > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > run the verified-boot process and decide which SPL binary should be run.
> > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > verified boot. So far, only the phase itself is added along with some
> > > > Kconfig options. The next step is to create a build for sandbox.
> > > >

Let's try to understand. So we can have:

TPL (redundant most of cpus support it) -> VPL -\

  -> SPL1 -\ = > UBOOT_B e/o fitImage

| -> ATF1
| -> TEE1

  -> SPL2  -\ => UBOOT_A e/o fitImage
| => ATF2
| => TEE2

If you have this kind of system TPL and VPL can be combined. Is this
the scenario we will use with this patchset?

The funny thing here is that a lot of people ask to update the TPL. After
adding the VPL the communication will happen using hob memory area?

One of the most interesting parts will be to tag the TPL(x) to know what of them
the bootrom load.

Michael


> > > > Changes in v3:
> > > > - Move VPL Kconfig options to a separate patch
> > > > - Add full build support for VPL
> > > >
> > > > Changes in v2:
> > > > - Add some more VPL Kconfig options
> > > >
> > > > Simon Glass (7):
> > > >   doc: Convert SPL documentation to ReST
> > > >   doc: Expand SPL docs to explain the phase and config
> > > >   test: Tidy up test building with SPL
> > > >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > >   binman: Add VPL support
> > > >   Introduce Verifying Program Loader (VPL)
> > > >   vpl: Add Kconfig options for VPL
> > >
> > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > if that helps.
> >
> > Perhaps some of these general questions would be answered with seeing an
> > implementation for not just sandbox, but real hardware too.  But I'm
> > missing what this provides exactly that we can't do already, or that
> > would justify a whole new stage rather than just some updates within
> > existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
> > Checking in with a TPM to confirm good measurements?  Having written
> > that out, now I really do want to see this implemented on real hardware
> > much more so than sandbox.
>
> Yes it was actually implemented on coral, an x86 Chromebook which is
> in-tree. I have various patches to come but the docs are at [1]
>
> The core reason for it is that SPL sets up SDRAM (and perhaps other
> things) so needs to be updateable, so we cannot boot the vboot logic
> in SPL. TPL often has very small size limits so it is difficult to put
> it in there. I am thinking that VPL can be an optional phase used only
> if verified boot is enabled. That makes it easy since it has a defined
> purpose which can be enabled/disabled.
>
> BTW in doing this I wonder whether we should look again at the
> SPL_TPL_ Makefile variables. Do you think PHASE might be better?
>
> Regards,
> Simon
>
> [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst



--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com

Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader

[Simon Glass]

Hi Tom,

On Wed, 28 Jul 2021 at 08:35, Tom Rini  wrote:
>
> On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 11 Jul 2021 at 20:19, Simon Glass  wrote:
> > >
> > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > no standard way of implementing it for a board. At present the various
> > > required pieces must be built up separately, to produce a working
> > > implementation. In particular, there is no built-in support for selecting
> > > A/B boot or recovery mode.
> > >
> > > This series introduces VPL, a verified program loader. Its purpose is to
> > > run the verified-boot process and decide which SPL binary should be run.
> > > Adding VPL into the boot flow provides a standard way of implementing
> > > verified boot. So far, only the phase itself is added along with some
> > > Kconfig options. The next step is to create a build for sandbox.
> > >
> > > Changes in v3:
> > > - Move VPL Kconfig options to a separate patch
> > > - Add full build support for VPL
> > >
> > > Changes in v2:
> > > - Add some more VPL Kconfig options
> > >
> > > Simon Glass (7):
> > >   doc: Convert SPL documentation to ReST
> > >   doc: Expand SPL docs to explain the phase and config
> > >   test: Tidy up test building with SPL
> > >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > >   binman: Add VPL support
> > >   Introduce Verifying Program Loader (VPL)
> > >   vpl: Add Kconfig options for VPL
> >
> > Any thoughts on this one? I have a few updates so can send a rebase v4
> > if that helps.
>
> Perhaps some of these general questions would be answered with seeing an
> implementation for not just sandbox, but real hardware too.  But I'm
> missing what this provides exactly that we can't do already, or that
> would justify a whole new stage rather than just some updates within
> existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
> Checking in with a TPM to confirm good measurements?  Having written
> that out, now I really do want to see this implemented on real hardware
> much more so than sandbox.

Yes it was actually implemented on coral, an x86 Chromebook which is
in-tree. I have various patches to come but the docs are at [1]

The core reason for it is that SPL sets up SDRAM (and perhaps other
things) so needs to be updateable, so we cannot boot the vboot logic
in SPL. TPL often has very small size limits so it is difficult to put
it in there. I am thinking that VPL can be an optional phase used only
if verified boot is enabled. That makes it easy since it has a defined
purpose which can be enabled/disabled.

BTW in doing this I wonder whether we should look again at the
SPL_TPL_ Makefile variables. Do you think PHASE might be better?

Regards,
Simon

[1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst

Re: u-boot saveenv to redundant fat does not persist env

[Tom Rini]

On Wed, Jul 28, 2021 at 05:25:48PM +0200, Pierre-Alexis Ciavaldini wrote:

> Hi,
> 
> When I did, mender complained about it :
> include/config_mender.h:41:3: error: #error CONFIG_SYS_REDUNDAND_ENVIRONMENT 
> is required for Mender to work. Make sure that: 1) All the instructions at 
> https:
> 41 | # error CONFIG_SYS_REDUNDAND_ENVIRONMENT is required for Mender to work. 
> Make sure that: 1) All the instructions at 
> https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot
>  have been followed. 2) All required layers are included in bblayers.conf, 
> including any board specific layers such as meta-mender-. Check also 
> https://docs.mender.io/troubleshoot/yocto-project-build for Known Issues when 
> upgrading.
> 
> I guess I could disable the check, but even so I'm not sure it would work as 
> uboot.env does not get written ?

Yes, you should disable that check.  Then you can debug the fw_printenv
issue by itself.

> Thank you,
> PA
> 
> On Jul 28 2021, at 5:23 pm, Tom Rini  wrote:
> > On Wed, Jul 28, 2021 at 04:41:56PM +0200, Pierre-Alexis Ciavaldini wrote:
> >
> > > Hi Tom,
> > >
> > > /etc/fw_env.config has this contents:
> > > /boot/u-boot/uboot.env 0x 0x4000
> > > /boot/u-boot/uboot-redund.env 0x 0x4000
> >
> > And what if you turn off redundant environment support? Mender does
> > strongly recommend that, but you can just turn it off. Does that get
> > you working environment from file and fw_setenv/fw_printenv working?
> >
> > >
> > > Thank you,
> > > PA
> > >
> > > On Jul 28 2021, at 4:39 pm, Tom Rini  wrote:
> > > > On Tue, Jul 27, 2021 at 04:44:20PM +0200, Pierre-Alexis Ciavaldini 
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I'm trying to integrate u-boot in our project that is a custom 
> > > > > scripted build without yocto, for use with mender.
> > > > > The complete discussion can be found here : 
> > > > > https://hub.mender.io/t/pi3-usb-boot-support/595/54?u=peac
> > > > > The problem is that when issuing saveenv in u-boot, it responds with 
> > > > > "Saving Environment to FAT... OK" but then using fw_printenv in the 
> > > > > booted linux, does not show saved variables.
> > > > >
> > > > > The system currently boots because i've tricked it by getting the 
> > > > > compiled-in env over uart (env print -a) and made a uboot.env using 
> > > > > mkenvimage manually to enable fw_printenv to work.
> > > > > I've noticed that when deleting "/boot/u-boot/uboot.env", u-boot's 
> > > > > saveenv does not re-create it, so it seems to me that saveenv does 
> > > > > not write uboot.env.
> > > > > Here's the complete project files : 
> > > > > https://git.iostud.io/cosmos/u-boot/-/tree/cosmos
> > > > > relevant modified files are:
> > > > > - configs/rpi_4_32b_defconfig
> > > > > - include/config_mender_defines.h
> > > > > - include/env_mender.h
> > > > > - include/configs/rpi.h
> > > > > - include/env_default.h
> > > > > - include/config_mender.h
> > > > >
> > > > > Any help or investigating direction would be greatly appreciated.
> > > >
> > > > What does your /etc/fw_env.config file look like?
> > > > --
> > > > Tom
> > > >
> > >
> >
> > --
> > Tom
> >
> 

-- 
Tom


signature.asc
Description: PGP signature

Re: u-boot saveenv to redundant fat does not persist env

[Tom Rini]

On Wed, Jul 28, 2021 at 04:41:56PM +0200, Pierre-Alexis Ciavaldini wrote:

> Hi Tom,
> 
> /etc/fw_env.config has this contents:
> /boot/u-boot/uboot.env 0x 0x4000
> /boot/u-boot/uboot-redund.env 0x 0x4000

And what if you turn off redundant environment support?  Mender does
strongly recommend that, but you can just turn it off.  Does that get
you working environment from file and fw_setenv/fw_printenv working?

> 
> Thank you,
> PA
> 
> On Jul 28 2021, at 4:39 pm, Tom Rini  wrote:
> > On Tue, Jul 27, 2021 at 04:44:20PM +0200, Pierre-Alexis Ciavaldini wrote:
> > > Hi,
> > >
> > > I'm trying to integrate u-boot in our project that is a custom scripted 
> > > build without yocto, for use with mender.
> > > The complete discussion can be found here : 
> > > https://hub.mender.io/t/pi3-usb-boot-support/595/54?u=peac
> > > The problem is that when issuing saveenv in u-boot, it responds with 
> > > "Saving Environment to FAT... OK" but then using fw_printenv in the 
> > > booted linux, does not show saved variables.
> > >
> > > The system currently boots because i've tricked it by getting the 
> > > compiled-in env over uart (env print -a) and made a uboot.env using 
> > > mkenvimage manually to enable fw_printenv to work.
> > > I've noticed that when deleting "/boot/u-boot/uboot.env", u-boot's 
> > > saveenv does not re-create it, so it seems to me that saveenv does not 
> > > write uboot.env.
> > > Here's the complete project files : 
> > > https://git.iostud.io/cosmos/u-boot/-/tree/cosmos
> > > relevant modified files are:
> > > - configs/rpi_4_32b_defconfig
> > > - include/config_mender_defines.h
> > > - include/env_mender.h
> > > - include/configs/rpi.h
> > > - include/env_default.h
> > > - include/config_mender.h
> > >
> > > Any help or investigating direction would be greatly appreciated.
> >
> > What does your /etc/fw_env.config file look like?
> > --
> > Tom
> >
> 

-- 
Tom


signature.asc
Description: PGP signature

qemu-kvm doesn't work with qemu-x86_64_defconfig

[Matwey V. Kornilov]

Hello,

I am trying to build master for qemu-x86_64_defconfig. When I try to
boot u-boot.rom as the following everything works fine:

> qemu-system-x86_64 -nographic -bios u-boot.rom

U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300)
Trying to boot from SPI
Jumping to 64-bit U-Boot: Note many features are missing


U-Boot 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300)

CPU:   QEMU Virtual CPU version 2.5+
DRAM:  128 MiB
Loading Environment from nowhere... OK
Incorrect expansion ROM header signature 4daa
Model: QEMU x86 (I440FX)
Net:   e1000: 52:54:00:12:34:56
   eth0: e1000#0
Hit any key to stop autoboot:  0


When I try to enable KVM as the following, the boot process hangs:

> qemu-system-x86_64 -enable-kvm -cpu host -nographic -bios u-boot.rom

U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300)
Trying to boot from SPI
Jumping to 64-bit U-Boot: Note many features are missing


What have I missed? Maybe KVM is just not supported?

Re: [PATCH 2/2] board: sifive: use ccache driver instead of helper function

[Sean Anderson]

On 7/28/21 3:25 AM, Zong Li wrote:

On Wed, Jul 28, 2021 at 12:29 PM Sean Anderson  wrote:


On 7/27/21 4:54 AM, Zong Li wrote:

Invokes the generic cache_enable interface to execute the relative
implementation in SiFive ccache driver.

Signed-off-by: Zong Li 
---
   arch/riscv/cpu/fu540/Kconfig  |  1 +
   arch/riscv/cpu/fu540/cache.c  | 62 ---
   arch/riscv/cpu/fu740/Kconfig  |  1 +
   arch/riscv/cpu/fu740/cache.c  | 60 +++---
   arch/riscv/include/asm/arch-fu540/cache.h |  2 +-
   arch/riscv/include/asm/arch-fu740/cache.h |  2 +-
   board/sifive/unleashed/unleashed.c| 10 +---
   board/sifive/unmatched/unmatched.c|  9 +---
   8 files changed, 45 insertions(+), 102 deletions(-)

diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
index 05463b2625..1f50b823ed 100644
--- a/arch/riscv/cpu/fu540/Kconfig
+++ b/arch/riscv/cpu/fu540/Kconfig
@@ -19,6 +19,7 @@ config SIFIVE_FU540
   imply SMP
   imply CLK_SIFIVE
   imply CLK_SIFIVE_PRCI
+ imply SIFIVE_CACHE_CCACHE
   imply SIFIVE_SERIAL
   imply MACB
   imply MII
diff --git a/arch/riscv/cpu/fu540/cache.c b/arch/riscv/cpu/fu540/cache.c
index 0fc4ef6c00..3c754c4614 100644
--- a/arch/riscv/cpu/fu540/cache.c
+++ b/arch/riscv/cpu/fu540/cache.c
@@ -1,55 +1,33 @@
   // SPDX-License-Identifier: GPL-2.0+
   /*
- * Copyright (C) 2020 SiFive, Inc
+ * Copyright (C) 2020 - 2021 SiFive, Inc
*
* Authors:
*   Pragnesh Patel 
*/

   #include 
-#include 
-#include 
-#include 
+#include 
+#include 

-/* Register offsets */
-#define L2_CACHE_CONFIG  0x000
-#define L2_CACHE_ENABLE  0x008
-
-#define MASK_NUM_WAYSGENMASK(15, 8)
-#define NUM_WAYS_SHIFT   8
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int cache_enable_ways(void)
+int sifive_ccache_enable_ways(void)
   {


Is there any reason this function is duplicated? See below for further comments.


Sorry, I don't completely understand about duplication here. Do you
mean why we need this function? or why is it present in both unleashed
and unmatched?


Why it is present in both. Shouldn't it be present in some shared file?






- const void *blob = gd->fdt_blob;
- int node;
- fdt_addr_t base;
- u32 config;
- u32 ways;
-
- volatile u32 *enable;
-
- node = fdt_node_offset_by_compatible(blob, -1,
-  "sifive,fu540-c000-ccache");
-
- if (node < 0)
- return node;
-
- base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
- NULL, false);
- if (base == FDT_ADDR_T_NONE)
- return FDT_ADDR_T_NONE;
-
- config = readl((volatile u32 *)base + L2_CACHE_CONFIG);
- ways = (config & MASK_NUM_WAYS) >> NUM_WAYS_SHIFT;
-
- enable = (volatile u32 *)(base + L2_CACHE_ENABLE);
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_CACHE,
+   DM_DRIVER_GET(sifive_ccache),
+   );
+ if (ret) {
+ pr_debug("%s: could not enable cache ways\n", __func__);
+ return ret;
+ }
+
+ ret = cache_enable(dev);
+ if (ret) {
+ pr_debug("%s: ccache enable filed\n", __func__);
+ return ret;
+ }

- /* memory barrier */
- mb();
- (*enable) = ways - 1;
- /* memory barrier */
- mb();
   return 0;
   }
diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
index 8e54310b9c..87d8016c88 100644
--- a/arch/riscv/cpu/fu740/Kconfig
+++ b/arch/riscv/cpu/fu740/Kconfig
@@ -19,6 +19,7 @@ config SIFIVE_FU740
   imply SMP
   imply CLK_SIFIVE
   imply CLK_SIFIVE_PRCI
+ imply SIFIVE_CACHE_CCACHE
   imply SIFIVE_SERIAL
   imply MACB
   imply MII
diff --git a/arch/riscv/cpu/fu740/cache.c b/arch/riscv/cpu/fu740/cache.c
index 680955c9e3..1d6c295d98 100644
--- a/arch/riscv/cpu/fu740/cache.c
+++ b/arch/riscv/cpu/fu740/cache.c
@@ -7,49 +7,27 @@
*/

   #include 
-#include 
-#include 
-#include 
+#include 
+#include 

-/* Register offsets */
-#define L2_CACHE_CONFIG  0x000
-#define L2_CACHE_ENABLE  0x008
-
-#define MASK_NUM_WAYSGENMASK(15, 8)
-#define NUM_WAYS_SHIFT   8
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int cache_enable_ways(void)
+int sifive_ccache_enable_ways(void)
   {
- const void *blob = gd->fdt_blob;
- int node;
- fdt_addr_t base;
- u32 config;
- u32 ways;
-
- volatile u32 *enable;
-
- node = fdt_node_offset_by_compatible(blob, -1,
-  "sifive,fu740-c000-ccache");
-
- if (node < 0)
- return node;
-
- base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
- NULL, false);
- if (base == FDT_ADDR_T_NONE)
- return FDT_ADDR_T_NONE;
-
- config = 

Re: u-boot saveenv to redundant fat does not persist env

[Tom Rini]

On Tue, Jul 27, 2021 at 04:44:20PM +0200, Pierre-Alexis Ciavaldini wrote:
> Hi,
> 
> I'm trying to integrate u-boot in our project that is a custom scripted build 
> without yocto, for use with mender.
> The complete discussion can be found here : 
> https://hub.mender.io/t/pi3-usb-boot-support/595/54?u=peac
> The problem is that when issuing saveenv in u-boot, it responds with "Saving 
> Environment to FAT... OK" but then using fw_printenv in the booted linux, 
> does not show saved variables.
> 
> The system currently boots because i've tricked it by getting the compiled-in 
> env over uart (env print -a) and made a uboot.env using mkenvimage manually 
> to enable fw_printenv to work.
> I've noticed that when deleting "/boot/u-boot/uboot.env", u-boot's saveenv 
> does not re-create it, so it seems to me that saveenv does not write 
> uboot.env.
> Here's the complete project files : 
> https://git.iostud.io/cosmos/u-boot/-/tree/cosmos
> relevant modified files are:
> - configs/rpi_4_32b_defconfig
> - include/config_mender_defines.h
> - include/env_mender.h
> - include/configs/rpi.h
> - include/env_default.h
> - include/config_mender.h
> 
> Any help or investigating direction would be greatly appreciated.

What does your /etc/fw_env.config file look like?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader

[Tom Rini]

On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 11 Jul 2021 at 20:19, Simon Glass  wrote:
> >
> > U-Boot provides a verified-boot feature based around FIT, but there is
> > no standard way of implementing it for a board. At present the various
> > required pieces must be built up separately, to produce a working
> > implementation. In particular, there is no built-in support for selecting
> > A/B boot or recovery mode.
> >
> > This series introduces VPL, a verified program loader. Its purpose is to
> > run the verified-boot process and decide which SPL binary should be run.
> > Adding VPL into the boot flow provides a standard way of implementing
> > verified boot. So far, only the phase itself is added along with some
> > Kconfig options. The next step is to create a build for sandbox.
> >
> > Changes in v3:
> > - Move VPL Kconfig options to a separate patch
> > - Add full build support for VPL
> >
> > Changes in v2:
> > - Add some more VPL Kconfig options
> >
> > Simon Glass (7):
> >   doc: Convert SPL documentation to ReST
> >   doc: Expand SPL docs to explain the phase and config
> >   test: Tidy up test building with SPL
> >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> >   binman: Add VPL support
> >   Introduce Verifying Program Loader (VPL)
> >   vpl: Add Kconfig options for VPL
> 
> Any thoughts on this one? I have a few updates so can send a rebase v4
> if that helps.

Perhaps some of these general questions would be answered with seeing an
implementation for not just sandbox, but real hardware too.  But I'm
missing what this provides exactly that we can't do already, or that
would justify a whole new stage rather than just some updates within
existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
Checking in with a TPM to confirm good measurements?  Having written
that out, now I really do want to see this implemented on real hardware
much more so than sandbox.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 1/6] lib: strto: add simple_strtoll function

[Tom Rini]

On Fri, Jul 23, 2021 at 12:29:18PM +, Roland Gaudig wrote:

> From: Roland Gaudig 
> 
> Add simple_strtoll function for converting a string containing digits
> into a long long int value.
> 
> Signed-off-by: Roland Gaudig 
> Reviewed-by: Simon Glass 

For the series, applied to u-boot/master (and enabled on sandbox so the
tests run), thanks!

-- 
Tom


signature.asc
Description: PGP signature

u-boot saveenv to redundant fat does not persist env

[Pierre-Alexis Ciavaldini]

Hi,

I'm trying to integrate u-boot in our project that is a custom scripted build 
without yocto, for use with mender.
The complete discussion can be found here : 
https://hub.mender.io/t/pi3-usb-boot-support/595/54?u=peac
The problem is that when issuing saveenv in u-boot, it responds with "Saving 
Environment to FAT... OK" but then using fw_printenv in the booted linux, does 
not show saved variables.

The system currently boots because i've tricked it by getting the compiled-in 
env over uart (env print -a) and made a uboot.env using mkenvimage manually to 
enable fw_printenv to work.
I've noticed that when deleting "/boot/u-boot/uboot.env", u-boot's saveenv does 
not re-create it, so it seems to me that saveenv does not write uboot.env.
Here's the complete project files : 
https://git.iostud.io/cosmos/u-boot/-/tree/cosmos
relevant modified files are:
- configs/rpi_4_32b_defconfig
- include/config_mender_defines.h
- include/env_mender.h
- include/configs/rpi.h
- include/env_default.h
- include/config_mender.h

Any help or investigating direction would be greatly appreciated.
Thank you,
Pierre-Alexis Ciavaldini

[PATCH] spi: fix xilinx-spi lockup when fifo-size undefined in dtree

[Pauli Oikkonen]

If fifo_depth is 0, the driver will lock up.

If fifo-size is not defined in device tree, the driver would use 0 as
a default value. This however will cause an infinite loop and a lockup
in any read or write. Use 1 as a default FIFO size instead, no FIFO
should be zero-length anyway.

Signed-off-by: Pauli Oikkonen 
CC: Jagan Teki 
---
 drivers/spi/xilinx_spi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index b892cdae9b..da0f8b3bb4 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -110,12 +110,17 @@ struct xilinx_spi_priv {
 
 static int xilinx_spi_probe(struct udevice *bus)
 {
+   int success;
struct xilinx_spi_priv *priv = dev_get_priv(bus);
struct xilinx_spi_regs *regs = priv->regs;
 
priv->regs = (struct xilinx_spi_regs *)dev_read_addr(bus);
 
-   priv->fifo_depth = dev_read_u32_default(bus, "fifo-size", 0);
+   success = dev_read_u32(bus, "fifo-size", >fifo_depth);
+   if (success != 0) {
+   debug("%s: no fifo-size defined in dtree, using 1\n", __func__);
+   priv->fifo_depth = 1;
+   }
 
writel(SPISSR_RESET_VALUE, >srr);
 
-- 
2.25.1

[PATCH] spi: spi-mem-nodm: Fix read data size issue

[Bin Meng]

When slave drivers don't set the max_read_size, the spi-mem should
directly use data.nbytes and not limit to any size. But current
logic will limit to the max_write_size.

This commit mirrors the same changes in the dm version done in
commit 535b1fdb8e5e ("spi: spi-mem: Fix read data size issue").

Signed-off-by: Bin Meng 
---

 drivers/spi/spi-mem-nodm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-mem-nodm.c b/drivers/spi/spi-mem-nodm.c
index a228c808c7..77ddb19a9f 100644
--- a/drivers/spi/spi-mem-nodm.c
+++ b/drivers/spi/spi-mem-nodm.c
@@ -93,12 +93,14 @@ int spi_mem_adjust_op_size(struct spi_slave *slave,
if (slave->max_write_size && len > slave->max_write_size)
return -EINVAL;
 
-   if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size)
-   op->data.nbytes = min(op->data.nbytes,
- slave->max_read_size);
-   else if (slave->max_write_size)
+   if (op->data.dir == SPI_MEM_DATA_IN) {
+   if (slave->max_read_size)
+   op->data.nbytes = min(op->data.nbytes,
+ slave->max_read_size);
+   } else if (slave->max_write_size) {
op->data.nbytes = min(op->data.nbytes,
  slave->max_write_size - len);
+   }
 
if (!op->data.nbytes)
return -EINVAL;
-- 
2.25.1

[PATCH 4/4] xilinx: zynqmp: Add support for runtime dfu_alt_info setup

[Michal Simek]

The main reason for this to be implemented is capsule update.
Two memories are supported and tested which is MMC FAT based and QSPI
based.

For creating capsule these commands are used:
./tools/mkeficapsule --raw spl/boot.bin --index 1 capsule1.bin
./tools/mkeficapsule --raw u-boot.itb --index 2 capsule2.bin

Then transfer to SD card where these commands run:
load mmc 0 1000 capsule1.bin
efidebug capsule update -v 1000
load mmc 0 1000 capsule2.bin
efidebug capsule update -v 1000

Depends on the boot device used are binaries loaded to qspi or mmc fat
partition.
Also multiboot register is handled to make sure that the same location(id)
is used as image which is upgraded.

Two locations are used by purpose for SPL flow. If only boot.bin is used
create only one capsule.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 56 
 configs/xilinx_zynqmp_virt_defconfig |  1 +
 2 files changed, 57 insertions(+)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 1b0356c84c5c..f9390fbb3957 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -818,3 +820,57 @@ enum env_location env_get_location(enum env_operation op, 
int prio)
return ENVL_NOWHERE;
}
 }
+
+#if defined(CONFIG_SET_DFU_ALT_INFO)
+
+#define DFU_ALT_BUF_LENSZ_1K
+
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+   u8 multiboot;
+   int bootseq = 0;
+
+   ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
+
+   if (env_get("dfu_alt_info"))
+   return;
+
+   memset(buf, 0, sizeof(buf));
+
+   multiboot = multi_boot();
+   debug("Multiboot: %d\n", multiboot);
+
+   switch (zynqmp_get_bootmode()) {
+   case EMMC_MODE:
+   case SD_MODE:
+   case SD1_LSHFT_MODE:
+   case SD_MODE1:
+   bootseq = mmc_get_env_dev();
+   if (!multiboot)
+   snprintf(buf, DFU_ALT_BUF_LEN,
+"mmc %d:1=boot.bin fat %d 1;"
+"u-boot.itb fat %d 1",
+bootseq, bootseq, bootseq);
+   else
+   snprintf(buf, DFU_ALT_BUF_LEN,
+"mmc %d:1=boot%04d.bin fat %d 1;"
+"u-boot.itb fat %d 1",
+bootseq, multiboot, bootseq, bootseq);
+   break;
+   case QSPI_MODE_24BIT:
+   case QSPI_MODE_32BIT:
+   snprintf(buf, DFU_ALT_BUF_LEN,
+"sf 0:0=boot.bin raw %x 0x150;"
+"u-boot.itb raw 0x%x 0x50",
+multiboot * SZ_32K, CONFIG_SYS_SPI_U_BOOT_OFFS);
+   break;
+   default:
+   goto end;
+   }
+
+   env_set("dfu_alt_info", buf);
+   puts("DFU alt info setting: done\n");
+end:
+   free(buf);
+}
+#endif
diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index 6f72a9f50ed3..02e165f3b2bc 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -96,6 +96,7 @@ CONFIG_DFU_NAND=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
 CONFIG_DFU_MTD=y
+CONFIG_SET_DFU_ALT_INFO=y
 CONFIG_SYS_DFU_DATA_BUF_SIZE=0x180
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_FLASH=y
-- 
2.32.0

[PATCH 3/4] xilinx: zynqmp: Config non zero SYS_SPI_U_BOOT_OFFS

[Michal Simek]

This variable is pointing to offset is qspi where u-boot image is placed.
In our case it is location of u-boot.itb file. Offset is the same as is
used by Xilinx Zynq SoC.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index fa6a7f1de6ee..6f72a9f50ed3 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -5,6 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 CONFIG_SYS_MEMTEST_START=0x
 CONFIG_SYS_MEMTEST_END=0x1000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x10
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu100-revC"
 CONFIG_SPL=y
-- 
2.32.0

[PATCH 2/4] xilinx: zynqmp: use zynqmp_mmio_read() in multi_boot()

[Michal Simek]

When U-Boot runs in EL2 there is no access to csu_base registers that's why
this has to be done via firmware interface to find out multi boot register
value. Till now this function is called only from SPL in EL3.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index eb67116d5b44..1b0356c84c5c 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -346,9 +346,12 @@ int board_early_init_f(void)
 
 static int multi_boot(void)
 {
-   u32 multiboot;
+   u32 multiboot = 0;
+   int ret;
 
-   multiboot = readl(_base->multi_boot);
+   ret = zynqmp_mmio_read((ulong)_base->multi_boot, );
+   if (ret)
+   return -EINVAL;
 
return multiboot;
 }
-- 
2.32.0

[PATCH 1/4] xilinx: zynqmp: Change multi_boot() to return value

[Michal Simek]

Change multi_boot() to return multiboot value and move print out of this
function and let this function to be used by other functions without
duplicating message.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 2cb97f42bec3..eb67116d5b44 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -350,9 +350,7 @@ static int multi_boot(void)
 
multiboot = readl(_base->multi_boot);
 
-   printf("Multiboot:\t%d\n", multiboot);
-
-   return 0;
+   return multiboot;
 }
 
 #define PS_SYSMON_ANALOG_BUS_VAL   0x3210
@@ -392,7 +390,7 @@ int board_init(void)
 #endif
 
if (current_el() == 3)
-   multi_boot();
+   printf("Multiboot:\t%d\n", multi_boot());
 
return 0;
 }
-- 
2.32.0

[PATCH 0/4] xilinx: zynqmp: Add support for dfu_alt_info setup at runtime

[Michal Simek]

Hi,

this series is just for composing dfu_alt_info string for capsule update to
work automatically based on current setup.
QSPI/MMC FAT bootmodes are handled and supported. Other bootmodes are
ignored for now.

Thanks,
Michal


Michal Simek (4):
  xilinx: zynqmp: Change multi_boot() to return value
  xilinx: zynqmp: use zynqmp_mmio_read() in multi_boot()
  xilinx: zynqmp: Config non zero SYS_SPI_U_BOOT_OFFS
  xilinx: zynqmp: Add support for runtime dfu_alt_info setup

 board/xilinx/zynqmp/zynqmp.c | 69 +---
 configs/xilinx_zynqmp_virt_defconfig |  2 +
 2 files changed, 65 insertions(+), 6 deletions(-)

-- 
2.32.0

[PATCH] xilinx: zynqmp: Free allocated field for target variable

[Michal Simek]

When env_set() is called there is no need to allocate memory for variable
which is already saved that's why free it.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 38c910fa5bab..2cb97f42bec3 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -735,6 +735,7 @@ int board_late_init(void)
env_targets ? env_targets : "");
 
env_set("boot_targets", new_targets);
+   free(new_targets);
 
reset_reason();
 
-- 
2.32.0

Re: [PATCH v10 12/27] mtd: spi-nor-core: Rework hwcaps selection

[Pratyush Yadav]

On 28/07/21 06:13PM, Bin Meng wrote:
> Hi Pratyush,
> 
> On Sat, Jun 26, 2021 at 3:20 AM Pratyush Yadav  wrote:
> >
> > The spi-mem layer provides a spi_mem_supports_op() function to check
> > whether a specific operation is supported by the controller or not.
> > This is much more accurate than the hwcaps selection logic based on
> > SPI_{RX,TX}_ flags.
> >
> > Rework the hwcaps selection logic to use spi_mem_supports_op().
> >
> > To make sure the build doesn't break for boards not using CONFIG_DM_SPI,
> > add a simple SPI_{RX,TX}_ based hwcaps selection logic in spi-mem-nodm
> > similar to spi_mem_default_supports_op(). This change is only
> > compile-tested.
> >
> > To avoid SPL size problems on the x530 board, the old hwcaps selection
> > is still kept around. Leaving the code in-place was getting difficult to
> > read and understand, so the code is restructured to have it all in one
> > isolated function. As a result of this, the parameter hwcaps to
> > spi_nor_setup() is no longer needed. Remove it.
> >
> > Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
> > selection for the spi-mem case, 2019-08-06)
> >
> > Signed-off-by: Pratyush Yadav 
> > ---
> >  drivers/mtd/spi/Kconfig|   9 ++
> >  drivers/mtd/spi/spi-nor-core.c | 244 ++---
> >  drivers/spi/spi-mem-nodm.c |  62 +
> >  include/linux/mtd/spi-nor.h|  17 ++-
> >  4 files changed, 280 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > index f8db8e5213..a701167dcc 100644
> > --- a/drivers/mtd/spi/Kconfig
> > +++ b/drivers/mtd/spi/Kconfig
> > @@ -88,6 +88,15 @@ config SPI_FLASH_SFDP_SUPPORT
> >  SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
> >  tables as per JESD216 standard.
> >
> > +config SPI_FLASH_SMART_HWCAPS
> > +   bool "Smart hardware capability detection based on SPI MEM 
> > supports_op() hook"
> > +   default y
> 
> This commit unfortunately breaks ICH SPI driver working with SPI
> flashes on Intel boards.
> 
> Switching off this option makes it work again.
> 
> I think this is due to that ICH SPI driver has set the flags
> SPI_RX_SLOW | SPI_TX_BYTE but these 2 flags are not handled in the new
> codes.
> Any quick ideas on how to fix this?

So can the controller can only support 1S-1S-1S mode? Or can the 
controller support more modes but the board does not have the other 
lines connected?

For the former case, you should populate the supports_op() hook and 
reject ops that are not 1S-1S-1S. For the latter case, you should set 
spi-{rx,tx}-bus-width = <1> in device tree.

Make sure you call spi_mem_default_supports_op() from your supports_op() 
hook otherwise the slave->mode bits are not taken into account.

> 
> > +   help
> > +Enable support for smart hardware capability detection based on SPI
> > +MEM supports_op() hook that lets controllers express whether they
> > +can support a type of operation in a much more refined way compared
> > +to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> > +
> 
> [snip]
> 
> Regards,
> Bin

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH 1/2] cache: add sifive composable cache driver

[Zong Li]

On Wed, Jul 28, 2021 at 12:23 PM Sean Anderson  wrote:
>
> On 7/27/21 4:54 AM, Zong Li wrote:
> > This driver is currently responsible for enabling all ccache ways.
>
> Can you expand on this a little? Perhaps describe the hardware a little. For 
> example,
> you could describe what a way/bank is, and that they can't be disabled by the 
> hardware.

Certainly, let me give more details there.

>
> >
> > Signed-off-by: Zong Li 
> > ---
> >   drivers/cache/Kconfig   |  7 +++
> >   drivers/cache/Makefile  |  1 +
> >   drivers/cache/cache-sifive-ccache.c | 69 +
> >   3 files changed, 77 insertions(+)
> >   create mode 100644 drivers/cache/cache-sifive-ccache.c
> >
> > diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> > index 1e452ad6d9..b903e3e935 100644
> > --- a/drivers/cache/Kconfig
> > +++ b/drivers/cache/Kconfig
> > @@ -39,4 +39,11 @@ config NCORE_CACHE
> > controller. The driver initializes cache directories and coherent
> > agent interfaces.
> >
> > +config SIFIVE_CACHE_CCACHE
>
> Just SIFIVE_CCACHE (or SIFIVE_CACHE) please.

The idea is that the configuration name needs to be able to
distinguish multiple cache devices. For example, if there are other
two devices related to cache, we could give the following three
configurations:
 - SIFIVE_CACHE_CCACHE
 - SIFIVE_CACHE_XXX
 - SIFIVE_CACHE_YYY

SIFIVE_CCACHE is also ok to me, then we would get the following
configuration names in the future.
 - SIFIVE_CCACHE
 - SIFIVE_XXX
 - SIFIVE_YYY

>
> > + bool "SiFive composable cache"
> > + select CACHE
> > + help
> > +   This driver is for SiFive Composable L2/L3 cache. It enables cache
> > +   ways of composable cache.
> > +
> >   endmenu
> > diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile
> > index fed50be3f9..92c6c5a83f 100644
> > --- a/drivers/cache/Makefile
> > +++ b/drivers/cache/Makefile
> > @@ -4,3 +4,4 @@ obj-$(CONFIG_SANDBOX) += sandbox_cache.o
> >   obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
> >   obj-$(CONFIG_NCORE_CACHE) += cache-ncore.o
> >   obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o
> > +obj-$(CONFIG_SIFIVE_CACHE_CCACHE) += cache-sifive-ccache.o
> > diff --git a/drivers/cache/cache-sifive-ccache.c 
> > b/drivers/cache/cache-sifive-ccache.c
> > new file mode 100644
> > index 00..9ea064912f
> > --- /dev/null
> > +++ b/drivers/cache/cache-sifive-ccache.c
> > @@ -0,0 +1,69 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2021 SiFive
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SIFIVE_CCACHE_CONFIG 0x000
> > +#define SIFIVE_CCACHE_ENABLE 0x008
>
> WAY_ENABLE?

Changes in the next version.

>
> > +
> > +#define SIFIVE_CCACHE_NUM_WAY_MASK   GENMASK(15, 8)
> > +#define SIFIVE_CCACHE_NUM_WAY_SHIFT  8
> > +
> > +struct sifive_ccache {
> > + void __iomem *base;
> > +};
> > +
> > +static int sifive_ccache_enable_all_ways(struct udevice *dev)
> > +{
> > + struct sifive_ccache *priv = dev_get_priv(dev);
> > + u32 config;
> > + u32 ways;
> > +
> > + config = readl(priv->base + SIFIVE_CCACHE_CONFIG);
> > + ways = (config & SIFIVE_CCACHE_NUM_WAY_MASK) >> 
> > SIFIVE_CCACHE_NUM_WAY_SHIFT;
>
> ways = FIELD_GET(SIFIVE_CCACHE_NUM_WAY_MASK, config);
>
> and perhaps this should be named SIFIVE_CCACHE_CONFIG_WAYS to better match 
> the datasheet?
>

Yes, change it in the next version.

> > +
> > + writel(ways - 1, priv->base + SIFIVE_CCACHE_ENABLE);
> > +
> > + return 0;
> > +}
> > +
> > +static int sifive_ccache_enable(struct udevice *dev)
> > +{
> > + return sifive_ccache_enable_all_ways(dev);
>
> Any reason to have this in a separate function?
>

sifive_ccache_enable isn't clear enough to me, we couldn't be
straightforward to know what to enable.

> > +}
> > +
> > +static const struct cache_ops sifive_ccache_ops = {
> > + .enable = sifive_ccache_enable,
>
> Please implement get_info as well. It should effectively just be
>

Add get_info in the next version. Thanks.

> get_info()
> {
> struct sifive_ccache *priv = dev_get_priv(dev);
>
> info->base = priv->base;
> return 0;
> }
>
> > +};
> > +
> > +static int sifive_ccache_probe(struct udevice *dev)
> > +{
> > + struct sifive_ccache *priv = dev_get_priv(dev);
> > +
> > + priv->base = dev_read_addr_ptr(dev);
> > + if (!priv->base)
> > + return -ENODEV;
>
> Please return -EINVAL instead [1].
>

Thanks. Modify it in the next version.

> --Sean
>
> [1] 
> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#error-codes
>
> > +
> > + return 0;
> > +}
> > +
> > +static const struct udevice_id sifive_ccache_ids[] = {
> > + { .compatible = "sifive,fu540-c000-ccache" },
> > + { .compatible = "sifive,fu740-c000-ccache" },
> > + {}
> > +};
> > +
> > +U_BOOT_DRIVER(sifive_ccache) = {
> > + .name = "sifive_ccache",
> > + .id = UCLASS_CACHE,
> > + 

[PATCH 2/2] x86: crownbay: Disable CONFIG_SPI_FLASH_SMART_HWCAPS

[Bin Meng]

Since commit 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
SPI flash on Intel Crown Bay board does not work anymore.

Disable CONFIG_SPI_FLASH_SMART_HWCAPS until a proper fix is made to
the spi-nor core.

Signed-off-by: Bin Meng 
---

 configs/crownbay_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index af8fb0d805..1208aad42f 100644
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -47,6 +47,7 @@ CONFIG_TFTP_TSIZE=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CPU=y
+# CONFIG_SPI_FLASH_SMART_HWCAPS is not set
 CONFIG_E1000=y
 CONFIG_SOUND=y
 CONFIG_SOUND_I8254=y
-- 
2.25.1

[PATCH 1/2] spi: ich: Limit slave->max_read_size

[Bin Meng]

Since commit 43c145b8b3ee ("spi: ich: Correct max-size bug in 
ich_spi_adjust_size()")
(in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
in software sequencer mode.

ICH controller can only transfer a small number of bytes at once.
Before commit 43c145b8b3ee, the logic happens to make sure data.nbytes
is limited to slave->max_write_size but after commit 43c145b8b3ee
data.nbytes is no longer limited because slave->max_read_size is not
initialized with a valid number.

Fixes: 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
Signed-off-by: Bin Meng 
---

 drivers/spi/ich.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index 3d49c22a9d..08d54e86f4 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -918,12 +918,14 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
struct spi_slave *slave = dev_get_parent_priv(dev);
 
/*
-* Yes this controller can only write a small number of bytes at
+* Yes this controller can only transfer a small number of bytes at
 * once! The limit is typically 64 bytes. For hardware sequencing a
 * a loop is used to get around this.
 */
-   if (!plat->hwseq)
+   if (!plat->hwseq) {
+   slave->max_read_size = priv->databytes;
slave->max_write_size = priv->databytes;
+   }
/*
 * ICH 7 SPI controller only supports array read command
 * and byte program command for SST flash
-- 
2.25.1

Re: [PATCH v10 12/27] mtd: spi-nor-core: Rework hwcaps selection

[Bin Meng]

Hi Pratyush,

On Sat, Jun 26, 2021 at 3:20 AM Pratyush Yadav  wrote:
>
> The spi-mem layer provides a spi_mem_supports_op() function to check
> whether a specific operation is supported by the controller or not.
> This is much more accurate than the hwcaps selection logic based on
> SPI_{RX,TX}_ flags.
>
> Rework the hwcaps selection logic to use spi_mem_supports_op().
>
> To make sure the build doesn't break for boards not using CONFIG_DM_SPI,
> add a simple SPI_{RX,TX}_ based hwcaps selection logic in spi-mem-nodm
> similar to spi_mem_default_supports_op(). This change is only
> compile-tested.
>
> To avoid SPL size problems on the x530 board, the old hwcaps selection
> is still kept around. Leaving the code in-place was getting difficult to
> read and understand, so the code is restructured to have it all in one
> isolated function. As a result of this, the parameter hwcaps to
> spi_nor_setup() is no longer needed. Remove it.
>
> Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
> selection for the spi-mem case, 2019-08-06)
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/mtd/spi/Kconfig|   9 ++
>  drivers/mtd/spi/spi-nor-core.c | 244 ++---
>  drivers/spi/spi-mem-nodm.c |  62 +
>  include/linux/mtd/spi-nor.h|  17 ++-
>  4 files changed, 280 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index f8db8e5213..a701167dcc 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -88,6 +88,15 @@ config SPI_FLASH_SFDP_SUPPORT
>  SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
>  tables as per JESD216 standard.
>
> +config SPI_FLASH_SMART_HWCAPS
> +   bool "Smart hardware capability detection based on SPI MEM 
> supports_op() hook"
> +   default y

This commit unfortunately breaks ICH SPI driver working with SPI
flashes on Intel boards.

Switching off this option makes it work again.

I think this is due to that ICH SPI driver has set the flags
SPI_RX_SLOW | SPI_TX_BYTE but these 2 flags are not handled in the new
codes.
Any quick ideas on how to fix this?

> +   help
> +Enable support for smart hardware capability detection based on SPI
> +MEM supports_op() hook that lets controllers express whether they
> +can support a type of operation in a much more refined way compared
> +to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> +

[snip]

Regards,
Bin

Re: [PATCH 1/1] doc: riscv: flashing SiFive boards

[Bin Meng]

On Wed, Jul 28, 2021 at 5:03 PM Heinrich Schuchardt  wrote:
>

nits: missing

From: Heinrich Schuchardt 

> We should not use /dev/sda and /dev/sdb in our examples. Users might
> inadvertently mess up their workstation. Use /dev/sdX instead.
>
> Remove console output like '# ' and '> ' which makes copying hard.
>
> Set example language to bash for correct syntax-highlighting.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  doc/board/sifive/unleashed.rst | 20 ++--
>  doc/board/sifive/unmatched.rst | 30 +++---
>  2 files changed, 25 insertions(+), 25 deletions(-)
>

Otherwise
Reviewed-by: Bin Meng 

Re: [u-boot PATCH] arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge

[Jan Kiszka]

On 30.01.20 09:05, Roger Quadros wrote:
> NB0 is bridge to SRAM and NB1 is bridge to DDR.
> 
> To ensure that SRAM transfers are not stalled due to
> delays during DDR refreshes, SRAM traffic should be higher
> priority (threadmap=2) than DDR traffic (threadmap=0).
> 
> This patch does just that.
> 
> This is required to fix ICSSG TX lock-ups due to delays in
> MSMC transfers due to incorrect Northbridge configuration.
> 
> Signed-off-by: Roger Quadros 
> Acked-by: Andrew F. Davis 
> Acked-by: Tomi Valkeinen 
> Acked-by: Benoit Parrot 
> ---
>  arch/arm/mach-k3/am6_init.c  | 14 ++
>  arch/arm/mach-k3/include/mach/am6_hardware.h |  7 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
> index 8d107b870b..9379b95bdb 100644
> --- a/arch/arm/mach-k3/am6_init.c
> +++ b/arch/arm/mach-k3/am6_init.c
> @@ -86,6 +86,18 @@ static void store_boot_index_from_rom(void)
>   bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
>  }
>  
> +static void setup_am654_navss_northbridge(void)
> +{
> + /*
> +  * NB0 is bridge to SRAM and NB1 is bridge to DDR.
> +  * To ensure that SRAM transfers are not stalled due to
> +  * delays during DDR refreshes, SRAM traffic should be higher
> +  * priority (threadmap=2) than DDR traffic (threadmap=0).
> +  */
> + writel(0x2, NAVSS0_NBSS_NB0_CFG_BASE + NAVSS_NBSS_THREADMAP);
> + writel(0x0, NAVSS0_NBSS_NB1_CFG_BASE + NAVSS_NBSS_THREADMAP);
> +}
> +
>  void board_init_f(ulong dummy)
>  {
>  #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS)
> @@ -101,6 +113,8 @@ void board_init_f(ulong dummy)
>   /* Make all control module registers accessible */
>   ctrl_mmr_unlock();
>  
> + setup_am654_navss_northbridge();
> +
>  #ifdef CONFIG_CPU_V7R
>   disable_linefill_optimization();
>   setup_k3_mpu_regions();
> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h 
> b/arch/arm/mach-k3/include/mach/am6_hardware.h
> index 6df7631545..45a5b31c52 100644
> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h
> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
> @@ -47,4 +47,11 @@
>  /* MCU SCRATCHPAD usage */
>  #define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
>  
> +/* NAVSS Northbridge config */
> +#define  NAVSS0_NBSS_NB0_CFG_BASE0x03802000
> +#define  NAVSS0_NBSS_NB1_CFG_BASE0x03803000
> +
> +#define  NAVSS_NBSS_PID  0x0
> +#define  NAVSS_NBSS_THREADMAP0x10
> +
>  #endif /* __ASM_ARCH_AM6_HARDWARE_H */
> 

This was never merged, not even commented on (only apparently rejected
in patchwork) - but it is crucial as we now found out:

prueth will quickly stall when these priorities are not applied, at
least with SR1.0-based AM65x designs. And you probably know what else
could go wrong. Please clarify and merge, possibly reducing the scope to
SR1.0 if you can confirm that SR2.0 cannot be affected by design (I can
only say this based on few practical experiments here).

If it was good for several TI SDK releases by now, at least something
similar should be good for upstream as well, I believe.

Thanks,
Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH 1/1] doc: riscv: flashing SiFive boards

[Heinrich Schuchardt]

We should not use /dev/sda and /dev/sdb in our examples. Users might
inadvertently mess up their workstation. Use /dev/sdX instead.

Remove console output like '# ' and '> ' which makes copying hard.

Set example language to bash for correct syntax-highlighting.

Signed-off-by: Heinrich Schuchardt 
---
 doc/board/sifive/unleashed.rst | 20 ++--
 doc/board/sifive/unmatched.rst | 30 +++---
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/doc/board/sifive/unleashed.rst b/doc/board/sifive/unleashed.rst
index 4e4c852ff3..c8a62068a7 100644
--- a/doc/board/sifive/unleashed.rst
+++ b/doc/board/sifive/unleashed.rst
@@ -456,21 +456,21 @@ device tree blob (hifive-unleashed-a00.dtb)

 Format the SD card (make sure the disk has GPT, otherwise use gdisk to switch)

-.. code-block:: none
+.. code-block:: bash

-   # sudo sgdisk --clear \
-   > --set-alignment=2 \
-   > --new=1:34:2081 --change-name=1:loader1 
--typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
-   > --new=2:2082:10273 --change-name=2:loader2 
--typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
-   > --new=3:10274: --change-name=3:rootfs 
--typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
-   > /dev/sda
+   sudo sgdisk --clear \
+ --set-alignment=2 \
+ --new=1:34:2081 --change-name=1:loader1 
--typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+ --new=2:2082:10273 --change-name=2:loader2 
--typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+ --new=3:10274: --change-name=3:rootfs 
--typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
+ /dev/sdX

 Program the SD card

-.. code-block:: none
+.. code-block:: bash

-   sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
-   sudo dd if=u-boot.itb of=/dev/sda seek=2082
+   sudo dd if=spl/u-boot-spl.bin of=/dev/sdX seek=34
+   sudo dd if=u-boot.itb of=/dev/sdX seek=2082

 Booting
 ~~~
diff --git a/doc/board/sifive/unmatched.rst b/doc/board/sifive/unmatched.rst
index e65b0d3206..4b4a1ff8f0 100644
--- a/doc/board/sifive/unmatched.rst
+++ b/doc/board/sifive/unmatched.rst
@@ -61,31 +61,31 @@ device tree blob (hifive-unmatched-a00.dtb)

 Format the SD card (make sure the disk has GPT, otherwise use gdisk to switch)

-.. code-block:: none
+.. code-block:: bash

-   # sudo sgdisk -g --clear -a 1 \
-   > --new=1:34:2081 --change-name=1:spl 
--typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
-   > --new=2:2082:10273  --change-name=2:uboot  
--typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
-   > --new=3:16384:282623--change-name=3:boot --typecode=3:0x0700 \
-   > --new=4:286720:13918207 --change-name=4:root --typecode=4:0x8300 \
-   > /dev/sdb
+   sudo sgdisk -g --clear -a 1 \
+ --new=1:34:2081 --change-name=1:spl 
--typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+ --new=2:2082:10273  --change-name=2:uboot  
--typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+ --new=3:16384:282623--change-name=3:boot --typecode=3:0x0700 \
+ --new=4:286720:13918207 --change-name=4:root --typecode=4:0x8300 \
+ /dev/sdX

 Copy linux Image.gz and hifive-unmatched-a00.dtb to boot partition

-.. code-block:: none
+.. code-block:: bash

-   sudo mkfs.vfat /dev/sdb3
-   sudo mkfs.ext4 /dev/sdb4
+   sudo mkfs.vfat /dev/sdX3
+   sudo mkfs.ext4 /dev/sdX4

-   sudo mount /dev/sdb3 /media/sdb3
-   sudo cp Image.gz hifive-unmatched-a00.dtb /media/sdb3/
+   sudo mount /dev/sdX3 /media/sdX3
+   sudo cp Image.gz hifive-unmatched-a00.dtb /media/sdX3/

 Program the SD card

-.. code-block:: none
+.. code-block:: bash

-   sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
-   sudo dd if=u-boot.itb of=/dev/sda seek=2082
+   sudo dd if=spl/u-boot-spl.bin of=/dev/sdX seek=34
+   sudo dd if=u-boot.itb of=/dev/sdX seek=2082

 Booting
 ---
--
2.30.2

[PATCH] lx2160a: Enable CONFIG_SPI_FLASH_MT35XU for lx2160a-rdb/qds

[Kuldeep Singh]

LX2160A-RDB/QDS has micron mt35xu512aba flash which requires flag
CONFIG_SPI_FLASH_MT35XU on to probe flash successfully.

Signed-off-by: Kuldeep Singh 
---
 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 +
 configs/lx2160aqds_tfa_defconfig | 1 +
 configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 +
 configs/lx2160ardb_tfa_defconfig | 1 +
 configs/lx2160ardb_tfa_stmm_defconfig| 1 +
 5 files changed, 5 insertions(+)

diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
index ed4304c704..91fba19618 100644
--- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
@@ -51,6 +51,7 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_SST=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig
index faa8da770b..d52063c7a8 100644
--- a/configs/lx2160aqds_tfa_defconfig
+++ b/configs/lx2160aqds_tfa_defconfig
@@ -58,6 +58,7 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_SST=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
index f8511cb193..94e103c5d1 100644
--- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
@@ -47,6 +47,7 @@ CONFIG_FSL_ESDHC=y
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
 CONFIG_PHY_AQUANTIA=y
diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig
index 004eb7de74..d09bcde92e 100644
--- a/configs/lx2160ardb_tfa_defconfig
+++ b/configs/lx2160ardb_tfa_defconfig
@@ -56,6 +56,7 @@ CONFIG_FSL_ESDHC=y
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
 CONFIG_PHY_AQUANTIA=y
diff --git a/configs/lx2160ardb_tfa_stmm_defconfig 
b/configs/lx2160ardb_tfa_stmm_defconfig
index 140f851ba2..93b1e49cf2 100644
--- a/configs/lx2160ardb_tfa_stmm_defconfig
+++ b/configs/lx2160ardb_tfa_stmm_defconfig
@@ -56,6 +56,7 @@ CONFIG_FSL_ESDHC=y
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
 CONFIG_PHY_AQUANTIA=y
-- 
2.25.1

RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature

[Z.Q. Hou]

> -Original Message-
> From: Tom Rini 
> Sent: 2021年7月27日 21:08
> To: Z.Q. Hou 
> Cc: Michael Walle ; Heinrich Schuchardt
> ; u-boot@lists.denx.de; Priyanka Jain
> 
> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
> 
> On Tue, Jul 27, 2021 at 05:42:51AM +, Z.Q. Hou wrote:
> > Hi Tom,
> >
> > > -Original Message-
> > > From: Tom Rini 
> > > Sent: 2021年7月26日 20:29
> > > To: Z.Q. Hou 
> > > Cc: Michael Walle ; Heinrich Schuchardt
> > > ; u-boot@lists.denx.de; Priyanka Jain
> > > 
> > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> > > feature
> > >
> > > On Mon, Jul 26, 2021 at 07:37:53AM +, Z.Q. Hou wrote:
> > > > Hi Micheal,
> > > >
> > > > > -Original Message-
> > > > > From: Michael Walle 
> > > > > Sent: 2021年7月26日 15:13
> > > > > To: Z.Q. Hou 
> > > > > Cc: Tom Rini ; Heinrich Schuchardt
> > > > > ; u-boot@lists.denx.de; Priyanka Jain
> > > > > 
> > > > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> > > > > feature
> > > > >
> > > > > Am 2021-07-26 09:01, schrieb Z.Q. Hou:
> > > > > > Hi Michael,
> > > > > >
> > > > > >> -Original Message-
> > > > > >> From: Michael Walle 
> > > > > >> Sent: 2021年7月23日 1:01
> > > > > >> To: Tom Rini 
> > > > > >> Cc: Z.Q. Hou ; Heinrich Schuchardt
> > > > > >> ; u-boot@lists.denx.de; Priyanka Jain
> > > > > >> 
> > > > > >> Subject: Re: [PATCH] configs: layerscape: Disable the
> > > > > >> EFI_LOADER feature
> > > > > >>
> > > > > >> Am 2021-07-22 17:26, schrieb Tom Rini:
> > > > > >> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> > > > > >> >
> > > > > >> >> From: Hou Zhiqiang 
> > > > > >> >>
> > > > > >> >> The feature BOOTENV_SHARED_EFI is not supported on
> > > > > >> >> layerscape
> > > > > >> boards,
> > > > > >> >> it didn't result kernel boot crash previously since there
> > > > > >> >> isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
> > > 'boot_efi_binary'.
> > > > > >> >>
> > > > > >> >> But since the commit f3866909e350 ("distro_bootcmd: call
> > > > > >> >> EFI bootmgr even without having /EFI/boot"), it will cause
> > > > > >> >> kernel boot crash as there isn't a valid fdt_addr and it
> > > > > >> >> finially uses the device tree blob of U-Boot and further cause
> errors.
> > > > > >> >>
> > > > > >> >> As this feature is enabled by default for armv7 and armv8,
> > > > > >> >> so disable it explicitly to avoid calling the 
> > > > > >> >> 'scan_dev_for_efi'.
> > > > > >> >
> > > > > >> > I'm not thrilled with this.  Why isn't the solution to get
> > > > > >> > and keep in sync the device trees, so that the tree U-Boot
> > > > > >> > has is valid for the kernel?  I'm also open to discussing
> > > > > >> > f3866909e350 more.  But I'm really opposed to disabling
> > > > > >> > EFI_LOADER on modern platforms as that will make adoption
> > > > > >> > of U-Boot in device harder I
> > > feel.
> > > > > >>
> > > > > >> I don't know whats going on with the NXP boards, but the sl28
> > > > > >> is a layerscape board it is working pretty well with EFI boot.
> > > > > >
> > > > > > Do you mean the EFI boot work well on sl28?
> > > > > This, for example, I can boot the debian installer
> > > > > out-of-the-box, given that the fdtfile variable is set correctly.
> > > >
> > > > Oh, we are talking on different case.
> > > >
> > > > >
> > > > > > Or the EFI boot doesn't break other boot ways?
> > > > > >
> > > > > > In my case, there are 4 MMC partitions and a boot script with
> > > > > > boot images in the 2nd partition, while nothing in the 1st 
> > > > > > partition.
> > > > > > So the expected boot flow is the 'bootcmd_mmc0' scan the 1st
> > > > > > partition and find it's not bootable and then the 2nd
> > > > > > partition and boot with the script. But actually the
> > > > > > 'scan_dev_for_efi' got problem when scan the 1st partition, as
> > > > > > the u-boot DTB is used in 'bootefi bootmgr' and result in some error
> related to the DTB.
> > > > >
> > > > > As mentioned in the other mail, I'm not sure why "bootefi bootmgr"
> > > > > does something at all, because AFAIK it needs the
> > > > > BootOrder/BootNext variables. Heinrich, please correct me if I'm
> wrong.
> > > >
> > > > I'm not familiar with EFI boot, In this case, the
> > > > 'scan_dev_for_efi' calls 'run
> > > boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if
> > > the needed components exist.
> > > > Is the cmd 'scan_dev_for_efi' wrong?
> > >
> > > I'll let Heinrich comment on this part.
> > >
> > > > > > Actually, if give a readable but invalid 'fdt_addr' in env,
> > > > > > the EFI boot can also be skipped during the scan of the 1st 
> > > > > > partition.
> > > > > > Actually on some Layerscape boards the provided env 'fdt_addr'
> > > > > > with a non-readable address, and on other boards a readable
> > > > > > 'fdt_addr'. Seems the patch author copy them from somewhere
> > > > > > but didn't cause issue that time. But this is just a
> > > > > 

Re: [PATCH v2 1/9] tools: mkeficapsule: add firmwware image signing

[Masami Hiramatsu]

Hi,

I've tested this update on the DeveloperBox platform.

Tested-by: Masami Hiramatsu 

Thank you,

2021年7月27日(火) 18:12 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 | 332 +++
>  3 files changed, 316 insertions(+), 31 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 bae3f95c4995..af8536489652 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -245,8 +245,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..798706c7b5f7 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,195 @@ 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);
>  }
>
> +struct auth_context {
> +   char *key_file;
> +   char *cert_file;
> +   u8 *image_data;
> +   size_t image_size;
> +   struct efi_firmware_image_authentication auth;
> +   u8 *sig_data;
> +   size_t sig_size;
> +};
> +
> +static int dump_sig;
> +
> +#ifdef CONFIG_TOOLS_LIBCRYPTO
> +static EVP_PKEY *fileio_read_pkey(const char *filename)
> +{
> +   EVP_PKEY *key 

Re: [PATCH v2 4/8] mmc: zynq_sdhci: Use xilinx pm request instead of mmio_write

[Michal Simek]

Hi Ashok

On 7/27/21 2:36 PM, Ashok Reddy Soma wrote:
> Currently xilinx sdhci driver is using zynqmp_mmio_write() to set
> tapdelay values. Use xilinx_pm_request() using appropriate arguments
> to set input/output tapdelays for zynqmp. Where tapdelay setting is
> done by firmware. Host driver should explicitly request DLL reset
> before ITAP (assert DLL) and after OTAP (release DLL) to avoid issues
> in some cases. Also handle error return where possible.
> 
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Ashok Reddy Soma 
> ---
> 
> Changes in v2:
>  - Added comment for why 1ms delay is needed between DLL assert and
>  release
>  - Remove mmc->dev->seq_ and use priv->deviceid instead
> 
>  board/xilinx/zynqmp/tap_delays.c | 89 +++-
>  drivers/mmc/zynq_sdhci.c | 75 ++-
>  include/zynqmp_tap_delay.h   | 25 ++---
>  3 files changed, 87 insertions(+), 102 deletions(-)
> 
> diff --git a/board/xilinx/zynqmp/tap_delays.c 
> b/board/xilinx/zynqmp/tap_delays.c
> index d16bbb8eff..4ce2244060 100644
> --- a/board/xilinx/zynqmp/tap_delays.c
> +++ b/board/xilinx/zynqmp/tap_delays.c
> @@ -10,92 +10,17 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#define SD_DLL_CTRL  0xFF180358
> -#define SD_ITAP_DLY  0xFF180314
> -#define SD_OTAP_DLY  0xFF180318
> -#define SD0_DLL_RST_MASK 0x0004
> -#define SD0_DLL_RST  0x0004
> -#define SD1_DLL_RST_MASK 0x0004
> -#define SD1_DLL_RST  0x0004
> -#define SD0_ITAPCHGWIN_MASK  0x0200
> -#define SD0_ITAPCHGWIN   0x0200
> -#define SD1_ITAPCHGWIN_MASK  0x0200
> -#define SD1_ITAPCHGWIN   0x0200
> -#define SD0_ITAPDLYENA_MASK  0x0100
> -#define SD0_ITAPDLYENA   0x0100
> -#define SD1_ITAPDLYENA_MASK  0x0100
> -#define SD1_ITAPDLYENA   0x0100
> -#define SD0_ITAPDLYSEL_MASK  0x00FF
> -#define SD1_ITAPDLYSEL_MASK  0x00FF
> -#define SD0_OTAPDLYSEL_MASK  0x003F
> -#define SD1_OTAPDLYSEL_MASK  0x003F
> -
> -void zynqmp_dll_reset(u8 deviceid)
> +int arasan_zynqmp_set_in_tapdelay(u8 deviceid, u32 type, u32 itap_delay)
>  {
> - /* Issue DLL Reset */
> - if (deviceid == 0)
> - zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK,
> -   SD0_DLL_RST);
> - else
> - zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST_MASK,
> -   SD1_DLL_RST);
> -
> - mdelay(1);
>  
> - /* Release DLL Reset */
> - if (deviceid == 0)
> - zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK, 0x0);
> - else
> - zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST_MASK, 0x0);
> + return xilinx_pm_request(PM_IOCTL, (u32)deviceid, IOCTL_SET_SD_TAPDELAY,
> +   type, itap_delay, NULL);

I have tried to apply these patches to latest tree and this breaks SPL
flow because IOCTL_SET_SD_TAPDELAY in TF-A is doing much more steps then
just single write. It means for SPL case we have to implement that steps
in xilinx_pm_request() as it is done for PM_FPGA_LOAD case.

Thanks,
Michal

Re: [PATCH 2/2] board: sifive: use ccache driver instead of helper function

[Zong Li]

On Wed, Jul 28, 2021 at 12:29 PM Sean Anderson  wrote:
>
> On 7/27/21 4:54 AM, Zong Li wrote:
> > Invokes the generic cache_enable interface to execute the relative
> > implementation in SiFive ccache driver.
> >
> > Signed-off-by: Zong Li 
> > ---
> >   arch/riscv/cpu/fu540/Kconfig  |  1 +
> >   arch/riscv/cpu/fu540/cache.c  | 62 ---
> >   arch/riscv/cpu/fu740/Kconfig  |  1 +
> >   arch/riscv/cpu/fu740/cache.c  | 60 +++---
> >   arch/riscv/include/asm/arch-fu540/cache.h |  2 +-
> >   arch/riscv/include/asm/arch-fu740/cache.h |  2 +-
> >   board/sifive/unleashed/unleashed.c| 10 +---
> >   board/sifive/unmatched/unmatched.c|  9 +---
> >   8 files changed, 45 insertions(+), 102 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
> > index 05463b2625..1f50b823ed 100644
> > --- a/arch/riscv/cpu/fu540/Kconfig
> > +++ b/arch/riscv/cpu/fu540/Kconfig
> > @@ -19,6 +19,7 @@ config SIFIVE_FU540
> >   imply SMP
> >   imply CLK_SIFIVE
> >   imply CLK_SIFIVE_PRCI
> > + imply SIFIVE_CACHE_CCACHE
> >   imply SIFIVE_SERIAL
> >   imply MACB
> >   imply MII
> > diff --git a/arch/riscv/cpu/fu540/cache.c b/arch/riscv/cpu/fu540/cache.c
> > index 0fc4ef6c00..3c754c4614 100644
> > --- a/arch/riscv/cpu/fu540/cache.c
> > +++ b/arch/riscv/cpu/fu540/cache.c
> > @@ -1,55 +1,33 @@
> >   // SPDX-License-Identifier: GPL-2.0+
> >   /*
> > - * Copyright (C) 2020 SiFive, Inc
> > + * Copyright (C) 2020 - 2021 SiFive, Inc
> >*
> >* Authors:
> >*   Pragnesh Patel 
> >*/
> >
> >   #include 
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> > +#include 
> >
> > -/* Register offsets */
> > -#define L2_CACHE_CONFIG  0x000
> > -#define L2_CACHE_ENABLE  0x008
> > -
> > -#define MASK_NUM_WAYSGENMASK(15, 8)
> > -#define NUM_WAYS_SHIFT   8
> > -
> > -DECLARE_GLOBAL_DATA_PTR;
> > -
> > -int cache_enable_ways(void)
> > +int sifive_ccache_enable_ways(void)
> >   {
>
> Is there any reason this function is duplicated? See below for further 
> comments.

Sorry, I don't completely understand about duplication here. Do you
mean why we need this function? or why is it present in both unleashed
and unmatched?

>
> > - const void *blob = gd->fdt_blob;
> > - int node;
> > - fdt_addr_t base;
> > - u32 config;
> > - u32 ways;
> > -
> > - volatile u32 *enable;
> > -
> > - node = fdt_node_offset_by_compatible(blob, -1,
> > -  "sifive,fu540-c000-ccache");
> > -
> > - if (node < 0)
> > - return node;
> > -
> > - base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
> > - NULL, false);
> > - if (base == FDT_ADDR_T_NONE)
> > - return FDT_ADDR_T_NONE;
> > -
> > - config = readl((volatile u32 *)base + L2_CACHE_CONFIG);
> > - ways = (config & MASK_NUM_WAYS) >> NUM_WAYS_SHIFT;
> > -
> > - enable = (volatile u32 *)(base + L2_CACHE_ENABLE);
> > + struct udevice *dev;
> > + int ret;
> > +
> > + ret = uclass_get_device_by_driver(UCLASS_CACHE,
> > +   DM_DRIVER_GET(sifive_ccache),
> > +   );
> > + if (ret) {
> > + pr_debug("%s: could not enable cache ways\n", __func__);
> > + return ret;
> > + }
> > +
> > + ret = cache_enable(dev);
> > + if (ret) {
> > + pr_debug("%s: ccache enable filed\n", __func__);
> > + return ret;
> > + }
> >
> > - /* memory barrier */
> > - mb();
> > - (*enable) = ways - 1;
> > - /* memory barrier */
> > - mb();
> >   return 0;
> >   }
> > diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
> > index 8e54310b9c..87d8016c88 100644
> > --- a/arch/riscv/cpu/fu740/Kconfig
> > +++ b/arch/riscv/cpu/fu740/Kconfig
> > @@ -19,6 +19,7 @@ config SIFIVE_FU740
> >   imply SMP
> >   imply CLK_SIFIVE
> >   imply CLK_SIFIVE_PRCI
> > + imply SIFIVE_CACHE_CCACHE
> >   imply SIFIVE_SERIAL
> >   imply MACB
> >   imply MII
> > diff --git a/arch/riscv/cpu/fu740/cache.c b/arch/riscv/cpu/fu740/cache.c
> > index 680955c9e3..1d6c295d98 100644
> > --- a/arch/riscv/cpu/fu740/cache.c
> > +++ b/arch/riscv/cpu/fu740/cache.c
> > @@ -7,49 +7,27 @@
> >*/
> >
> >   #include 
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> > +#include 
> >
> > -/* Register offsets */
> > -#define L2_CACHE_CONFIG  0x000
> > -#define L2_CACHE_ENABLE  0x008
> > -
> > -#define MASK_NUM_WAYSGENMASK(15, 8)
> > -#define NUM_WAYS_SHIFT   8
> > -
> > -DECLARE_GLOBAL_DATA_PTR;
> > -
> > -int cache_enable_ways(void)
> > +int sifive_ccache_enable_ways(void)
> >   {
> > - const void *blob = gd->fdt_blob;
> > - int node;
> > - fdt_addr_t base;
> > - u32 config;
> > -