Re: [PATCH] xilinx: Enable support for SquashFS

2022-06-27 Thread Michal Simek
čt 23. 6. 2022 v 13:04 odesílatel Michal Simek  napsal:
>
> Enable SquashFS for all xilinx platforms.
>
> Signed-off-by: Michal Simek 
> ---
>
>  configs/xilinx_versal_virt_defconfig | 1 +
>  configs/xilinx_zynq_virt_defconfig   | 1 +
>  configs/xilinx_zynqmp_virt_defconfig | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/configs/xilinx_versal_virt_defconfig 
> b/configs/xilinx_versal_virt_defconfig
> index c9ae0185f8ad..1ab9ae2ac3cb 100644
> --- a/configs/xilinx_versal_virt_defconfig
> +++ b/configs/xilinx_versal_virt_defconfig
> @@ -44,6 +44,7 @@ CONFIG_CMD_EFIDEBUG=y
>  CONFIG_CMD_TIME=y
>  CONFIG_CMD_TIMER=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_SQUASHFS=y
>  CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_UBI=y
>  CONFIG_PARTITION_TYPE_GUID=y
> diff --git a/configs/xilinx_zynq_virt_defconfig 
> b/configs/xilinx_zynq_virt_defconfig
> index 120bc29393d8..489e86adb344 100644
> --- a/configs/xilinx_zynq_virt_defconfig
> +++ b/configs/xilinx_zynq_virt_defconfig
> @@ -58,6 +58,7 @@ CONFIG_CMD_EFIDEBUG=y
>  CONFIG_CMD_TIME=y
>  CONFIG_CMD_TIMER=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_SQUASHFS=y
>  CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_MTDPARTS_SPREAD=y
>  CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
> diff --git a/configs/xilinx_zynqmp_virt_defconfig 
> b/configs/xilinx_zynqmp_virt_defconfig
> index de945c5c65b5..59b4cf6eaa2b 100644
> --- a/configs/xilinx_zynqmp_virt_defconfig
> +++ b/configs/xilinx_zynqmp_virt_defconfig
> @@ -81,6 +81,7 @@ CONFIG_CMD_TIMER=y
>  CONFIG_CMD_REGULATOR=y
>  CONFIG_CMD_TPM=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_SQUASHFS=y
>  CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_MTDPARTS_SPREAD=y
>  CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
> --
> 2.36.1
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


RE: [PATCH 18/20] kmcoge5ne: Move BFTIC3 CONFIG references to their usage

2022-06-27 Thread Holger Brunck
> 
> We only reference CONFIG_SYS_BFTIC3_BASE in one location.  Move the
> comment to where we reference it, and use the value directly.
> 
> Cc: Holger Brunck 
> Cc: Heiko Schocher 
> Signed-off-by: Tom Rini 
> ---
>  board/keymile/km83xx/km83xx.c | 6 --
>  include/configs/kmcoge5ne.h   | 6 --
>  2 files changed, 4 insertions(+), 8 deletions(-)
> 

Reviewed-By: Holger Brunck 

Best regards
Holger



Re: [PATCH] timer: Add SPL_REGMAP dependency for Xilinx timer

2022-06-27 Thread Michal Simek
čt 23. 6. 2022 v 13:08 odesílatel Michal Simek  napsal:
>
> Add SPL_REGMAP dependency when SPL is enabled. This can avoid compilation
> issues if timer is selected but SPL_REGMAP not.
>
> Reported-by: Ovidiu Panait 
> Signed-off-by: Michal Simek 
> ---
>
>  drivers/timer/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
> index 44d1a81bad3d..61156371a666 100644
> --- a/drivers/timer/Kconfig
> +++ b/drivers/timer/Kconfig
> @@ -276,6 +276,7 @@ config XILINX_TIMER
> bool "Xilinx timer support"
> depends on TIMER
> select REGMAP
> +   select SPL_REGMAP if SPL
> help
>   Select this to enable support for the timer found on
>   any Xilinx boards (axi timer).
> --
> 2.36.1
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


Re: [PATCH 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Joel Stanley
On Mon, 27 Jun 2022 at 07:12, Cédric Le Goater  wrote:
>
> Hello Chiawei,
>
> On 6/27/22 02:39, ChiaWei Wang wrote:
> > Reply again to leave record on mailing list.

Sorry, I re-sent it to get it on the list and managed to miss that for
the second time.

> >
> >> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> >> Sent: Friday, June 24, 2022 10:50 AM
> >>
> >> The Qemu model or the u-boot driver is unable to correctly compute the
> >> SHA256 hash used in a FIT. Disable it by default while that issue is 
> >> worked out
> >> to enable boot testing in Qemu.
> >>
> >> Signed-off-by: Joel Stanley 
> >> ---
> >>   configs/evb-ast2600_defconfig | 3 ---
> >>   1 file changed, 3 deletions(-)
> >>
> >> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> >> index f3a6cb222020..160bccff48e2 100644
> >> --- a/configs/evb-ast2600_defconfig
> >> +++ b/configs/evb-ast2600_defconfig
> >> @@ -59,9 +59,6 @@ CONFIG_REGMAP=y
> >>   CONFIG_SPL_OF_TRANSLATE=y
> >>   CONFIG_CLK=y
> >>   CONFIG_SPL_CLK=y
> >> -CONFIG_DM_HASH=y
> >> -CONFIG_HASH_ASPEED=y
> >> -CONFIG_ASPEED_ACRY=y
> >
> > Per our previous discussion, SPL code size still exists if all of AST2600 
> > features are upstream-ed.
> > Therefore, HW-assisted crypto drivers are needed.
> >
> > In addition, the current drivers works fine on real EVB to verify Hash + 
> > RSA signature (including the SHA256 in question).
> > This issue described in commit message should be attributed to incomplete 
> > QEMU emulation.
>
> When activating some debug in the hace driver :
>
>U-Boot SPL 2022.07-rc5-dirty (Jun 27 2022 - 09:01:28 +0200)
>already initialized, aspeed_2600_sdmc_write: SDMC is locked! (write to 
> MCR04 blocked)
>Trying to boot from RAM
>## Checking hash(es) for config conf-1 ... OK
>## Checking hash(es) for Image firmware-1 ... crc32Unsupported hash 
> algorithm 'crc32'
> error!
>Unsupported hash algorithm for 'hash-1' hash node in 'firmware-1' image 
> node
>
> It seems the problem comes from the unsupported 'crc32' algo.
> See aspeed_hace_init().

Well spotted. It needs a fallback implementation of the algorithms the
hash API supports but the hardware driver does not implement.

So we have three downsides of using the HACE driver:

 - Cannot DMA from SPI NOR, requiring a copy to RAM
 - Missing MD5 and CRC32 implementations, breaking the hash API
 - Broken Qemu emulation, meaning we cannot use it in OpenBMC as all
commits will fail CI

Obviously we can fix or find workarounds for these issues. However I
suggest while they are worked on we leave the HACE disabled in the
defconfig, so we can have build coverage in u-boot CI.

Once Aspeed completes the upstreaming of its u-boot port and therefore
hits the 64KB space limit, then we can look at re-enabling HACE in the
defconfig. Hopefully by then you will have resolved the issues with
the Qemu model.

Cheers,

Joel



>
> Thanks,
>
> C.
>
>
> >
> > Therefore, fixing QEMU should be the right way to go instead of disabling 
> > these options for real HW.
> >
> > Chiawei
> >
> >>   CONFIG_ASPEED_GPIO=y
> >>   CONFIG_DM_I2C=y
> >>   CONFIG_MISC=y
> >> --
> >> 2.35.1
> >
>


Re: [RFC PATCH] tools: kwbimage: Allow to disable compilation of kwbimage on non-mvebu platforms

2022-06-27 Thread Alexander Dahl
Hello,

Am Dienstag, 30. November 2021, 17:06:11 CEST schrieb Alexander Dahl:
> Am Thu, Oct 21, 2021 at 11:33:04AM +0200 schrieb Pali Rohár:
> > kwbimage depends on libcrypto. 32-bit mvebu platforms (except Orion and
> > Discovery, which are not in mach-mvebu) require kwimage for building SPL.
> > 
> > Some users want to compile u-boot tools without libcrypto.
> > 
> > Therefore add a new symbol CONFIG_TOOLS_KWBIMAGE which controls
> > compilation
> > of kwbimage and define correct dependences between mvebu, kwbimage and
> > libcrypto targets.
> > 
> > This allows disabling of kwbimage compilation on non-mvebu platforms.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> > 
> >  arch/arm/mach-mvebu/Kconfig | 1 +
> >  tools/Kconfig   | 5 +
> >  tools/Makefile  | 5 -
> >  3 files changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> > index 54dff9986b41..1ccbccea1dda 100644
> > --- a/arch/arm/mach-mvebu/Kconfig
> > +++ b/arch/arm/mach-mvebu/Kconfig
> > @@ -15,6 +15,7 @@ config ARMADA_32BIT
> > 
> > select SPL_SIMPLE_BUS if SPL
> > select SUPPORT_SPL
> > select TRANSLATION_OFFSET
> > 
> > +   select TOOLS_KWBIMAGE if SPL
> > 
> >  config ARMADA_64BIT
> >  
> > bool
> > 
> > diff --git a/tools/Kconfig b/tools/Kconfig
> > index 91ce8ae3e516..40866c5713d9 100644
> > --- a/tools/Kconfig
> > +++ b/tools/Kconfig
> > @@ -25,6 +25,11 @@ config TOOLS_LIBCRYPTO
> > 
> >   This selection does not affect target features, such as runtime FIT
> >   signature verification.
> > 
> > +config TOOLS_KWBIMAGE
> > +   bool "Enable kwbimage support in host tools"
> > +   default y
> > +   depends on TOOLS_LIBCRYPTO
> > +
> > 
> >  config TOOLS_FIT
> >  
> > def_bool y
> > help
> > 
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 75d8fe71d668..08f1f5a51fb3 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -118,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
> > 
> > imximage.o \
> > imx8image.o \
> > imx8mimage.o \
> > 
> > -   kwbimage.o \
> > 
> > lib/md5.o \
> > lpc32xximage.o \
> > mxsimage.o \
> > 
> > @@ -150,6 +149,10 @@ dumpimage-mkimage-objs := aisimage.o \
> > 
> > $(RSA_OBJS-y) \
> > $(AES_OBJS-y)
> > 
> > +ifdef CONFIG_TOOLS_KWBIMAGE
> > +dumpimage-mkimage-objs += kwbimage.o
> > +endif
> > +
> > 
> >  dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o
> >  mkimage-objs   := $(dumpimage-mkimage-objs) mkimage.o
> >  fit_info-objs   := $(dumpimage-mkimage-objs) fit_info.o
> 
> FWIW:
> 
> Tested-by: Alexander Dahl 

After migrating some boards from u-boot v2021.10 to v2022.01 I found this is 
still an issue.  Build for example at91 board fails if CONFIG_TOOLS_LIBCRYPTO 
is disabled and build host has no openssl headers installed.  
(Error output below.)

Could anyone please have a look at this patch again?  I don't need host tools 
linked with openssl.  When building with ptxdist, this only increases build 
time (for the additional host-openssl) for no benefit.

(Actually I don't need kwbimage for my target at all, why is it built for 
platforms not needing it in the first place?)


  HOSTLD  tools/mkimage
/usr/bin/ld: tools/kwbimage.o: in function `openssl_err':
kwbimage.c:(.text+0x9a): undefined reference to `ERR_get_error'
/usr/bin/ld: kwbimage.c:(.text+0xb6): undefined reference to 
`ERR_error_string'
/usr/bin/ld: tools/kwbimage.o: in function `kwb_compute_pubkey_hash':
kwbimage.c:(.text+0x119): undefined reference to `EVP_MD_CTX_new'
/usr/bin/ld: kwbimage.c:(.text+0x12d): undefined reference to 
`EVP_MD_CTX_reset'
/usr/bin/ld: kwbimage.c:(.text+0x132): undefined reference to `EVP_sha256'
/usr/bin/ld: kwbimage.c:(.text+0x13d): undefined reference to `EVP_DigestInit'
/usr/bin/ld: kwbimage.c:(.text+0x158): undefined reference to 
`EVP_DigestUpdate'
/usr/bin/ld: kwbimage.c:(.text+0x16c): undefined reference to 
`EVP_DigestFinal'
/usr/bin/ld: kwbimage.c:(.text+0x17a): undefined reference to 
`EVP_MD_CTX_reset'
/usr/bin/ld: kwbimage.c:(.text+0x182): undefined reference to 
`EVP_MD_CTX_free'
/usr/bin/ld: tools/kwbimage.o: in function `kwb_export_pubkey':
kwbimage.c:(.text+0x222): undefined reference to `RSA_get0_key'
/usr/bin/ld: kwbimage.c:(.text+0x233): undefined reference to `RSA_get0_key'
/usr/bin/ld: kwbimage.c:(.text+0x265): undefined reference to `BN_num_bits'
/usr/bin/ld: kwbimage.c:(.text+0x27a): undefined reference to `BN_num_bits'
/usr/bin/ld: kwbimage.c:(.text+0x2ee): undefined reference to `BN_bn2bin'
/usr/bin/ld: kwbimage.c:(.text+0x30b): undefined reference to `BN_bn2bin'
/usr/bin/ld: tools/kwbimage.o: in function `kwb_load_rsa_key':
kwbimage.c:(.text+0x4a1): undefined reference to `PEM_read_RSAPrivateKey'
/usr/bin/ld: tools/kwbimage.o: in function `kwb_sign':
kwbimage.c:(.text+0x

[PATCH RESEND 0/5] aspeed: Add AST2600 machine to CI

2022-06-27 Thread Joel Stanley
The Aspeed AST2600 is modelled in Qemu. This makes some configuration
changes so it can be added to CI.

It has a depednency on the u-boot-test-hooks patches I sent here:

 https://lore.kernel.org/u-boot/20220624023420.3925916-1-j...@jms.id.au

I've given it a run on Azure and the tests passed.

Joel Stanley (5):
  config/ast2600: Enable CRC32
  config/ast2600: Make position independent
  config/ast2600: Disable hash hardware accel
  ast2600: Configure u-boot-with-spl.bin target
  CI: Add Aspeed AST2600

 include/configs/evb_ast2600.h | 3 +++
 .azure-pipelines.yml  | 3 +++
 .gitlab-ci.yml| 6 ++
 configs/evb-ast2600_defconfig | 7 ---
 4 files changed, 16 insertions(+), 3 deletions(-)

-- 
2.35.1



[PATCH RESEND 2/5] config/ast2600: Make position independent

2022-06-27 Thread Joel Stanley
Allows loading one u-boot from another. Useful for testing on hardware.

Signed-off-by: Joel Stanley 
---
 configs/evb-ast2600_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 53ba36a28374..f3a6cb222020 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_SYS_DCACHE_OFF=y
+CONFIG_POSITION_INDEPENDENT=y
 CONFIG_SPL_SYS_THUMB_BUILD=y
 CONFIG_ARCH_ASPEED=y
 CONFIG_SYS_TEXT_BASE=0x8000
-- 
2.35.1



[PATCH RESEND 4/5] ast2600: Configure u-boot-with-spl.bin target

2022-06-27 Thread Joel Stanley
For the u-boot-with-spl.bin target to be useful for the AST2600, set the
maximum SPL size which also sets the padding length.

The normal way of loading u-boot is as a FIT, so configure u-boot.img as
the SPL playload.

With this the following simple steps can be used to build and boot a
system:

  make u-boot-with-spl.bin
  truncate -s 64M u-boot-with-spl.bin
  qemu-system-arm -nographic -M ast2600-evb \
-drive file=u-boot-with-spl.bin,if=mtd,format=raw

Signed-off-by: Joel Stanley 
---
 include/configs/evb_ast2600.h | 3 +++
 configs/evb-ast2600_defconfig | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h
index 3c2155da46df..f5ac88447b52 100644
--- a/include/configs/evb_ast2600.h
+++ b/include/configs/evb_ast2600.h
@@ -10,6 +10,9 @@
 
 #define CONFIG_SYS_UBOOT_BASE  CONFIG_SYS_TEXT_BASE
 
+/* The maximum size the AST2600 bootrom can load is 64KB */
+#define CONFIG_SPL_MAX_SIZE65536
+
 /* Misc */
 #define STR_HELPER(s)  #s
 #define STR(s) STR_HELPER(s)
diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 160bccff48e2..5230515f7ab6 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_SIZE_LIMIT=0x1
 CONFIG_SPL=y
 # CONFIG_ARMV7_NONSEC is not set
 CONFIG_SYS_LOAD_ADDR=0x8300
+CONFIG_SPL_PAYLOAD="u-boot.img"
+CONFIG_BUILD_TARGET="u-boot-with-spl.bin"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_FIT=y
 CONFIG_SPL_FIT_SIGNATURE=y
-- 
2.35.1



[PATCH RESEND 5/5] CI: Add Aspeed AST2600

2022-06-27 Thread Joel Stanley
The AST2600 has a Qemu model that allows testing. Create a SPI NOR image
containing the combined SPL and u-boot FIT image.

Signed-off-by: Joel Stanley 
---
 .azure-pipelines.yml | 3 +++
 .gitlab-ci.yml   | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index ad540ea63536..bdc515ebcdc1 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -261,6 +261,9 @@ stages:
 evb_ast2500:
   TEST_PY_BD: "evb-ast2500"
   TEST_PY_ID: "--id qemu"
+evb_ast2600:
+  TEST_PY_BD: "evb-ast2600"
+  TEST_PY_ID: "--id qemu"
 vexpress_ca9x4:
   TEST_PY_BD: "vexpress_ca9x4"
   TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c6a608f7e2a7..f9cd41750791 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -272,6 +272,12 @@ evb-ast2500 test.py:
 TEST_PY_ID: "--id qemu"
   <<: *buildman_and_testpy_dfn
 
+evb-ast2600 test.py:
+  variables:
+TEST_PY_BD: "evb-ast2600"
+TEST_PY_ID: "--id qemu"
+  <<: *buildman_and_testpy_dfn
+
 sandbox_flattree test.py:
   variables:
 TEST_PY_BD: "sandbox_flattree"
-- 
2.35.1



[PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Joel Stanley
The HACE driver lacks support for all the hash types, causing boot to
fail with the default FIT configuration which uses CRC32.

Additionally the Qemu model or the u-boot driver is unable to correctly
compute the SHA256 hash used in a FIT.

Disable HACE by default while the above issues are worked out to enable
boot testing in Qemu.

Signed-off-by: Joel Stanley 
---
 configs/evb-ast2600_defconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f3a6cb222020..160bccff48e2 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -59,9 +59,6 @@ CONFIG_REGMAP=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
-CONFIG_DM_HASH=y
-CONFIG_HASH_ASPEED=y
-CONFIG_ASPEED_ACRY=y
 CONFIG_ASPEED_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_MISC=y
-- 
2.35.1



[PATCH RESEND 1/5] config/ast2600: Enable CRC32

2022-06-27 Thread Joel Stanley
Useful for testing images with the default hash type.

Signed-off-by: Joel Stanley 
---
 configs/evb-ast2600_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f84b723bbba3..53ba36a28374 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -35,6 +35,7 @@ CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
+CONFIG_SPL_CRC32=y
 CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_DM_RESET=y
 CONFIG_SPL_RAM_SUPPORT=y
-- 
2.35.1



Re: [RFC PATCH] tools: kwbimage: Allow to disable compilation of kwbimage on non-mvebu platforms

2022-06-27 Thread Pali Rohár
On Monday 27 June 2022 09:53:22 Alexander Dahl wrote:
> After migrating some boards from u-boot v2021.10 to v2022.01 I found this is 
> still an issue.  Build for example at91 board fails if CONFIG_TOOLS_LIBCRYPTO 
> is disabled and build host has no openssl headers installed.  
> (Error output below.)
> 
> Could anyone please have a look at this patch again?

Reviewing / accepting this patch is up to the u-boot maintainers, not
me. I just provided this patch as I think it could be useful.

> (Actually I don't need kwbimage for my target at all, why is it built for 
> platforms not needing it in the first place?)

This is because mkimage is generic tool which supports all image formats
supported by U-Boot. For example on x86 host it allows users to build
different ARM images, not only x86. I guess this is primary intended for
Linux distributions to support all U-Boot targets...


RE: [PATCH RESEND 2/5] config/ast2600: Make position independent

2022-06-27 Thread ChiaWei Wang
Reviewed-by: Chia-Wei Wang 

> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 27, 2022 3:58 PM
> 
> Allows loading one u-boot from another. Useful for testing on hardware.
> 
> Signed-off-by: Joel Stanley 
> ---
>  configs/evb-ast2600_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> index 53ba36a28374..f3a6cb222020 100644
> --- a/configs/evb-ast2600_defconfig
> +++ b/configs/evb-ast2600_defconfig
> @@ -1,5 +1,6 @@
>  CONFIG_ARM=y
>  CONFIG_SYS_DCACHE_OFF=y
> +CONFIG_POSITION_INDEPENDENT=y
>  CONFIG_SPL_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_ASPEED=y
>  CONFIG_SYS_TEXT_BASE=0x8000
> --
> 2.35.1



RE: [PATCH RESEND 1/5] config/ast2600: Enable CRC32

2022-06-27 Thread ChiaWei Wang
Reviewed-by: Chia-Wei Wang 

> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 27, 2022 3:58 PM
> 
> Useful for testing images with the default hash type.
> 
> Signed-off-by: Joel Stanley 
> ---
>  configs/evb-ast2600_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> index f84b723bbba3..53ba36a28374 100644
> --- a/configs/evb-ast2600_defconfig
> +++ b/configs/evb-ast2600_defconfig
> @@ -35,6 +35,7 @@ CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
> +CONFIG_SPL_CRC32=y
>  CONFIG_SPL_FIT_IMAGE_TINY=y
>  CONFIG_SPL_DM_RESET=y
>  CONFIG_SPL_RAM_SUPPORT=y
> --
> 2.35.1



RE: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread ChiaWei Wang
Reviewed-by: Chia-Wei Wang 

The QEMU emulation issue is under investigation by Steven.
The CRC32 and MD5 SW support will be added before we re-enabling HW crypto 
drivers.

Chiawei

> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 27, 2022 3:58 PM
> 
> The HACE driver lacks support for all the hash types, causing boot to fail 
> with
> the default FIT configuration which uses CRC32.
> 
> Additionally the Qemu model or the u-boot driver is unable to correctly
> compute the SHA256 hash used in a FIT.
> 
> Disable HACE by default while the above issues are worked out to enable boot
> testing in Qemu.
> 
> Signed-off-by: Joel Stanley 
> ---
>  configs/evb-ast2600_defconfig | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> index f3a6cb222020..160bccff48e2 100644
> --- a/configs/evb-ast2600_defconfig
> +++ b/configs/evb-ast2600_defconfig
> @@ -59,9 +59,6 @@ CONFIG_REGMAP=y
>  CONFIG_SPL_OF_TRANSLATE=y
>  CONFIG_CLK=y
>  CONFIG_SPL_CLK=y
> -CONFIG_DM_HASH=y
> -CONFIG_HASH_ASPEED=y
> -CONFIG_ASPEED_ACRY=y
>  CONFIG_ASPEED_GPIO=y
>  CONFIG_DM_I2C=y
>  CONFIG_MISC=y
> --
> 2.35.1



RE: [PATCH RESEND 4/5] ast2600: Configure u-boot-with-spl.bin target

2022-06-27 Thread ChiaWei Wang
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 27, 2022 3:58 PM
> 
> For the u-boot-with-spl.bin target to be useful for the AST2600, set the
> maximum SPL size which also sets the padding length.
> 
> The normal way of loading u-boot is as a FIT, so configure u-boot.img as the
> SPL playload.
> 
> With this the following simple steps can be used to build and boot a
> system:
> 
>   make u-boot-with-spl.bin
>   truncate -s 64M u-boot-with-spl.bin
>   qemu-system-arm -nographic -M ast2600-evb \
> -drive file=u-boot-with-spl.bin,if=mtd,format=raw
> 
> Signed-off-by: Joel Stanley 
> ---
>  include/configs/evb_ast2600.h | 3 +++
>  configs/evb-ast2600_defconfig | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h
> index 3c2155da46df..f5ac88447b52 100644
> --- a/include/configs/evb_ast2600.h
> +++ b/include/configs/evb_ast2600.h
> @@ -10,6 +10,9 @@
> 
>  #define CONFIG_SYS_UBOOT_BASECONFIG_SYS_TEXT_BASE
> 
> +/* The maximum size the AST2600 bootrom can load is 64KB */
> +#define CONFIG_SPL_MAX_SIZE  65536
> +

Please have this to be synced with CONFIG_SPL_SIZE_LIMIT. Thanks.

Reviewed-by: Chia-Wei Wang 


Re: spi-nand: how to store environment with badblock handling in qspi nand

2022-06-27 Thread Kegl Rohit
On Sun, Jun 26, 2022 at 2:02 AM Daniel Golle  wrote:
>
> On Sat, Jun 25, 2022 at 10:10:08AM +0200, Kegl Rohit wrote:
> > Hello!
> >
> > Is it possible to store the environment inside a mtd partition when
> > using a single qspi nand chip as storage?
> > CONFIG_MTD_SPI_NAND=y
> >
> > The idea is to separate the NAND into two system A/B.
> > [...]
> >
> > CONFIG_ENV_IS_IN_UBI will do badblock handling, but it would be a huge
> > overhead to create an extra ubifs mtd partition only for the
> > environment.
>
> Actually it's not. The overhead of allocating a UBI volume is minimal
> and typical logical block sizes are small enough to not be complete
> overkill for something like a U-Boot environment.
>

For 1.Solution it is not a big overhead.
But if i want to isolate a/b completely e.g.

3.Solution:
mtdparts_nand0=2m(uboot),1m(env_ubi),8m(system_a),8m(system_b)
system_a/b ubifs is completely isolated and environment and
environment_redundant stored in addtional env_ubi.
It looks like ubi needs at least 2mb @ 128kb eraseblocks for itself.
So a lot of wasted space for e.g. 128kb environment.


> > Has anyone already created the A/B system approach with the mtd spi
> > nand interface and can give me some input?
>
> Maybe see here for inspiration:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/410-add-linksys-e8450.patch;h=fde679f3863ccf2e22a3e1fd299963b66041a0b9;hb=HEAD#l403
>
This seems to match my 1.Solution. system_a/b volumes are in same ubi
mtd partition and are not really isolated.


RE: [PATCH RESEND 5/5] CI: Add Aspeed AST2600

2022-06-27 Thread ChiaWei Wang
Reviewed-by: Chia-Wei Wang 

> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 27, 2022 3:58 PM
> 
> The AST2600 has a Qemu model that allows testing. Create a SPI NOR image
> containing the combined SPL and u-boot FIT image.
> 
> Signed-off-by: Joel Stanley 
> ---
>  .azure-pipelines.yml | 3 +++
>  .gitlab-ci.yml   | 6 ++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index
> ad540ea63536..bdc515ebcdc1 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -261,6 +261,9 @@ stages:
>  evb_ast2500:
>TEST_PY_BD: "evb-ast2500"
>TEST_PY_ID: "--id qemu"
> +evb_ast2600:
> +  TEST_PY_BD: "evb-ast2600"
> +  TEST_PY_ID: "--id qemu"
>  vexpress_ca9x4:
>TEST_PY_BD: "vexpress_ca9x4"
>TEST_PY_ID: "--id qemu"
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index c6a608f7e2a7..f9cd41750791
> 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -272,6 +272,12 @@ evb-ast2500 test.py:
>  TEST_PY_ID: "--id qemu"
><<: *buildman_and_testpy_dfn
> 
> +evb-ast2600 test.py:
> +  variables:
> +TEST_PY_BD: "evb-ast2600"
> +TEST_PY_ID: "--id qemu"
> +  <<: *buildman_and_testpy_dfn
> +
>  sandbox_flattree test.py:
>variables:
>  TEST_PY_BD: "sandbox_flattree"
> --
> 2.35.1



Re: [PATCH 1/3] ram: rk3399: Fix .set_rate_index() error handling

2022-06-27 Thread Lee Jones
On Tue, 21 Jun 2022, Lee Jones wrote:

> Functions pointed to by this op pointer can return non-zero values
> indicating an error.  Ensure any error value is propagated back up the
> call-chain.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/ram/rockchip/sdram_rk3399.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Weekly check-in:

Are these still on someone's radar, or would you like me to [RESEND]?

> diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
> b/drivers/ram/rockchip/sdram_rk3399.c
> index c0a06dcaed..0af0fa9e7b 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ b/drivers/ram/rockchip/sdram_rk3399.c
> @@ -3005,7 +3005,9 @@ static int sdram_init(struct dram_info *dram,
>   params->base.stride = calculate_stride(params);
>   dram_all_config(dram, params);
>  
> - dram->ops->set_rate_index(dram, params);
> + ret = dram->ops->set_rate_index(dram, params);
> + if (ret)
> + return ret;
>  
>   debug("Finish SDRAM initialization...\n");
>   return 0;

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH] efi_loader: Allow overlapped extra data for PE hashing

2022-06-27 Thread Su, Bao Cheng
On Mon, 2022-06-27 at 06:55 +0200, Heinrich Schuchardt wrote:
> On 6/27/22 05:43, Su, Bao Cheng wrote:
> > On Fri, 2022-06-24 at 11:44 +0200, Jan Kiszka wrote:
> > > On 24.06.22 10:53, Heinrich Schuchardt wrote:
> > > > On 6/24/22 07:32, Su, Bao Cheng wrote:
> > > > > During PE hashing, when holes exists between sections, the
> > > > > extra
> > > > > data
> > > > > calculated could be a dupulicated region of the last section.
> > > > > 
> > > > > Such PE image with holes existing between sections may
> > > > > contain
> > > > > the
> > > > > symbol table for the kernel, for example.
> > > > > 
> > > > > The Authenticode_PE spec does not rule how to deal with such
> > > > > scenario,
> > > > > however, other tools such as pesign and sbsign both have the
> > > > > overlapped
> > > > 
> > > > Thanks for analyzing differences in hashing.
> > > > 
> > > > Above you mention holes between sections. Here you talk about
> > > > overlapping sections. These two cases are obviously distinct.
> > > > 
> > > > Please, provide an accurate description.
> > > 
> > > Yeah, I also gave that feedback internally already as it left me
> > > a
> > > bit
> > > confused.
> > > 
> > > > 
> > > > Examples (in text form) would be helpful.
> > > 
> > > There is apparently no good PE dump tooling available, so I try
> > > to
> > > describe our scenario verbally:
> 
> You could try 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxypron%2Fefi_analyzer&data=05%7C01%7Cbaocheng.su%40ad011.siemens.com%7Cc732b1c183ff4cf56ca708da57f943f2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637919025335317245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W1gO6h2%2BiFSUzdNTFi551gyoxlybMOEwQgBnf%2Bswnjw%3D&reserved=0
> .
> 
> > > 
> > > We are generating a unified kernel image, similar to what systemd
> > > does,
> > > for ARM and ARM64 [1]. The stub has .text and .data sections, and
> > > then
> > > follows the symbol table (some versions of binutils allow to
> > > suppress
> > > it, other not, sigh). When appending the actual payload to that
> > > (kernel
> > > image, command line, initrd, dtbs), those sections are added
> > > right
> > > after
> > > the symbol table, creating an unhashed gap between the last stub
> > > section
> > > and the first appended one. That unified linux.efi is then signed
> > > and
> > > should be verifiable and bootable (as it is with EDK2).
> > > 
> > 
> > I will try to give a more straightforward description, considering
> > below PE image:
> > 
> > ## PE Header:
> >    @0x
> >     ...
> > ### Section Header 1:
> >    ...
> >    @0x0108 : 0x8000 - SizeOfRawData
> >    @0x010C : 0x1000 - PointerToRawData
> >    ...
> > ### Section Header 2:
> >    ...
> >    @0x0130 : 0x1C00 - SizeOfRawData
> >    @0x0134 : 0x9000 - PointerToRawData
> >    ...
> > ### Section Header 3:
> >    ...
> >    @0x0158 : 0x1200 - SizeOfRawData
> >    @0x015C : 0xB200 - PointerToRawData
> >    ...
> > 
> >  From the section headers, the end offset of section 2 is 0x1C00 +
> > 0x9000 = 0xAC00, however, the start offset of the section 3 is
> > 0xB200,
> > there is a `hole` here of size 0x600 bytes. In our case Jan has
> > explained this is the symbol table.
> > 
> > According to PE hasing spec, when finished the parsing of sections,
> > the
> > bytes_hashed should be calculated and compared to the (total PE
> > size -
> > auth size), and if the bytes_hashed is lesser, it means there are
> > extra
> > data need be hashed as well.
> > 
> > According to spec, the offset of the extra data is set to
> > bytes_hashed,
> > this does not cause overlapping for a normal PE image without holes
> > between sections, because the bytes_hashed is equal to the tail of
> > the
> > last section. However, for our case the extra data is the
> > overlapped
> > with the last section or sections, because the bytes_hashed is
> > lesser
> > than the tail of the last section due to the `hole`.
> > 
> > U-Boot currently considers this part of data as overlapped and
> > excludes
> > them from the hashing, however other tools or BLs such as
> > pesign/sbsign/EDK2 do not rule out the overlapped data, the hash
> > result
> 
> "Overlap" means that bytes of the image belong to two sections.
> 
> An example of overlap would be:
> 
> section 1: 0x1000 - 0x2000
> section 2: 0x1800 - 0x2800
> 
> "Gap" means that bytes between two sections don't belong to any
> section:
> 
> section1: 0x1000 - 0x2000
> section2: 0x2800 - 0x3800
> 

Gap between sections (in our case between section 2 and 3) produces the
overlapped data while hashing, due to MicroSoft's algorithm.

Baocheng

> > stays consistent among these tools, although the last part is
> > hashed
> > twice indeed.
> 
> We will have to update U-Boot's unit tests to contain an example with
> a
> gap. How do you c

[PATCH] mmc: zynq_sdhci: Fix timing macros for MMC High speed

2022-06-27 Thread Ashok Reddy Soma
Timing macro's are wrong for MMC_HS_52 and MMC_DDR_52. Fix it with
correct values of MMC_TIMING_MMC_HS and MMC_TIMING_MMC_DDR52 respectively.

Signed-off-by: Ashok Reddy Soma 
---

 drivers/mmc/zynq_sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index e978b67988..8f4071c8c2 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -101,8 +101,8 @@ static const u8 mode2timing[] = {
[MMC_LEGACY] = MMC_TIMING_LEGACY,
[MMC_HS] = MMC_TIMING_MMC_HS,
[SD_HS] = MMC_TIMING_SD_HS,
-   [MMC_HS_52] = MMC_TIMING_UHS_SDR50,
-   [MMC_DDR_52] = MMC_TIMING_UHS_DDR50,
+   [MMC_HS_52] = MMC_TIMING_MMC_HS,
+   [MMC_DDR_52] = MMC_TIMING_MMC_DDR52,
[UHS_SDR12] = MMC_TIMING_UHS_SDR12,
[UHS_SDR25] = MMC_TIMING_UHS_SDR25,
[UHS_SDR50] = MMC_TIMING_UHS_SDR50,
-- 
2.17.1



Re: [PATCH] efi_loader: Allow overlapped extra data for PE hashing

2022-06-27 Thread Su, Bao Cheng
On Fri, 2022-06-24 at 11:44 +0200, Jan Kiszka wrote:
> On 24.06.22 10:53, Heinrich Schuchardt wrote:
> > On 6/24/22 07:32, Su, Bao Cheng wrote:
> > > During PE hashing, when holes exists between sections, the extra
> > > data
> > > calculated could be a dupulicated region of the last section.
> > > 
> > > Such PE image with holes existing between sections may contain
> > > the
> > > symbol table for the kernel, for example.
> > > 
> > > The Authenticode_PE spec does not rule how to deal with such
> > > scenario,
> > > however, other tools such as pesign and sbsign both have the
> > > overlapped
> > 
> > Thanks for analyzing differences in hashing.
> > 
> > Above you mention holes between sections. Here you talk about
> > overlapping sections. These two cases are obviously distinct.
> > 
> > Please, provide an accurate description.
> 
> Yeah, I also gave that feedback internally already as it left me a
> bit
> confused.
> 
> > 
> > Examples (in text form) would be helpful.
> 
> There is apparently no good PE dump tooling available, so I try to
> describe our scenario verbally:
> 
> We are generating a unified kernel image, similar to what systemd
> does,
> for ARM and ARM64 [1]. The stub has .text and .data sections, and
> then
> follows the symbol table (some versions of binutils allow to suppress
> it, other not, sigh). When appending the actual payload to that
> (kernel
> image, command line, initrd, dtbs), those sections are added right
> after
> the symbol table, creating an unhashed gap between the last stub
> section
> and the first appended one. That unified linux.efi is then signed and
> should be verifiable and bootable (as it is with EDK2).
> 

I will try to give a more straightforward description, considering
below PE image:

## PE Header:
  @0x
   ...
### Section Header 1:
  ...
  @0x0108 : 0x8000 - SizeOfRawData
  @0x010C : 0x1000 - PointerToRawData
  ...
### Section Header 2:
  ...
  @0x0130 : 0x1C00 - SizeOfRawData
  @0x0134 : 0x9000 - PointerToRawData
  ...
### Section Header 3:
  ...
  @0x0158 : 0x1200 - SizeOfRawData
  @0x015C : 0xB200 - PointerToRawData
  ...

From the section headers, the end offset of section 2 is 0x1C00 +
0x9000 = 0xAC00, however, the start offset of the section 3 is 0xB200,
there is a `hole` here of size 0x600 bytes. In our case Jan has
explained this is the symbol table.

According to PE hasing spec, when finished the parsing of sections, the
bytes_hashed should be calculated and compared to the (total PE size -
auth size), and if the bytes_hashed is lesser, it means there are extra
data need be hashed as well. 

According to spec, the offset of the extra data is set to bytes_hashed,
this does not cause overlapping for a normal PE image without holes
between sections, because the bytes_hashed is equal to the tail of the
last section. However, for our case the extra data is the overlapped
with the last section or sections, because the bytes_hashed is lesser
than the tail of the last section due to the `hole`.

U-Boot currently considers this part of data as overlapped and excludes
them from the hashing, however other tools or BLs such as
pesign/sbsign/EDK2 do not rule out the overlapped data, the hash result
stays consistent among these tools, although the last part is hashed
twice indeed.

Baocheng

> HTH,
> Jan
> 
> [1]
> https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md
> 



Re: [PATCH 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Cédric Le Goater

Hello Chiawei,

On 6/27/22 02:39, ChiaWei Wang wrote:

Reply again to leave record on mailing list.


From: joel.s...@gmail.com  On Behalf Of Joel Stanley
Sent: Friday, June 24, 2022 10:50 AM

The Qemu model or the u-boot driver is unable to correctly compute the
SHA256 hash used in a FIT. Disable it by default while that issue is worked out
to enable boot testing in Qemu.

Signed-off-by: Joel Stanley 
---
  configs/evb-ast2600_defconfig | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f3a6cb222020..160bccff48e2 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -59,9 +59,6 @@ CONFIG_REGMAP=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_CLK=y
  CONFIG_SPL_CLK=y
-CONFIG_DM_HASH=y
-CONFIG_HASH_ASPEED=y
-CONFIG_ASPEED_ACRY=y


Per our previous discussion, SPL code size still exists if all of AST2600 
features are upstream-ed.
Therefore, HW-assisted crypto drivers are needed.

In addition, the current drivers works fine on real EVB to verify Hash + RSA 
signature (including the SHA256 in question).
This issue described in commit message should be attributed to incomplete QEMU 
emulation.


When activating some debug in the hace driver :

  U-Boot SPL 2022.07-rc5-dirty (Jun 27 2022 - 09:01:28 +0200)
  already initialized, aspeed_2600_sdmc_write: SDMC is locked! (write to MCR04 
blocked)
  Trying to boot from RAM
  ## Checking hash(es) for config conf-1 ... OK
  ## Checking hash(es) for Image firmware-1 ... crc32Unsupported hash algorithm 
'crc32'
   error!
  Unsupported hash algorithm for 'hash-1' hash node in 'firmware-1' image node

It seems the problem comes from the unsupported 'crc32' algo.
See aspeed_hace_init().

Thanks,

C.




Therefore, fixing QEMU should be the right way to go instead of disabling these 
options for real HW.

Chiawei


  CONFIG_ASPEED_GPIO=y
  CONFIG_DM_I2C=y
  CONFIG_MISC=y
--
2.35.1






Re: [PATCH RESEND 1/5] config/ast2600: Enable CRC32

2022-06-27 Thread Cédric Le Goater

On 6/27/22 09:58, Joel Stanley wrote:

Useful for testing images with the default hash type.

Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

Thanks,

C.


---
  configs/evb-ast2600_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f84b723bbba3..53ba36a28374 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -35,6 +35,7 @@ CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
  CONFIG_SPL_STACK_R=y
  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
+CONFIG_SPL_CRC32=y
  CONFIG_SPL_FIT_IMAGE_TINY=y
  CONFIG_SPL_DM_RESET=y
  CONFIG_SPL_RAM_SUPPORT=y




Re: [PATCH RESEND 2/5] config/ast2600: Make position independent

2022-06-27 Thread Cédric Le Goater

On 6/27/22 09:58, Joel Stanley wrote:

Allows loading one u-boot from another. Useful for testing on hardware.

Signed-off-by: Joel Stanley 
---


Reviewed-by: Cédric Le Goater 

Thanks,

C.



  configs/evb-ast2600_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 53ba36a28374..f3a6cb222020 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -1,5 +1,6 @@
  CONFIG_ARM=y
  CONFIG_SYS_DCACHE_OFF=y
+CONFIG_POSITION_INDEPENDENT=y
  CONFIG_SPL_SYS_THUMB_BUILD=y
  CONFIG_ARCH_ASPEED=y
  CONFIG_SYS_TEXT_BASE=0x8000




Re: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Cédric Le Goater

On 6/27/22 09:58, Joel Stanley wrote:

The HACE driver lacks support for all the hash types, causing boot to
fail with the default FIT configuration which uses CRC32.

Additionally the Qemu model or the u-boot driver is unable to correctly
compute the SHA256 hash used in a FIT.

Disable HACE by default while the above issues are worked out to enable
boot testing in Qemu.

Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  configs/evb-ast2600_defconfig | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f3a6cb222020..160bccff48e2 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -59,9 +59,6 @@ CONFIG_REGMAP=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_CLK=y
  CONFIG_SPL_CLK=y
-CONFIG_DM_HASH=y
-CONFIG_HASH_ASPEED=y
-CONFIG_ASPEED_ACRY=y
  CONFIG_ASPEED_GPIO=y
  CONFIG_DM_I2C=y
  CONFIG_MISC=y




Re: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Cédric Le Goater

On 6/27/22 10:15, ChiaWei Wang wrote:

Reviewed-by: Chia-Wei Wang 

The QEMU emulation issue is under investigation by Steven.


Great ! I was going to open a gitlab issue under :

  https://gitlab.com/qemu-project/qemu/-/issues/

But we still have a couple of weeks before QEMU 7.1 soft freeze :

  https://wiki.qemu.org/Planning/7.1

We should open one if not solved before, as a reminder, with
some guidelines to reproduce. It


The CRC32 and MD5 SW support will be added before we re-enabling HW crypto 
drivers.


Thanks,

C.


Chiawei


From: joel.s...@gmail.com  On Behalf Of Joel Stanley
Sent: Monday, June 27, 2022 3:58 PM

The HACE driver lacks support for all the hash types, causing boot to fail with
the default FIT configuration which uses CRC32.

Additionally the Qemu model or the u-boot driver is unable to correctly
compute the SHA256 hash used in a FIT.

Disable HACE by default while the above issues are worked out to enable boot
testing in Qemu.

Signed-off-by: Joel Stanley 
---
  configs/evb-ast2600_defconfig | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f3a6cb222020..160bccff48e2 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -59,9 +59,6 @@ CONFIG_REGMAP=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_CLK=y
  CONFIG_SPL_CLK=y
-CONFIG_DM_HASH=y
-CONFIG_HASH_ASPEED=y
-CONFIG_ASPEED_ACRY=y
  CONFIG_ASPEED_GPIO=y
  CONFIG_DM_I2C=y
  CONFIG_MISC=y
--
2.35.1






Re: [PATCH RESEND 4/5] ast2600: Configure u-boot-with-spl.bin target

2022-06-27 Thread Cédric Le Goater

On 6/27/22 09:58, Joel Stanley wrote:

For the u-boot-with-spl.bin target to be useful for the AST2600, set the
maximum SPL size which also sets the padding length.

The normal way of loading u-boot is as a FIT, so configure u-boot.img as
the SPL playload.

With this the following simple steps can be used to build and boot a
system:

   make u-boot-with-spl.bin
   truncate -s 64M u-boot-with-spl.bin
   qemu-system-arm -nographic -M ast2600-evb \
 -drive file=u-boot-with-spl.bin,if=mtd,format=raw

Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  include/configs/evb_ast2600.h | 3 +++
  configs/evb-ast2600_defconfig | 2 ++
  2 files changed, 5 insertions(+)

diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h
index 3c2155da46df..f5ac88447b52 100644
--- a/include/configs/evb_ast2600.h
+++ b/include/configs/evb_ast2600.h
@@ -10,6 +10,9 @@
  
  #define CONFIG_SYS_UBOOT_BASE		CONFIG_SYS_TEXT_BASE
  
+/* The maximum size the AST2600 bootrom can load is 64KB */

+#define CONFIG_SPL_MAX_SIZE65536
+
  /* Misc */
  #define STR_HELPER(s) #s
  #define STR(s)STR_HELPER(s)
diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 160bccff48e2..5230515f7ab6 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_SIZE_LIMIT=0x1
  CONFIG_SPL=y
  # CONFIG_ARMV7_NONSEC is not set
  CONFIG_SYS_LOAD_ADDR=0x8300
+CONFIG_SPL_PAYLOAD="u-boot.img"
+CONFIG_BUILD_TARGET="u-boot-with-spl.bin"
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_FIT=y
  CONFIG_SPL_FIT_SIGNATURE=y




Re: [PATCH RESEND 5/5] CI: Add Aspeed AST2600

2022-06-27 Thread Cédric Le Goater

On 6/27/22 09:58, Joel Stanley wrote:

The AST2600 has a Qemu model that allows testing. Create a SPI NOR image
containing the combined SPL and u-boot FIT image.

Signed-off-by: Joel Stanley 




Reviewed-by: Cédric Le Goater 

Thanks,

C.


---
  .azure-pipelines.yml | 3 +++
  .gitlab-ci.yml   | 6 ++
  2 files changed, 9 insertions(+)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index ad540ea63536..bdc515ebcdc1 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -261,6 +261,9 @@ stages:
  evb_ast2500:
TEST_PY_BD: "evb-ast2500"
TEST_PY_ID: "--id qemu"
+evb_ast2600:
+  TEST_PY_BD: "evb-ast2600"
+  TEST_PY_ID: "--id qemu"
  vexpress_ca9x4:
TEST_PY_BD: "vexpress_ca9x4"
TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c6a608f7e2a7..f9cd41750791 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -272,6 +272,12 @@ evb-ast2500 test.py:
  TEST_PY_ID: "--id qemu"
<<: *buildman_and_testpy_dfn
  
+evb-ast2600 test.py:

+  variables:
+TEST_PY_BD: "evb-ast2600"
+TEST_PY_ID: "--id qemu"
+  <<: *buildman_and_testpy_dfn
+
  sandbox_flattree test.py:
variables:
  TEST_PY_BD: "sandbox_flattree"




RE: [PATCH 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Steven Lee
Hi Joel,

I was wondering if you could share the commit hash of u-boot you tested.
I would like to test it on qemu.

Thanks,
Steven

* Email Confidentiality Notice 
DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other 
confidential information. If you have received it in error, please notify the 
sender by reply e-mail and immediately delete the e-mail and any attachments 
without copying or disclosing the contents. Thank you.

-Original Message-
From: Joel Stanley  
Sent: Monday, June 27, 2022 3:40 PM
To: Cédric Le Goater 
Cc: ChiaWei Wang ; u-boot@lists.denx.de; Ryan Chen 
; BMC-SW 
Subject: Re: [PATCH 3/5] config/ast2600: Disable hash hardware accel

On Mon, 27 Jun 2022 at 07:12, Cédric Le Goater  wrote:
>
> Hello Chiawei,
>
> On 6/27/22 02:39, ChiaWei Wang wrote:
> > Reply again to leave record on mailing list.

Sorry, I re-sent it to get it on the list and managed to miss that for the 
second time.

> >
> >> From: joel.s...@gmail.com  On Behalf Of Joel 
> >> Stanley
> >> Sent: Friday, June 24, 2022 10:50 AM
> >>
> >> The Qemu model or the u-boot driver is unable to correctly compute 
> >> the
> >> SHA256 hash used in a FIT. Disable it by default while that issue 
> >> is worked out to enable boot testing in Qemu.
> >>
> >> Signed-off-by: Joel Stanley 
> >> ---
> >>   configs/evb-ast2600_defconfig | 3 ---
> >>   1 file changed, 3 deletions(-)
> >>
> >> diff --git a/configs/evb-ast2600_defconfig 
> >> b/configs/evb-ast2600_defconfig index f3a6cb222020..160bccff48e2 
> >> 100644
> >> --- a/configs/evb-ast2600_defconfig
> >> +++ b/configs/evb-ast2600_defconfig
> >> @@ -59,9 +59,6 @@ CONFIG_REGMAP=y
> >>   CONFIG_SPL_OF_TRANSLATE=y
> >>   CONFIG_CLK=y
> >>   CONFIG_SPL_CLK=y
> >> -CONFIG_DM_HASH=y
> >> -CONFIG_HASH_ASPEED=y
> >> -CONFIG_ASPEED_ACRY=y
> >
> > Per our previous discussion, SPL code size still exists if all of AST2600 
> > features are upstream-ed.
> > Therefore, HW-assisted crypto drivers are needed.
> >
> > In addition, the current drivers works fine on real EVB to verify Hash + 
> > RSA signature (including the SHA256 in question).
> > This issue described in commit message should be attributed to incomplete 
> > QEMU emulation.
>
> When activating some debug in the hace driver :
>
>U-Boot SPL 2022.07-rc5-dirty (Jun 27 2022 - 09:01:28 +0200)
>already initialized, aspeed_2600_sdmc_write: SDMC is locked! (write to 
> MCR04 blocked)
>Trying to boot from RAM
>## Checking hash(es) for config conf-1 ... OK
>## Checking hash(es) for Image firmware-1 ... crc32Unsupported hash 
> algorithm 'crc32'
> error!
>Unsupported hash algorithm for 'hash-1' hash node in 'firmware-1' 
> image node
>
> It seems the problem comes from the unsupported 'crc32' algo.
> See aspeed_hace_init().

Well spotted. It needs a fallback implementation of the algorithms the hash API 
supports but the hardware driver does not implement.

So we have three downsides of using the HACE driver:

 - Cannot DMA from SPI NOR, requiring a copy to RAM
 - Missing MD5 and CRC32 implementations, breaking the hash API
 - Broken Qemu emulation, meaning we cannot use it in OpenBMC as all commits 
will fail CI

Obviously we can fix or find workarounds for these issues. However I suggest 
while they are worked on we leave the HACE disabled in the defconfig, so we can 
have build coverage in u-boot CI.

Once Aspeed completes the upstreaming of its u-boot port and therefore hits the 
64KB space limit, then we can look at re-enabling HACE in the defconfig. 
Hopefully by then you will have resolved the issues with the Qemu model.

Cheers,

Joel



>
> Thanks,
>
> C.
>
>
> >
> > Therefore, fixing QEMU should be the right way to go instead of disabling 
> > these options for real HW.
> >
> > Chiawei
> >
> >>   CONFIG_ASPEED_GPIO=y
> >>   CONFIG_DM_I2C=y
> >>   CONFIG_MISC=y
> >> --
> >> 2.35.1
> >
>


Issue with booting U-Boot from SD card, but using QSPI Flash for its Environment

2022-06-27 Thread David Antliff
Hi,

I'm having some difficulty configuring U-Boot, in particular setting it up so 
that it can load from an SD card, 
but access its Environment from QSPI Flash.

First of all, is this even possible? Can the U-Boot environment be stored in a 
different location from where
U-Boot was loaded?

Currently, I have a U-Boot image running from QSPI Flash on a Xilinx MPSoC 
ARM64 platform. I'm using Xilinx
PetaLinux however I think I understand how this configures U-Boot "under the 
hood" so I'll try to refer to
uboot.cfg​ as much as I can.

Along with all the defaults, I have set:

#define CONFIG_ENV_OFFSET 0x2E0
#define CONFIG_ENV_OVERWRITE 1
#define CONFIG_CMD_ERASEENV 1

On this particular platform, there is a physical switch to switch the Xilinx 
first-stage bootloader (and ARM
Trusted Firmware) between QSPI Flash to SD card. This platform also requires a 
so-called "BOOT.BIN", which
contains the u-boot binary and other things (like the Xilinx FSBL, ARM Trusted 
Firmware, an FPGA image and
other things), to be written to QSPI Flash, which I have done. This is all 
working correctly, and the serial console
looks like this:

Xilinx Zynq MP First Stage Boot Loader
Release 2021.2   Oct 13 2021  -  07:15:53
NOTICE:  BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE:  BL31: Built : 07:41:24, Oct 13 2021


U-Boot 2021.01 (Oct 12 2021 - 09:28:42 +)

CPU:   ZynqMP
Silicon: v3
Model: ZynqMP ZCU208 RevA
Board: Xilinx ZynqMP
DRAM:  4 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu48dr
NAND:  0 MiB
MMC:   mmc@ff17: 0
Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 512 
Bytes, erase size 128 KiB, total 512 MiB
...

As you can see, U-Boot loads from QSPI Flash and the Environment is also loaded 
from QSPI Flash. All good.

What I want to do is modify the system so that the earlier bootloader "BL31" 
loads U-Boot from the SD card. In my config I
already have CONFIG_ENV_IS_IN_FAT set to 1. When I copy BOOT.BIN to the first, 
FAT partition on an SD card, and set my
platform's boot mode to "SD Card" via the physical switch, the unit loads 
U-Boot from the SD card successfully, and the
serial console shows the above but with:

Loading Environment from FAT... *** Warning - bad CRC, using default environment

It works, although this warning is expected because there is no Environment 
saved on the SD card yet.
It does show that the SD card is being checked for the Environment though, so 
that's good.

Note that this is the same build that I used for the QSPI flash boot earlier, 
so I'm currently under the impression that
U-Boot only looks for its Environment based on where it was loaded from, even 
if other locations are enabled.

The issue is that I would like to configure U-Boot to be loaded from the SD 
card, but to use QSPI for its Environment,
so that we can store persistent U-Boot configuration on the board itself. 
Experimentally, it appears that U-Boot uses the
medium it was loaded from as the place to look for its Environment, although I 
haven't been able to confirm this.

According to the U-Boot documentation I've read, disabling FAT as the default 
should be achievable by unsetting the
following in u-boot.cfg:

CONFIG_ENV_IS_IN_FAT
CONFIG_SYS_MMC_ENV_DEV
CONFIG_ENV_FAT_DEVICE_AND_PART
CONFIG_ENV_IS_IN_FAT
CONFIG_ENV_FAT_FILE
CONFIG_SYS_MMC_ENV_PART
CONFIG_ENV_FAT_INTERFACE

Performing the same installation steps as above, to have this new U-Boot loaded 
from the SD card, results in the
following output:

Xilinx Zynq MP First Stage Boot Loader 
Release 2021.2   Oct 13 2021  -  07:15:53
NOTICE:  BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE:  BL31: Built : 07:41:24, Oct 13 2021

And that's it! No more output. There is an LED on the board that goes from red 
to green, which I think indicates that 
the FPGA image within BOOT.BIN has been loaded into the gate array 
successfully, so I think the earlier boot loader
has found BOOT.BIN. I have no reason therefore to think that U-Boot has not 
also been loaded, but if it has, it is 
generating no output. I tried increasing the debug level of U-Boot to 7 (DEBUG) 
in the hope of seeing something
from U-Boot, but that makes no difference. It's also not booting Linux, which 
would normally happen next.

Can anyone shed any light on why making this change might result in this 
behaviour? Is there some other 
configuration option I need to set to ensure that U-Boot can run from the SD 
card when CONFIG_ENV_IS_IN_FAT
and friends are not set? Or perhaps I can keep CONFIG_ENV_IS_IN_FAT etc. and 
there's some other way to instruct
U-Boot to use the QSPI Flash for its environment, even though it was loaded 
from SD card?

-- 
David.


RE: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Neal Liu
> Reviewed-by: Chia-Wei Wang 
> 
> The QEMU emulation issue is under investigation by Steven.
> The CRC32 and MD5 SW support will be added before we re-enabling HW
> crypto drivers.
> 
> Chiawei
> 
> > From: joel.s...@gmail.com  On Behalf Of Joel
> > Stanley
> > Sent: Monday, June 27, 2022 3:58 PM
> >
> > The HACE driver lacks support for all the hash types, causing boot to
> > fail with the default FIT configuration which uses CRC32.
> >
> > Additionally the Qemu model or the u-boot driver is unable to
> > correctly compute the SHA256 hash used in a FIT.
> >
> > Disable HACE by default while the above issues are worked out to
> > enable boot testing in Qemu.

I don't think this is the right way to do it.

First, it's fine that drivers can only support some algos. There is no rules 
that it must support CRC32.
Second, if Qemu test is failure, it should fix the Qemu HACE driver or disable 
it in Qemu, not in common defconfig in u-boot.
This will affect lots of people who use mainline for developments and 
productions.
Thanks,

-Neal

> >
> > Signed-off-by: Joel Stanley 
> > ---
> >  configs/evb-ast2600_defconfig | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/configs/evb-ast2600_defconfig
> > b/configs/evb-ast2600_defconfig index f3a6cb222020..160bccff48e2
> > 100644
> > --- a/configs/evb-ast2600_defconfig
> > +++ b/configs/evb-ast2600_defconfig
> > @@ -59,9 +59,6 @@ CONFIG_REGMAP=y
> >  CONFIG_SPL_OF_TRANSLATE=y
> >  CONFIG_CLK=y
> >  CONFIG_SPL_CLK=y
> > -CONFIG_DM_HASH=y
> > -CONFIG_HASH_ASPEED=y
> > -CONFIG_ASPEED_ACRY=y
> >  CONFIG_ASPEED_GPIO=y
> >  CONFIG_DM_I2C=y
> >  CONFIG_MISC=y
> > --
> > 2.35.1



Re: [PATCH V7 0/4] arm64: binman: use binman symbols for imx

2022-06-27 Thread Frieder Schrempf
Hi Peng,

Am 27.06.22 um 05:41 schrieb Peng Fan (OSS):
> From: Peng Fan 
> 
> V7:
>  Rebased with follwoing patchset applied.
>  [1] i.MX93 patchset: 
> https://patchwork.ozlabs.org/project/uboot/cover/20220627032455.28280-1-peng@oss.nxp.com/
>  [2] binman symbols fix: 
> https://patchwork.ozlabs.org/project/uboot/cover/20220618121316.12061-1-alpernebiya...@gmail.com/
>  

I tested this on next with the two patchsets mentioned above applied on
a kontron-sl-mx8mm board. I get around 38 KiB of SPL size reduction,
which is great!

Tested-by: Frieder Schrempf 

Thanks!
Frieder

> 
> V6:
>  Drop no-u-boot-any introduced in V5
>  Drop binman symbol replacement with @ to _, which is not needed
>  Update imx8m config to not select RAM IMAGE and RAM DEVICE
>  Update ddr firmware node name
>  Introduce autoconf.h for binman test
> 
> V5:
>  Introduce no-u-boot-any property to drop the X86 guard patch 1
>  Add blob-ext type for ddr firmware node
>  Include a missing dts change
> 
> V4:
>  Fix three boards build failure
> 
> V3:
>  Add R-b/T-b
>  Fix build warning
> 
> V2:
>  resolve some CI failure
>  include patch 7
> 
> binman symbol is a good feature, but only used on X86 for now. This patchset
> is to use it for i.MX8M platform.
> 
> The current imx8m ddr phy firmware consumes lots of space, because we pad
> them to the largest 32KB and 16KB for IMEM and DMEM.
> 
> With this patchset we use binman symbols to get firmware location and size,
> we could save near 36KB with i.MX8MP-EVK.
> 
> Please help check and test
> 
> 
> 
> Peng Fan (4):
>   arm: dts: imx8m: update binman ddr firmware node name
>   ddr: imx8m: helper: load ddr firmware according to binman symbols
>   arm: dts: imx8m: shrink ddr firmware size to actual file size
>   imx: imx8mm-icore: migrate to use BINMAN
> 
>  arch/arm/dts/imx8mm-u-boot.dtsi   | 16 +++
>  arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi| 20 
>  .../dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi  |  8 ++--
>  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi  | 20 
>  arch/arm/dts/imx8mn-evk-u-boot.dtsi   | 20 
>  .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 16 +++
>  arch/arm/dts/imx8mn-venice-u-boot.dtsi| 16 +++
>  arch/arm/dts/imx8mp-u-boot.dtsi   | 20 
>  arch/arm/dts/imx8mq-cm-u-boot.dtsi| 20 
>  arch/arm/dts/imx8mq-u-boot.dtsi   | 16 +++
>  arch/arm/mach-imx/imx8m/Kconfig   |  1 +
>  .../mach-imx/imx8m/imximage-8mm-lpddr4.cfg| 10 +---
>  configs/imx8mm-icore-mx8mm-ctouch2_defconfig  |  2 +-
>  configs/imx8mm-icore-mx8mm-edimm2.2_defconfig |  2 +-
>  drivers/ddr/imx/phy/helper.c  | 47 ---
>  15 files changed, 141 insertions(+), 93 deletions(-)
> 


Re: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Cédric Le Goater

Hello Neal

On 6/27/22 10:55, Neal Liu wrote:

Reviewed-by: Chia-Wei Wang 

The QEMU emulation issue is under investigation by Steven.
The CRC32 and MD5 SW support will be added before we re-enabling HW
crypto drivers.

Chiawei


From: joel.s...@gmail.com  On Behalf Of Joel
Stanley
Sent: Monday, June 27, 2022 3:58 PM

The HACE driver lacks support for all the hash types, causing boot to
fail with the default FIT configuration which uses CRC32.

Additionally the Qemu model or the u-boot driver is unable to
correctly compute the SHA256 hash used in a FIT.

Disable HACE by default while the above issues are worked out to
enable boot testing in Qemu.


I don't think this is the right way to do it.

First, it's fine that drivers can only support some algos. There is no rules 
that it must support CRC32.



For CRC32, I understand that the driver should be able to fallback to
the SW implementation.  It is not the case today. With some debug in
aspeed_hace_finish() :

  U-Boot SPL 2022.07-rc5-dirty (Jun 27 2022 - 09:01:28 +0200)
  already initialized, Trying to boot from RAM
  ## Checking hash(es) for config conf-1 ... OK
  ## Checking hash(es) for Image firmware-1 ... crc32Unsupported hash algorithm 
'crc32' error!
  Unsupported hash algorithm for 'hash-1' hash node in 'firmware-1' image node

The above is not related to QEMU.

Thanks,

C.




Second, if Qemu test is failure, it should fix the Qemu HACE driver or disable 
it in Qemu, not in common defconfig in u-boot.
This will affect lots of people who use mainline for developments and 
productions.
Thanks,

-Neal



Signed-off-by: Joel Stanley 
---
  configs/evb-ast2600_defconfig | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/configs/evb-ast2600_defconfig
b/configs/evb-ast2600_defconfig index f3a6cb222020..160bccff48e2
100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -59,9 +59,6 @@ CONFIG_REGMAP=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_CLK=y
  CONFIG_SPL_CLK=y
-CONFIG_DM_HASH=y
-CONFIG_HASH_ASPEED=y
-CONFIG_ASPEED_ACRY=y
  CONFIG_ASPEED_GPIO=y
  CONFIG_DM_I2C=y
  CONFIG_MISC=y
--
2.35.1






RE: [PATCH V7 0/4] arm64: binman: use binman symbols for imx

2022-06-27 Thread Peng Fan
> Subject: Re: [PATCH V7 0/4] arm64: binman: use binman symbols for imx
> 
> Hi Peng,
> 
> Am 27.06.22 um 05:41 schrieb Peng Fan (OSS):
> > From: Peng Fan 
> >
> > V7:
> >  Rebased with follwoing patchset applied.
> >  [1] i.MX93 patchset:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Fuboot%2Fcover%2F20220627032455.28280-
> 1-pe
> >
> ng.fan%40oss.nxp.com%2F&data=05%7C01%7Cpeng.fan%40nxp.com%7
> C4d84e7
> >
> f4d2a64aa0c42608da581ba444%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%
> >
> 7C637919173000954346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQI
> >
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> data=95
> >
> jEtkvfpG3HVgqTpeodf%2BQXjw5DBnYVpZ7%2BCBaKfp0%3D&reserved=
> 0
> >  [2] binman symbols fix:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Fuboot%2Fcover%2F20220618121316.12061-
> 1-al
> >
> pernebiyasak%40gmail.com%2F&data=05%7C01%7Cpeng.fan%40nxp.co
> m%7C4d
> >
> 84e7f4d2a64aa0c42608da581ba444%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%
> >
> 7C0%7C637919173000954346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiL
> >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&a
> mp;sdat
> > a=jdsYVWoijLk0cGEA2xyVtF6AKNj7ajNxSILFLXkypZE%3D&reserved=0
> 
> I tested this on next with the two patchsets mentioned above applied on a
> kontron-sl-mx8mm board. I get around 38 KiB of SPL size reduction, which is
> great!
> 
> Tested-by: Frieder Schrempf 

Thanks for testing this patchset.

Thanks,
Peng.

> 
> Thanks!
> Frieder
> 
> >
> > V6:
> >  Drop no-u-boot-any introduced in V5
> >  Drop binman symbol replacement with @ to _, which is not needed
> > Update imx8m config to not select RAM IMAGE and RAM DEVICE  Update
> ddr
> > firmware node name  Introduce autoconf.h for binman test
> >
> > V5:
> >  Introduce no-u-boot-any property to drop the X86 guard patch 1  Add
> > blob-ext type for ddr firmware node  Include a missing dts change
> >
> > V4:
> >  Fix three boards build failure
> >
> > V3:
> >  Add R-b/T-b
> >  Fix build warning
> >
> > V2:
> >  resolve some CI failure
> >  include patch 7
> >
> > binman symbol is a good feature, but only used on X86 for now. This
> > patchset is to use it for i.MX8M platform.
> >
> > The current imx8m ddr phy firmware consumes lots of space, because we
> > pad them to the largest 32KB and 16KB for IMEM and DMEM.
> >
> > With this patchset we use binman symbols to get firmware location and
> > size, we could save near 36KB with i.MX8MP-EVK.
> >
> > Please help check and test
> >
> >
> >
> > Peng Fan (4):
> >   arm: dts: imx8m: update binman ddr firmware node name
> >   ddr: imx8m: helper: load ddr firmware according to binman symbols
> >   arm: dts: imx8m: shrink ddr firmware size to actual file size
> >   imx: imx8mm-icore: migrate to use BINMAN
> >
> >  arch/arm/dts/imx8mm-u-boot.dtsi   | 16 +++
> >  arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi| 20 
> >  .../dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi  |  8 ++--
> >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi  | 20 
> >  arch/arm/dts/imx8mn-evk-u-boot.dtsi   | 20 
> >  .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 16 +++
> >  arch/arm/dts/imx8mn-venice-u-boot.dtsi| 16 +++
> >  arch/arm/dts/imx8mp-u-boot.dtsi   | 20 
> >  arch/arm/dts/imx8mq-cm-u-boot.dtsi| 20 
> >  arch/arm/dts/imx8mq-u-boot.dtsi   | 16 +++
> >  arch/arm/mach-imx/imx8m/Kconfig   |  1 +
> >  .../mach-imx/imx8m/imximage-8mm-lpddr4.cfg| 10 +---
> >  configs/imx8mm-icore-mx8mm-ctouch2_defconfig  |  2 +-
> > configs/imx8mm-icore-mx8mm-edimm2.2_defconfig |  2 +-
> >  drivers/ddr/imx/phy/helper.c  | 47
> ---
> >  15 files changed, 141 insertions(+), 93 deletions(-)
> >


Re: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Joel Stanley
On Mon, 27 Jun 2022 at 08:55, Neal Liu  wrote:
>
> > Reviewed-by: Chia-Wei Wang 
> >
> > The QEMU emulation issue is under investigation by Steven.
> > The CRC32 and MD5 SW support will be added before we re-enabling HW
> > crypto drivers.
> >
> > Chiawei
> >
> > > From: joel.s...@gmail.com  On Behalf Of Joel
> > > Stanley
> > > Sent: Monday, June 27, 2022 3:58 PM
> > >
> > > The HACE driver lacks support for all the hash types, causing boot to
> > > fail with the default FIT configuration which uses CRC32.
> > >
> > > Additionally the Qemu model or the u-boot driver is unable to
> > > correctly compute the SHA256 hash used in a FIT.
> > >
> > > Disable HACE by default while the above issues are worked out to
> > > enable boot testing in Qemu.
>
> I don't think this is the right way to do it.
>
> First, it's fine that drivers can only support some algos. There is no rules 
> that it must support CRC32.
> Second, if Qemu test is failure, it should fix the Qemu HACE driver or 
> disable it in Qemu, not in common defconfig in u-boot.
> This will affect lots of people who use mainline for developments and 
> productions.

While I agree with you in general, this board didn't boot until
recently, and it certainly doesn't have any users. Mainline u-boot
lacks drivers for the ast2600 hardware it claims to support. There's
no working storage driver in the tree (SPI NOR or eMMC).

While qemu support is not required for u-boot's CI, it is a hard
dependency of it being used in the OpenBMC project, which is where the
majority of users come from. In that project we use a fork of the
Aspeed SDK, which itself is a few thousand patches on top of u-boot
v2019.04.

I propose this change as a way to get CI working for the board, so we
can have a baseline set of working functionality, and make
improvements from there. I've started submitting those improvements;
we have changes on the list for eMMC support, I2C, and the Aspeed
developers have a spi-nor driver under review.

Cheers,

Joel

> Thanks,
>
> -Neal
>
> > >
> > > Signed-off-by: Joel Stanley 
> > > ---
> > >  configs/evb-ast2600_defconfig | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git a/configs/evb-ast2600_defconfig
> > > b/configs/evb-ast2600_defconfig index f3a6cb222020..160bccff48e2
> > > 100644
> > > --- a/configs/evb-ast2600_defconfig
> > > +++ b/configs/evb-ast2600_defconfig
> > > @@ -59,9 +59,6 @@ CONFIG_REGMAP=y
> > >  CONFIG_SPL_OF_TRANSLATE=y
> > >  CONFIG_CLK=y
> > >  CONFIG_SPL_CLK=y
> > > -CONFIG_DM_HASH=y
> > > -CONFIG_HASH_ASPEED=y
> > > -CONFIG_ASPEED_ACRY=y
> > >  CONFIG_ASPEED_GPIO=y
> > >  CONFIG_DM_I2C=y
> > >  CONFIG_MISC=y
> > > --
> > > 2.35.1
>


Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-27 Thread Marek Vasut

On 6/27/22 07:30, Jim Liu wrote:

Hi Marek


Hello all,


Thanks for your reply.
The answer is yes.
Our customer Dell is using our driver now.
so need upstream uboot source to uboot master.


All right, so this Dell device is also going to be upstreamed then ?

If the driver is just going to be upstream and never enabled, it would 
bitrot and be useless -- that's my concern.


RE: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Neal Liu
> Hello Neal
> 
> On 6/27/22 10:55, Neal Liu wrote:
> >> Reviewed-by: Chia-Wei Wang 
> >>
> >> The QEMU emulation issue is under investigation by Steven.
> >> The CRC32 and MD5 SW support will be added before we re-enabling HW
> >> crypto drivers.
> >>
> >> Chiawei
> >>
> >>> From: joel.s...@gmail.com  On Behalf Of Joel
> >>> Stanley
> >>> Sent: Monday, June 27, 2022 3:58 PM
> >>>
> >>> The HACE driver lacks support for all the hash types, causing boot
> >>> to fail with the default FIT configuration which uses CRC32.
> >>>
> >>> Additionally the Qemu model or the u-boot driver is unable to
> >>> correctly compute the SHA256 hash used in a FIT.
> >>>
> >>> Disable HACE by default while the above issues are worked out to
> >>> enable boot testing in Qemu.
> >
> > I don't think this is the right way to do it.
> >
> > First, it's fine that drivers can only support some algos. There is no 
> > rules that
> it must support CRC32.
> 
> 
> For CRC32, I understand that the driver should be able to fallback to the SW
> implementation.  It is not the case today. With some debug in
> aspeed_hace_finish() :
> 
>U-Boot SPL 2022.07-rc5-dirty (Jun 27 2022 - 09:01:28 +0200)
>already initialized, Trying to boot from RAM
>## Checking hash(es) for config conf-1 ... OK
>## Checking hash(es) for Image firmware-1 ... crc32Unsupported hash
> algorithm 'crc32' error!
>Unsupported hash algorithm for 'hash-1' hash node in 'firmware-1' image
> node
> 
> The above is not related to QEMU.
> 
> Thanks,
> 
> C.

The fallback need to be fixed of course. We would send a patch to fix this.
Thanks

> 
> 
> 
> > Second, if Qemu test is failure, it should fix the Qemu HACE driver or 
> > disable
> it in Qemu, not in common defconfig in u-boot.
> > This will affect lots of people who use mainline for developments and
> productions.
> > Thanks,
> >
> > -Neal
> >



[GIT PULL] xilinx patches for v2022.10

2022-06-27 Thread Michal Simek

Hi Tom,

please pull the following patches to your next branch.
There are a lot of changes especially with Microblaze and having an option to 
disable MANUAL RELOC.


Gitlab CI doesn't show any issue.

And there is merge conflict with your next branch (Kconfig layout change) which 
is easy to resolve.

Simply remove all reported lines from include/configs/microblaze-generic.h and
include/configs/xilinx_zynqmp.h

Thanks,
Michal


The following changes since commit c18e5fb055ab789f58434e3cb432582adee0134c:

  dtoc: Update test_src_scan.py for new tegra compatibles (2022-06-14 13:59:23 
-0400)


are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git 
tags/xilinx-for-v2022.10


for you to fetch changes up to 728a86edb63a647e6faf211c0dbc7bd0e4ff7ac6:

  timer: Add SPL_REGMAP dependency for Xilinx timer (2022-06-27 09:03:54 +0200)


Xilinx changes for v2022.10

cpu:
- Add driver for microblaze cpu

net:
- Add support for DM_ETH_PHY to AXI emac and emaclite

xilinx:
- Switch platforms to DM_ETH_PHY
- DT chagnes in ZynqMP and Zynq
- Enable support for SquashFS

zynqmp:
- Add support for KR260 boards
- Move BSS from address 0
- Move platform identification from board code to soc driver
- Improve zynqmp_psu_init_minimize

versal:
- Enable loading app at EL1

serial:
- Setup default address and clock rates for DEBUG uarts

pinctrl:
- Add support for tri state and output enable properties

relocate-rela:
- Clean relocate-rela implementation for ARM64
- Add support for Microblaze

microblaze:
- Add support for runtime relocation
- Rework cache handling (wiring, Kconfig) based on cpuinfo
- Remove interrupt support

timer:
- Extract axi timer driver from Microblaze to generic location


Amit Kumar Mahapatra (1):
  ARM: zynq: Fix size-cells for pl353 driver

Ashok Reddy Soma (3):
  arm64: versal: Add support to load an app at EL1
  pinctrl: zynqmp: Add support for output-enable and bias-high-impedance
  arm64: zynqmp: Fix usb node drive strength and slew rate

Michal Simek (34):
  arm64: zynqmp: Add debug messages to bl2_plat_get_bl31_params()
  serial: Setup serial base and freq for zynq/zynqmp
  arm64: zynqmp: Add support for kr260 revA/B boards
  arm64: zynqmp: Enable DP for kv260-revA board
  arm64: zynqmp: Fix i2c addresses for vck190 SC
  arm64: zynqmp: Update tps53681 i2c address
  arm64: zynqmp: Fix tps544/u3007 node description
  tools: relocate-rela: Open binary u-boot file later
  Makefile: Fix description for relocate-rela parameters
  tools: relocate-rela: Use global variables
  tools: relocate-rela: Read rela start/end directly from ELF
  microblaze: Switch absolute branches to relative
  microblaze: Fix stack protection behavior
  microblaze: Fix early stack allocation
  microblaze: Remove CONFIG_TEXT_BASE from code
  microblaze: Fix typo in exception.c
  mips: Move endianness selection to arch/Kconfig
  microblaze: Enable REMAKE_ELF
  microblaze: Separate code end substraction
  microblaze: Change stack protection address to new stack address
  microblaze: Optimize register usage in relocate_code
  microblaze: Remove code around r20 in relocate_code()
  microblaze: Remove _start symbol handling at U-Boot start
  microblaze: Add comment about reset location
  microblaze: Create SYM_ADDR macro to deal with symbols
  tools: relocate-rela: Extract elf64 reloc to special function
  tools: relocate-rela: Check that relocation works only for EM_AARCH64
  tools: relocate-rela: Add support for elf32 decoding
  tools: relocate-rela: Add support for 32bit Microblaze relocation
  microblaze: Add support for run time relocation
  microblaze: Convert axi timer to DM driver
  microblaze: Remove interrupt handler
  xilinx: Enable support for SquashFS
  timer: Add SPL_REGMAP dependency for Xilinx timer

Ovidiu Panait (14):
  cmd: cpu: migrate cpu command to U_BOOT_CMD_WITH_SUBCMDS()
  cpu-uclass: relocate ops pointers for CONFIG_NEEDS_MANUAL_RELOC
  microblaze: start.S: remove unused code
  microblaze: cache: replace XILINX_USE_DCACHE -> CONFIG_DCACHE
  microblaze: cache: improve dcache Kconfig options
  microblaze: cache: improve icache Kconfig options
  microblaze: cache: split flush_cache() function
  microblaze: cache: introduce Kconfig options for icache/dcache sizes
  microblaze: cache: introduce flush_cache_all()
  microblaze: cache: introduce cpuinfo structure
  microblaze: cache: introduce flush_dcache_range()
  microblaze: Kconfig: introduce XILINX_MICROBLAZE0_FPGA_FAMILY option
  microblaze: add support for handling PVR data
  cpu: add CPU driver for microblaze

Stefan Herbrechtsmeier (16):
  xilinx: zynqmp: Do not use 0 as spl bs

Re: Issue with booting U-Boot from SD card, but using QSPI Flash for its Environment

2022-06-27 Thread Michal Simek

Hi,

On 6/27/22 05:01, David Antliff wrote:

Hi,

I'm having some difficulty configuring U-Boot, in particular setting it up so 
that it can load from an SD card,
but access its Environment from QSPI Flash.

First of all, is this even possible? Can the U-Boot environment be stored in a 
different location from where
U-Boot was loaded?

Currently, I have a U-Boot image running from QSPI Flash on a Xilinx MPSoC 
ARM64 platform. I'm using Xilinx
PetaLinux however I think I understand how this configures U-Boot "under the 
hood" so I'll try to refer to
uboot.cfg​ as much as I can.

Along with all the defaults, I have set:

#define CONFIG_ENV_OFFSET 0x2E0
#define CONFIG_ENV_OVERWRITE 1
#define CONFIG_CMD_ERASEENV 1

On this particular platform, there is a physical switch to switch the Xilinx 
first-stage bootloader (and ARM
Trusted Firmware) between QSPI Flash to SD card. This platform also requires a so-called 
"BOOT.BIN", which
contains the u-boot binary and other things (like the Xilinx FSBL, ARM Trusted 
Firmware, an FPGA image and
other things), to be written to QSPI Flash, which I have done. This is all 
working correctly, and the serial console
looks like this:

Xilinx Zynq MP First Stage Boot Loader
Release 2021.2   Oct 13 2021  -  07:15:53
NOTICE:  BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE:  BL31: Built : 07:41:24, Oct 13 2021


U-Boot 2021.01 (Oct 12 2021 - 09:28:42 +)

CPU:   ZynqMP
Silicon: v3
Model: ZynqMP ZCU208 RevA
Board: Xilinx ZynqMP
DRAM:  4 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu48dr
NAND:  0 MiB
MMC:   mmc@ff17: 0
Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 512 
Bytes, erase size 128 KiB, total 512 MiB
...

As you can see, U-Boot loads from QSPI Flash and the Environment is also loaded 
from QSPI Flash. All good.

What I want to do is modify the system so that the earlier bootloader "BL31" 
loads U-Boot from the SD card. In my config I
already have CONFIG_ENV_IS_IN_FAT set to 1. When I copy BOOT.BIN to the first, 
FAT partition on an SD card, and set my
platform's boot mode to "SD Card" via the physical switch, the unit loads 
U-Boot from the SD card successfully, and the
serial console shows the above but with:

Loading Environment from FAT... *** Warning - bad CRC, using default environment

It works, although this warning is expected because there is no Environment 
saved on the SD card yet.
It does show that the SD card is being checked for the Environment though, so 
that's good.

Note that this is the same build that I used for the QSPI flash boot earlier, 
so I'm currently under the impression that
U-Boot only looks for its Environment based on where it was loaded from, even 
if other locations are enabled.

The issue is that I would like to configure U-Boot to be loaded from the SD 
card, but to use QSPI for its Environment,
so that we can store persistent U-Boot configuration on the board itself. 
Experimentally, it appears that U-Boot uses the
medium it was loaded from as the place to look for its Environment, although I 
haven't been able to confirm this.

According to the U-Boot documentation I've read, disabling FAT as the default 
should be achievable by unsetting the
following in u-boot.cfg:

CONFIG_ENV_IS_IN_FAT
CONFIG_SYS_MMC_ENV_DEV
CONFIG_ENV_FAT_DEVICE_AND_PART
CONFIG_ENV_IS_IN_FAT
CONFIG_ENV_FAT_FILE
CONFIG_SYS_MMC_ENV_PART
CONFIG_ENV_FAT_INTERFACE

Performing the same installation steps as above, to have this new U-Boot loaded 
from the SD card, results in the
following output:

Xilinx Zynq MP First Stage Boot Loader
Release 2021.2   Oct 13 2021  -  07:15:53
NOTICE:  BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE:  BL31: Built : 07:41:24, Oct 13 2021

And that's it! No more output. There is an LED on the board that goes from red 
to green, which I think indicates that
the FPGA image within BOOT.BIN has been loaded into the gate array 
successfully, so I think the earlier boot loader
has found BOOT.BIN. I have no reason therefore to think that U-Boot has not 
also been loaded, but if it has, it is
generating no output. I tried increasing the debug level of U-Boot to 7 (DEBUG) 
in the hope of seeing something
from U-Boot, but that makes no difference. It's also not booting Linux, which 
would normally happen next.

Can anyone shed any light on why making this change might result in this 
behaviour? Is there some other
configuration option I need to set to ensure that U-Boot can run from the SD 
card when CONFIG_ENV_IS_IN_FAT
and friends are not set? Or perhaps I can keep CONFIG_ENV_IS_IN_FAT etc. and 
there's some other way to instruct
U-Boot to use the QSPI Flash for its environment, even though it was loaded 
from SD card?



There are couple of things here. You are saying you want to U-Boot to be loaded 
from SD card. But FSBL you are using don't support this mode. It only supports 
that boot.bin has all binaries you want FSBL to load.


The second part

Re: [PATCH] usb: kbd: allow probing even if usbkbd not in stdin

2022-06-27 Thread Köry Maincent
Hello Marek,

On Fri, 24 Jun 2022 20:12:31 +0200
Marek Vasut  wrote:

> On 6/22/22 10:59, kory.mainc...@bootlin.com wrote:
> > From: Kory Maincent 
> > 
> > For now the driver does not probe if usbkbd was not present in stdin.
> > This presents two issues, we can not probe the driver before setting stdin  
> 
> Environment should be up and running before USB, so this is likely not a 
> problem.

Having a driver probing only in this specific state is weird?
It should probe whatever the state of stdin.

> 
> > and we can not use this driver in other manner than stdin console.
> > 
> > This patch fixes this by adding an else statement. It simply probes the
> > driver without console management in the case "usbkbd" is not in stdin.  
> 
> Can you document the usecase in a bit more detail ?

My usecase is to get a key press from the USB keyboard and do some thing about
it in board_init. I do not want to multiplex the keyboard input to stdin but I
still want to read character from it.

> What exactly is the problem you are solving here ?
> > stdinname = env_get("stdin");
> >   #if CONFIG_IS_ENABLED(CONSOLE_MUX)
> > -   error = iomux_doenv(stdin, stdinname);
> > -   if (error)
> > -   return error;
> > +   if (strstr(stdinname, DEVNAME) != NULL) {
> > +   error = iomux_doenv(stdin, stdinname);
> > +   if (error)
> > +   return error;
> > +   }
> >   #else
> > /* Check if this is the standard input device. */
> > -   if (strcmp(stdinname, DEVNAME))
> > -   return 1;
> > -
> > -   /* Reassign the console */
> > -   if (overwrite_console())
> > -   return 1;
> > +   if (!strcmp(stdinname, DEVNAME)) {  
> 
> Maybe use strcmp() == NULL to be consistent with the != NULL check above ?

Yes, you are right.

Regards,
Köry


Re: [PATCH 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Joel Stanley
On Mon, 27 Jun 2022 at 08:48, Steven Lee  wrote:
>
> Hi Joel,
>
> I was wondering if you could share the commit hash of u-boot you tested.
> I would like to test it on qemu.

I recommend using master with the patch that fixes FIT hash checking:

https://lore.kernel.org/r/20220620070117.3443066-1-j...@jms.id.au

I use a script to build the image (also attached to this email):

https://ozlabs.org/~joel/build-ast2600-spl.sh

Run that script from the u-boot source tree. It provides an example
qemu commandline when it finishes:

/usr/bin/qemu-system-arm -M ast2600-evb -nographic -drive
file=ast2600-obj/test.img,if=mtd,format=raw -nic user,tftp=/srv/tftp/
U-Boot SPL 2022.07-rc5-00010-g75967970850a (Jun 27 2022 - 19:00:15 +0930)
Trying to boot from RAM
## Checking hash(es) for config conf-1 ... OK
## Checking hash(es) for Image firmware-1 ... sha256 error!
Bad hash value for 'hash-1' hash node in 'firmware-1' image node

One thing to note is the conf-1 check succeeds, but the firmware-1
check fails. I suspect this is because the conf-1 check is less than
64 bytes, so it only requires one pass of the HACE. That's also why
the qemu unit test you wrote works; it only tests one pass, so doesn't
trigger the accumulation part of the model.

I was running with this patch to see the output of the hash operation:

Author: Joel Stanley 
Date:   Sat Jun 18 18:20:08 2022 +0930

fit: Print hash results on failure

Signed-off-by: Joel Stanley 

diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df8836a..63aa46e51270 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1302,7 +1302,18 @@ static int fit_image_check_hash(const void
*fit, int noffset, const void *data,
*err_msgp = "Bad hash value len";
return -1;
} else if (memcmp(value, fit_value, value_len) != 0) {
+   int i;
*err_msgp = "Bad hash value";
+   printf("\ncalculated: ");
+   for (i=0; ihttps://github.com/shenki/u-boot/

Cheers,

Joel


build-ast2600-spl.sh
Description: Bourne shell script


[PATCH v2] fs/squashfs: Use kcalloc when relevant

2022-06-27 Thread Miquel Raynal
A crafted squashfs image could embed a huge number of empty metadata
blocks in order to make the amount of malloc()'d memory overflow and be
much smaller than expected. Because of this flaw, any random code
positioned at the right location in the squashfs image could be memcpy'd
from the squashfs structures into U-Boot code location while trying to
access the rearmost blocks, before being executed.

In order to prevent this vulnerability from being exploited in eg. a
secure boot environment, let's add a check over the amount of data
that is going to be allocated. Such a check could look like:

if (!elem_size || n > SIZE_MAX / elem_size)
return NULL;

The right way to do it would be to enhance the calloc() implementation
but this is quite an impacting change for such a small fix. Another
solution would be to add the check before the malloc call in the
squashfs implementation, but this does not look right. So for now, let's
use the kcalloc() compatibility function from Linux, which has this
check.

Fixes: c5100613037 ("fs/squashfs: new filesystem")
Reported-by: Tatsuhiko Yasumatsu 
Signed-off-by: Miquel Raynal 
Tested-by: Tatsuhiko Yasumatsu 
---

Changes in v2:
* Fixed the title prefix: s/sqashfs/squashfs
* Rebased on master to avoid a conflit with a headers change
* Added a Fixes tag
* Added the Tested-by from Tatsuhiko sent privately

 fs/squashfs/sqfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 40361ffa6d6..9f98d086070 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -726,7 +727,8 @@ static int sqfs_read_inode_table(unsigned char 
**inode_table)
goto free_itb;
}
 
-   *inode_table = malloc(metablks_count * SQFS_METADATA_BLOCK_SIZE);
+   *inode_table = kcalloc(metablks_count, SQFS_METADATA_BLOCK_SIZE,
+  GFP_KERNEL);
if (!*inode_table) {
ret = -ENOMEM;
printf("Error: failed to allocate squashfs inode_table of size 
%i, increasing CONFIG_SYS_MALLOC_LEN could help\n",
-- 
2.34.1



[PATCH] efi: test/py: repair authenticated capsules tests

2022-06-27 Thread Vincent Stehlé
The UEFI console initialisation has been modified by commit 68edbed454b8
("efi_loader: initialize console size late"). A corresponding workaround is
now necessary for the automated tests, as added to some of the tests
already by commit e05bd68ed5fc ("test: work around for EFI terminal size
probing").

Add the same workaround to the UEFI authenticated capsules tests to repair
them.

This can be tested with sandbox_defconfig, sandbox64_defconfig or
sandbox_flattree_defconfig, plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.

Signed-off-by: Vincent Stehlé 
Cc: Heinrich Schuchardt 
---
 .../tests/test_efi_capsule/test_capsule_firmware_signed_fit.py | 3 +++
 .../tests/test_efi_capsule/test_capsule_firmware_signed_raw.py | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py 
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
index 4400b8f1368..d6ca9b16745 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
@@ -40,6 +40,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
 with u_boot_console.log.section('Test Case 1-a, before reboot'):
 output = u_boot_console.run_command_list([
 'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
 'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
 'efidebug boot order 1',
 'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -115,6 +116,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
 with u_boot_console.log.section('Test Case 2-a, before reboot'):
 output = u_boot_console.run_command_list([
 'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
 'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
 'efidebug boot order 1',
 'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -192,6 +194,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
 with u_boot_console.log.section('Test Case 3-a, before reboot'):
 output = u_boot_console.run_command_list([
 'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
 'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
 'efidebug boot order 1',
 'env set -e -nv -bs -rt OsIndications =0x0004',
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py 
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
index 1b5a1bb42eb..2bbaa9cc55f 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
@@ -112,6 +112,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
 with u_boot_console.log.section('Test Case 2-a, before reboot'):
 output = u_boot_console.run_command_list([
 'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
 'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
 'efidebug boot order 1',
 'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -189,6 +190,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
 with u_boot_console.log.section('Test Case 3-a, before reboot'):
 output = u_boot_console.run_command_list([
 'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
 'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
 'efidebug boot order 1',
 'env set -e -nv -bs -rt OsIndications =0x0004',
-- 
2.35.1



Re: [PATCH] efi: test/py: repair authenticated capsules tests

2022-06-27 Thread Heinrich Schuchardt

On 6/27/22 12:23, Vincent Stehlé wrote:

The UEFI console initialisation has been modified by commit 68edbed454b8
("efi_loader: initialize console size late"). A corresponding workaround is
now necessary for the automated tests, as added to some of the tests
already by commit e05bd68ed5fc ("test: work around for EFI terminal size
probing").

Add the same workaround to the UEFI authenticated capsules tests to repair
them.

This can be tested with sandbox_defconfig, sandbox64_defconfig or
sandbox_flattree_defconfig, plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.

Signed-off-by: Vincent Stehlé 


Why are these tests not run in Gitlab?
Can't we permanently adjust one of said defconfigs for this purpose?
Or do we need a new defconfig for testing?

Best regards

Heinrich


Cc: Heinrich Schuchardt 
---
  .../tests/test_efi_capsule/test_capsule_firmware_signed_fit.py | 3 +++
  .../tests/test_efi_capsule/test_capsule_firmware_signed_raw.py | 2 ++
  2 files changed, 5 insertions(+)

diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py 
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
index 4400b8f1368..d6ca9b16745 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
@@ -40,6 +40,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
  with u_boot_console.log.section('Test Case 1-a, before reboot'):
  output = u_boot_console.run_command_list([
  'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
  'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
  'efidebug boot order 1',
  'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -115,6 +116,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
  with u_boot_console.log.section('Test Case 2-a, before reboot'):
  output = u_boot_console.run_command_list([
  'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
  'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
  'efidebug boot order 1',
  'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -192,6 +194,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
  with u_boot_console.log.section('Test Case 3-a, before reboot'):
  output = u_boot_console.run_command_list([
  'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
  'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
  'efidebug boot order 1',
  'env set -e -nv -bs -rt OsIndications =0x0004',
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py 
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
index 1b5a1bb42eb..2bbaa9cc55f 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
@@ -112,6 +112,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
  with u_boot_console.log.section('Test Case 2-a, before reboot'):
  output = u_boot_console.run_command_list([
  'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
  'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
  'efidebug boot order 1',
  'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -189,6 +190,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
  with u_boot_console.log.section('Test Case 3-a, before reboot'):
  output = u_boot_console.run_command_list([
  'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal 
size determination
  'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
  'efidebug boot order 1',
  'env set -e -nv -bs -rt OsIndications =0x0004',




[PATCH v2 1/2] pmic: pca9450: Add optional SD_VSEL GPIO for LDO5

2022-06-27 Thread Frieder Schrempf
From: Frieder Schrempf 

LDO5 has two separate control registers. LDO5CTRL_L is used if the
input signal SD_VSEL is low and LDO5CTRL_H if it is high.
The current driver implementation only uses LDO5CTRL_H. To make this
work on boards that have SD_VSEL connected to a GPIO, we add support
for specifying an optional GPIO and setting it to high at probe time.

In the future we might also want to add support for boards that have
SD_VSEL set to a fixed low level. In this case we need to change the
driver to be able to use the LDO5CTRL_L register.

This is a port of the same change in the Linux kernel:
8c67a11bae88 ("regulator: pca9450: Add SD_VSEL GPIO for LDO5")

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v2:
  * Add Fabio's R-b (Thanks!)
  * Use CONFIG_IS_ENABLED() instead of IS_ENABLED(CONFIG_*) to properly
detect the options for SPL.
---
 drivers/power/pmic/pca9450.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index 116ac49a8db..a186edc08da 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -7,9 +7,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +29,10 @@ static const struct pmic_child_info pmic_children_info[] = {
{ },
 };
 
+struct pca9450_priv {
+   struct gpio_desc *sd_vsel_gpio;
+};
+
 static int pca9450_reg_count(struct udevice *dev)
 {
return PCA9450_REG_NUM;
@@ -76,6 +83,24 @@ static int pca9450_bind(struct udevice *dev)
return 0;
 }
 
+static int pca9450_probe(struct udevice *dev)
+{
+   struct pca9450_priv *priv = dev_get_priv(dev);
+   int ret = 0;
+
+   if (CONFIG_IS_ENABLED(DM_GPIO) && 
CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {
+   priv->sd_vsel_gpio = devm_gpiod_get_optional(dev, "sd-vsel",
+GPIOD_IS_OUT |
+
GPIOD_IS_OUT_ACTIVE);
+   if (IS_ERR(priv->sd_vsel_gpio)) {
+   ret = PTR_ERR(priv->sd_vsel_gpio);
+   dev_err(dev, "Failed to request SD_VSEL GPIO: %d\n", 
ret);
+   }
+   }
+
+   return ret;
+}
+
 static struct dm_pmic_ops pca9450_ops = {
.reg_count = pca9450_reg_count,
.read = pca9450_read,
@@ -94,5 +119,7 @@ U_BOOT_DRIVER(pmic_pca9450) = {
.id = UCLASS_PMIC,
.of_match = pca9450_ids,
.bind = pca9450_bind,
+   .probe = pca9450_probe,
.ops = &pca9450_ops,
+   .priv_auto = sizeof(struct pca9450_priv),
 };
-- 
2.36.1



[PATCH v2 2/2] imx: kontron-sl-mx8mm: Enable PCA9450 regulator driver and fix SD card access

2022-06-27 Thread Frieder Schrempf
From: Frieder Schrempf 

Currently accessing the SD card on USDHC2 fails with:

=> mmc dev 1
Card did not respond to voltage select! : -110

This is due to the fact that UHS modes are enabled in the defconfig
and the devicetree, but the referenced LDO5 regulator (reg_nvcc_sd)
is not available to switch the data lines from 3.3V to 1.8V mode.

By enabling the regulator driver the vqmmc-supply is now available
and the SD card works also in high speed modes:

=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device

Please note that the board has a GPIO connected to the SD_VSEL signal
of the PMIC. As the driver uses the LDO5CTRL_H register to set the
voltage, we need to make sure that this GPIO (GPIO01_IO4) is set to
a high level.

Signed-off-by: Frieder Schrempf 
Reviewed-by: Fabio Estevam 
---
Changes in v2:
  * Add Fabio's R-b (Thanks!)
---
 configs/kontron-sl-mx8mm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/kontron-sl-mx8mm_defconfig 
b/configs/kontron-sl-mx8mm_defconfig
index 2e9d52522b2..727f99f0063 100644
--- a/configs/kontron-sl-mx8mm_defconfig
+++ b/configs/kontron-sl-mx8mm_defconfig
@@ -99,6 +99,7 @@ CONFIG_DM_PMIC=y
 CONFIG_DM_PMIC_PCA9450=y
 CONFIG_SPL_DM_PMIC_PCA9450=y
 CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PCA9450=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_RV8803=y
 CONFIG_CONS_INDEX=2
-- 
2.36.1



Re: [PATCH] usb: kbd: allow probing even if usbkbd not in stdin

2022-06-27 Thread Marek Vasut

On 6/27/22 12:03, Köry Maincent wrote:

Hello Marek,

On Fri, 24 Jun 2022 20:12:31 +0200
Marek Vasut  wrote:


On 6/22/22 10:59, kory.mainc...@bootlin.com wrote:

From: Kory Maincent 

For now the driver does not probe if usbkbd was not present in stdin.
This presents two issues, we can not probe the driver before setting stdin


Environment should be up and running before USB, so this is likely not a
problem.


Having a driver probing only in this specific state is weird?
It should probe whatever the state of stdin.




and we can not use this driver in other manner than stdin console.

This patch fixes this by adding an else statement. It simply probes the
driver without console management in the case "usbkbd" is not in stdin.


Can you document the usecase in a bit more detail ?


My usecase is to get a key press from the USB keyboard and do some thing about
it in board_init. I do not want to multiplex the keyboard input to stdin but I
still want to read character from it.


All right, understood, both. Thanks for clarification.

I applied this to usb/next , I hope that's OK ?


Re: [PATCH] usb: kbd: allow probing even if usbkbd not in stdin

2022-06-27 Thread Köry Maincent
On Mon, 27 Jun 2022 13:39:03 +0200
Marek Vasut  wrote:

> >> Can you document the usecase in a bit more detail ?  
> > 
> > My usecase is to get a key press from the USB keyboard and do some thing
> > about it in board_init. I do not want to multiplex the keyboard input to
> > stdin but I still want to read character from it.  
> 
> All right, understood, both. Thanks for clarification.
> 
> I applied this to usb/next , I hope that's OK ?

Great! Thanks!

Köry


Re: [PATCH v2 0/8] spl: binman: Fixes for BINMAN_SYMBOLS

2022-06-27 Thread Frieder Schrempf
Am 18.06.22 um 14:13 schrieb Alper Nebi Yasak:
> There's some trouble with an i.MX8M series [1] trying to use binman
> symbols. The crux of it is the 'u_boot_any' symbols BINMAN_SYMBOLS
> configs declare, and the boards creating partial binman images including
> an SPL without a U-Boot the symbol is referring to.
> 
> Normally this should be easy to resolve by disabling BINMAN_SYMBOLS
> configs, but that causes a build error. Apparently some parts of the SPL
> code (RAW_IMAGE_SUPPORT, RAM_DEVICE) use the symbols directly without
> guarding them by BINMAN_SYMBOLS, implicitly requiring it.
> 
> The first patch fixes the issue above, the rest are related things I
> tinkered with while trying to understand the issue and the i.MX8M use
> case. Part of this is splitting binman symbols support from enabling
> binman and from the u-boot-any symbols declarations. Another is to add a
> new macro people can use to check if they can use binman symbols safely.
> 
> These apply onto u-boot/next. I have also triggered an Azure CI run [2]
> via a Github pull request.

I tested this series together with the v7 of Peng's set "arm64: binman:
use binman symbols for imx" with kontron-sl-mx8mm.

Tested-by: Frieder Schrempf  #Kontron SL/BL
i.MX8MM


Re: [PATCH] efi_loader: Allow overlapped extra data for PE hashing

2022-06-27 Thread Heinrich Schuchardt

On 6/24/22 07:32, Su, Bao Cheng wrote:

During PE hashing, when holes exists between sections, the extra data
calculated could be a dupulicated region of the last section.

Such PE image with holes existing between sections may contain the
symbol table for the kernel, for example.

The Authenticode_PE spec does not rule how to deal with such scenario,
however, other tools such as pesign and sbsign both have the overlapped
regions hashed. And EDK2 hash the overlapped area as well.

Signed-off-by: Baocheng Su 
---
  lib/efi_loader/efi_image_loader.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 9611398885..d85fb6ba08 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -481,7 +481,7 @@ bool efi_image_parse(void *efi, size_t len, struct
efi_image_regions **regp,
EFI_PRINT("extra data for hash: %zu\n",
  len - (bytes_hashed + authsz));
efi_image_region_add(regs, efi + bytes_hashed,
-efi + len - authsz, 0);
+efi + len - authsz, 1);
}

/* Return Certificates Table */


Let us consider the case that the sum of gaps between sections is
greater than the size of the last section N.

start[N] > efi + bytes_hashed
end[N] < efi + len - authsz

Sbsigntool and EDK II sort regions by start address before adding the
extra data region and will accept this situation.

U-Boot's efi_image_region_add(nocheck = 1) will throw an error "%s: new
region already part of another\n".

It seems that this patch is not a complete solution.

Best regards

Heinrich


[PATCH 1/4] doc: Migrate CodingStyle wiki page to sphinx

2022-06-27 Thread Tom Rini
Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
The changes here are for formatting or slight rewording so that it reads
well when linking to other sphinx documents.

Signed-off-by: Tom Rini 
---
 doc/develop/codingstyle.rst | 211 
 doc/develop/index.rst   |   8 ++
 2 files changed, 219 insertions(+)
 create mode 100644 doc/develop/codingstyle.rst

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
new file mode 100644
index ..a41aed2764fb
--- /dev/null
+++ b/doc/develop/codingstyle.rst
@@ -0,0 +1,211 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Coding Style
+===
+
+The following Coding Style requirements shall be mandatory for all code 
contributed to
+the U-Boot project.
+
+Exceptions are only allowed if code from other projects is integrated with no
+or only minimal changes.
+
+The following rules apply:
+
+* All contributions to U-Boot should conform to the `Linux kernel
+  coding style 
`_
+  and the `Linent script 
`_.
+  * The exception for net files to the `multi-line comment
+  
`_
+  applies only to Linux, not to U-Boot. Only large hunks which are copied
+  unchanged from Linux may retain that comment format.
+* Use patman to send your patches (``tools/patman/patman -H`` for full
+  instructions). With a few tags in your commits this will check your patches
+  and take care of emailing them.
+* If you don't use patman, make sure to run ``scripts/checkpatch.pl``.  For
+  more information, read :doc:`checkpatch`.  Note that this should be done
+  *before* posting on the mailing list!
+* Source files originating from different projects (for example the MTD
+  subsystem or the hush shell code from the BusyBox project) may, after
+  careful consideration, be exempted from these rules. For such files, the
+  original coding style may be kept to ease subsequent migration to newer
+  versions of those sources.
+* Please note that U-Boot is implemented in C (and to some small parts in
+  Assembler); no C++ is used, so please do not use C++ style comments (//) in
+  your code.
+
+  * The sole exception here is for SPDX tags in some files (checkpatch.pl will 
warn you).
+
+* Please also stick to the following formatting rules:
+
+  * Remove any trailing white space
+  * Use TAB characters for indentation and vertical alignment, not spaces
+  * Make sure NOT to use DOS ``\r\n`` line feeds
+  * Do not add more than 2 consecutive empty lines to source files
+  * Do not add trailing empty lines to source files
+  * Using the option ``git config --global color.diff auto`` will help to
+visually see whitespace problems in ``diff`` output from ``git``.
+  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
+feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The Right
+Thing (tm)
+
+Submissions of new code or patches that do not conform to these requirements
+shall be rejected with a request to reformat the changes.
+
+U-Boot Code Documentation
+-
+
+U-Boot adopted the kernel-doc annotation style, this is the only exception from
+multi-line comment rule of Coding Style. While not mandatory, adding
+documentation is strongly advised. The Linux kernel `kernel-doc 
`_ 
documentation applies with no changes.
+applies with no changes.
+
+Use structures for I/O access
+-
+
+U-Boot typically uses a C structure to map out the registers in an I/O region, 
rather than offsets. The reasons for this are:
+
+* It dissociates the register location (offset) from the register type, which
+  means the developer has to make sure the type is right for each access,
+  whereas with the struct method, this is checked by the compiler;
+* It avoids actually writing all offsets, which is (more) error- prone;
+* It allows for better compile time sanity-checking of values we write to 
registers.
+
+Some reasons why you might not use C structures:
+
+* Where the registers appear at different offsets in different hardware
+  revisions supported by the same driver
+* Where the driver only uses a small subset of registers and it is not worth
+  defining a struct to cover them all, with large empty regions
+* Where the offset of a register might be hard to figure out when buried a long
+  way down a structure, possibly with embedded sub-structures
+* This may need to change to the kernel model if we allow for more run-time
+  detection of what drivers are appropriate for what we're running on.
+
+Please use check_member() to verify that your structure is the expected size, 
or that particular members appear at the right offset.
+
+Include files

[PATCH 3/4] doc: codingstyle: Remove comment about '//' style comments

2022-06-27 Thread Tom Rini
For some time now we've allowed for '//' style comments, which mirrors
the Linux kernel.  So drop this point here.

Signed-off-by: Tom Rini 
---
 doc/develop/codingstyle.rst | 5 -
 1 file changed, 5 deletions(-)

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index a41aed2764fb..bdf1efc6019a 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -29,11 +29,6 @@ The following rules apply:
   careful consideration, be exempted from these rules. For such files, the
   original coding style may be kept to ease subsequent migration to newer
   versions of those sources.
-* Please note that U-Boot is implemented in C (and to some small parts in
-  Assembler); no C++ is used, so please do not use C++ style comments (//) in
-  your code.
-
-  * The sole exception here is for SPDX tags in some files (checkpatch.pl will 
warn you).
 
 * Please also stick to the following formatting rules:
 
-- 
2.25.1



[PATCH 4/4] doc: Migrate Process wiki page to sphinx

2022-06-27 Thread Tom Rini
Move the current Process wiki page to doc/develop/process.rst.  The
changes here are for formatting or slight rewording so that it reads
well when linking to other sphinx documents.

Signed-off-by: Tom Rini 
---
 doc/develop/index.rst   |   1 +
 doc/develop/process.rst | 182 
 2 files changed, 183 insertions(+)
 create mode 100644 doc/develop/process.rst

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index c0f4f0ba413a..eab00a55382a 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -11,6 +11,7 @@ General
 
codingstyle
designprinciples
+   process
 
 Implementation
 --
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
new file mode 100644
index ..dd279fb9eff1
--- /dev/null
+++ b/doc/develop/process.rst
@@ -0,0 +1,182 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Development Process
+==
+
+Management Summary
+--
+
+* Development happens in Release Cycles of 3 months.
+* The first 2 weeks are called Merge Window, which is followed by a
+  Stabilization Period.
+* Patches with new code get only accepted while the Merge Window is open.
+* A patch that is generally in good shape and that was submitted while the
+  Merge Window was open is eligible to go into the upcoming release, even if
+  changes and resubmits are needed.
+* During the Stabilization Period, only patches that contain bug fixes get
+  applied.
+
+Phases of the Development Process
+-
+
+U-Boot development takes place in `Release Cycles
+`_.  A Release Cycle lasts
+normally for three months.
+
+The first two weeks of each Release Cycle are called *Merge Window*.
+
+It is followed by a *Stabilization Period*.
+
+The end of a Release Cycle is marked by the release of a new U-Boot version.
+
+Merge Window
+
+
+The Merge Window is the period when new patches get submitted
+(and hopefully accepted) for inclusion into U-Boot mainline.
+
+This is the only time when new code (like support for new processors or new
+boards, or other new features or reorganization of code) is accepted.
+
+Twilight Time
+-
+
+Usually patches do not get accepted as they are - the peer review that takes
+place will usually require changes and resubmits of the patches before they
+are considered to be ripe for inclusion into mainline.
+
+Also, the review often happens not immediately after a patch was submitted,
+but only when somebody (usually the responsible custodian) finds time to do
+this.
+
+In the result, the final version of such patches gets submitted after the
+merge window has been closed.
+
+It is current practice in U-Boot that such patches are eligible to go into the
+upcoming release.
+
+In the result, the release of the ``"-rc1"`` version does not immediately 
follow
+the closing of the Merge Window.
+
+Stabilization Period
+
+
+During the Stabilization Period only patches containing bug fixes get
+applied.
+
+Corner Cases
+
+
+Sometimes it is not clear if a patch contains a bug fix or not.
+For example, changes that remove dead code, unused macros etc. or
+that contain Coding Style fixes are not strict bug fixes.
+
+In such situations it is up to the responsible custodian to decide if he
+applies such patches even when the Merge Window is closed.
+
+Exception: at the end of the Stabilization Period only strict bug
+fixes my be applied.
+
+Sometimes patches miss the the Merge Window slightly - say by few
+hours or even a day. Patch acceptance is not as critical as a
+financial transaction, or such. So if there is such a slight delay,
+the custodian is free to turn a blind eye and accept it anyway. The
+idea of the development process is to make it foreseeable,
+but not to slow down development.
+
+It makes more sense if an engineer spends another day on testing and
+cleanup and submits the patch a couple of hours late, instead of
+submitting a green patch which will waste efforts from several people
+during several rounds of review and reposts.
+
+Differences to Linux Development Process
+
+
+* In Linux, top-level maintainers will collect patches in their trees and send
+  pull requests to Linus as soon as the merge window opens.
+  So far, most U-Boot custodians do not work like that; they send pull requests
+  only at (or even after) the end of the merge window.
+* In Linux, the closing of the merge window is marked by the release of the
+  next ``"-rc1"``
+  In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
+  the) patches that were submitted during the merge window have been applied.
+
+Custodians
+--
+
+The Custodians take responsibility for some area of the U-Boot code.  The
+in-tree ``MAINTAINERS`` files list who is reponsible for which areas.
+
+It is their responsibility to pick up patches fro

[PATCH 2/4] doc: Migrate DesignPrinciples wiki page to sphinx

2022-06-27 Thread Tom Rini
Move the current DesignPrinciples wiki page to
doc/develop/designprinciples.rst.  The changes here are for formatting
or slight rewording so that it reads well when linking to other sphinx
documents.

Signed-off-by: Tom Rini 
---
 doc/develop/designprinciples.rst | 197 +++
 doc/develop/index.rst|   1 +
 2 files changed, 198 insertions(+)
 create mode 100644 doc/develop/designprinciples.rst

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
new file mode 100644
index ..79694db77604
--- /dev/null
+++ b/doc/develop/designprinciples.rst
@@ -0,0 +1,197 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Design Principles
+
+
+The 10 Golden Rules of U-Boot design
+
+
+Keep it Small
+^
+
+U-Boot is a Boot Loader, i.e. its primary purpose in the shipping
+system is to load some operating system.
+That means that U-Boot is
+necessary to perform a certain task, but it's nothing you want to
+throw any significant resources at. Typically U-Boot is stored in
+relatively small NOR flash memory, which is expensive
+compared to the much larger NAND devices often used to store the
+operating system and the application.
+
+At the moment, U-Boot supports boards with just 128 !KiB ROM or with
+256 !KiB NOR flash. We should not easily ignore such configurations -
+they may be the exception in among all the other supported boards,
+but if a design uses such a resource-constrained hardware setup it is
+usually because costs are critical, i. e. because the number of
+manufactured boards might be tens or hundreds of thousands or even
+millions...
+
+A usable and useful configuration of U-Boot, including a basic
+interactive command interpreter, support for download over Ethernet
+and the capability to program the flash shall fit in no more than 128 !KiB.
+
+Keep it Fast
+
+
+The end user is not interested in running U-Boot. In most embedded
+systems he is not even aware that U-Boot exists. The user wants to
+run some application code, and that as soon as possible after switching
+on his device.
+
+It is therefore essential that U-Boot is as fast as possible,
+especially that it loads and boots the operating system as fast as possible.
+
+To achieve this, the following design principles shall be followed:
+
+* Enable caches as soon and whenever possible
+* Initialize devices only when they are needed within U-Boot, i.e. don't
+  initialize the Ethernet interface(s) unless U-Boot performs a download over
+  Ethernet; don't  initialize any IDE or USB devices unless U-Boot actually
+  tries to load files from these, etc.  (and don't forget to shut down these
+  devices after using them  - otherwise nasty things may happen when you try to
+  boot your OS).
+
+Also, building of U-Boot shall be as fast as possible.
+This makes it easier to run a build for all supported configurations
+or at least for all configurations of a specific architecture,
+which is essential for quality assurance.
+If building is cumbersome and slow, most people will omit
+this important step.
+
+Keep it Simple
+^^
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities
+
+Keep it Portable
+
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities that are
+very closely related to hardware development. So far, it has been
+ported to several hundreds of different boards on about 30 different
+processor families - please make sure that any code you add can be
+used on as many different platforms as possible.
+
+Avoid assembly language whenever possible - only the reset code with
+basic CPU initialization, maybe a static DRAM initialization and the C
+stack setup should be in assembly.
+All further initializations should be done in C using assembly/C
+subroutines or inline macros. These functions represent some
+kind of HAL functionality and should be defined consistently on all
+architectures. E.g. Basic MMU and cache control, stack pointer manipulation.
+Non-existing functions should expand into empty macros or error codes.
+
+Don't make assumptions over the environment where U-Boot is running.
+It may be communicating with a human operator on directly attached
+serial console, but it may be through a GSM modem as well, or driven
+by some automatic test or control system. So don't output any fancy
+control character sequences or similar.
+
+Keep it Configurable
+
+
+Section "Keep it Small" already explains about the size restrictions
+for U-Boot on one side. On the other side, U-Boot is a powerful tool
+with many, many extremely useful features. The maintainer or user of
+each board will have to decide which features are important to him and
+what shall be included with his specific board configuration to meet
+his cur

[PATCH 0/4] Migrate some wiki pages to sphinx

2022-06-27 Thread Tom Rini
Hey all,

As you might have seen, the DENX wiki has undergone some updates in the
last few months.  As of now, most pages have been restored and are up to
date.  But it's also true that the wiki long predates our sphinx
documentation and readthedocs site (which I am very happy the work has
been put in on making and improving).  So to that end, I'm trying to
move everything that's on the wiki over to sphinx so that it will be
easier to access and keep up to date.  To that end, this small series
includes 3 pages being moved.

I don't know what to do about ReleaseCycle and the statics pages long
term.  I have a few ideas, but they're tricker so not what I want to
tackle first.

I'm thinking the next page to tackle is
https://www.denx.de/wiki/U-Boot/Patches which might well end up being
more than one page once moved.

And there's still some outdated information in what I'm posting here,
I'm not sure if a follow-up updating it is needed now, or just when
someone has a chance.

-- 
Tom




Re: [GIT PULL] xilinx patches for v2022.10

2022-06-27 Thread Tom Rini
On Mon, Jun 27, 2022 at 11:50:48AM +0200, Michal Simek wrote:

> Hi Tom,
> 
> please pull the following patches to your next branch.
> There are a lot of changes especially with Microblaze and having an option
> to disable MANUAL RELOC.
> 
> Gitlab CI doesn't show any issue.
> 
> And there is merge conflict with your next branch (Kconfig layout change)
> which is easy to resolve.
> Simply remove all reported lines from include/configs/microblaze-generic.h and
> include/configs/xilinx_zynqmp.h
> 
> Thanks,
> Michal
> 
> 
> The following changes since commit c18e5fb055ab789f58434e3cb432582adee0134c:
> 
>   dtoc: Update test_src_scan.py for new tegra compatibles (2022-06-14
> 13:59:23 -0400)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git
> tags/xilinx-for-v2022.10
> 
> for you to fetch changes up to 728a86edb63a647e6faf211c0dbc7bd0e4ff7ac6:
> 
>   timer: Add SPL_REGMAP dependency for Xilinx timer (2022-06-27 09:03:54 
> +0200)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 3/6] omap3: emif4: More clearly hard-code cs0 size

2022-06-27 Thread Tom Rini
We have a single platform that is both in the OMAP3 family of parts, but
has an EMIF4 memory controller.  Currently we hard-code the size of
chip select 0.  Make this more clear by putting the value in the
function rather than a CONFIG option.

Signed-off-by: Tom Rini 
---
 arch/arm/mach-omap2/omap3/emif4.c | 2 +-
 include/configs/am3517_evm.h  | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap3/emif4.c 
b/arch/arm/mach-omap2/omap3/emif4.c
index d7d779819bf3..491e7c23dbc6 100644
--- a/arch/arm/mach-omap2/omap3/emif4.c
+++ b/arch/arm/mach-omap2/omap3/emif4.c
@@ -41,7 +41,7 @@ static u32 get_sdr_cs_size(u32 cs)
 
/* TODO: Calculate the size based on EMIF4 configuration */
if (cs == CS0)
-   size = CONFIG_SYS_CS0_SIZE;
+   size = 256 * 1024 * 1024;
 
return size;
 }
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index e6c9039d1664..93beed4ad736 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -85,9 +85,6 @@
 
 /* memtest works on */
 
-/* Physical Memory Map */
-#define CONFIG_SYS_CS0_SIZE(256 * 1024 * 1024)
-
 /* FLASH and environment organization */
 
 /*  PISMO SUPPORT *** */
-- 
2.25.1



[PATCH 4/6] legoev3: Migrate to DM_I2C

2022-06-27 Thread Tom Rini
Perform a basic migration of the calls in setup_serial_number() to DM so
that we can switch to using DM_I2C on this platform.

Cc: David Lechner 
Signed-off-by: Tom Rini 
---
 board/lego/ev3/legoev3.c  | 15 +--
 configs/legoev3_defconfig |  2 +-
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/board/lego/ev3/legoev3.c b/board/lego/ev3/legoev3.c
index 980ffef4cdfd..834926013101 100644
--- a/board/lego/ev3/legoev3.c
+++ b/board/lego/ev3/legoev3.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -57,6 +58,8 @@ const int lpsc_size = ARRAY_SIZE(lpsc);
  */
 static void setup_serial_number(void)
 {
+   struct udevice *idev, *ibus;
+   int ret;
u32 offset;
char serial_number[13];
u8 buf[6];
@@ -65,7 +68,15 @@ static void setup_serial_number(void)
if (env_get("serial#"))
return;
 
-   if (i2c_read(EEPROM_I2C_ADDR, EEPROM_REV_OFFSET, 2, buf, 2)) {
+   ret = uclass_get_device_by_seq(UCLASS_I2C, 0, &ibus);
+   if (ret)
+   return;
+
+   ret = dm_i2c_probe(ibus, EEPROM_I2C_ADDR, 0, &idev);
+   if (ret)
+   return;
+
+   if (dm_i2c_read(idev, EEPROM_REV_OFFSET, buf, 2)) {
printf("\nEEPROM revision read failed!\n");
return;
}
@@ -83,7 +94,7 @@ static void setup_serial_number(void)
/* EEPROM rev 3 has Bluetooth address where rev should be */
offset = (eeprom_rev == 3) ? EEPROM_REV_OFFSET : EEPROM_BDADDR_OFFSET;
 
-   if (i2c_read(EEPROM_I2C_ADDR, offset, 2, buf, 6)) {
+   if (dm_i2c_read(idev, offset, buf, 6)) {
printf("\nEEPROM serial read failed!\n");
return;
}
diff --git a/configs/legoev3_defconfig b/configs/legoev3_defconfig
index 3612afb463c2..36e3d7069238 100644
--- a/configs/legoev3_defconfig
+++ b/configs/legoev3_defconfig
@@ -46,7 +46,7 @@ CONFIG_VERSION_VARIABLE=y
 # CONFIG_NET is not set
 CONFIG_DM=y
 # CONFIG_DM_DEVICE_REMOVE is not set
-CONFIG_SYS_I2C_LEGACY=y
+CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_DAVINCI=y
 CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
-- 
2.25.1



[PATCH 5/6] i2c: Remove non-DM_I2C support from davinci_i2c.c

2022-06-27 Thread Tom Rini
As the migration deadline has passed, and all platforms have been
migrated, remove the non-DM code here.

Signed-off-by: Tom Rini 
---
 arch/arm/mach-keystone/ddr3_spd.c| 13 
 drivers/i2c/Kconfig  |  4 +-
 drivers/i2c/davinci_i2c.c| 97 
 include/configs/legoev3.h|  6 --
 include/configs/omapl138_lcdk.h  |  2 -
 include/configs/ti_armv7_keystone2.h |  8 ---
 6 files changed, 2 insertions(+), 128 deletions(-)

diff --git a/arch/arm/mach-keystone/ddr3_spd.c 
b/arch/arm/mach-keystone/ddr3_spd.c
index c4a1908af8d0..6f7f8ab7b40c 100644
--- a/arch/arm/mach-keystone/ddr3_spd.c
+++ b/arch/arm/mach-keystone/ddr3_spd.c
@@ -404,24 +404,11 @@ static void init_ddr3param(struct ddr3_spd_cb *spd_cb,
 static int ddr3_read_spd(ddr3_spd_eeprom_t *spd_params)
 {
int ret;
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   int old_bus;
-
-   i2c_init(CONFIG_SYS_DAVINCI_I2C_SPEED, CONFIG_SYS_DAVINCI_I2C_SLAVE);
-
-   old_bus = i2c_get_bus_num();
-   i2c_set_bus_num(1);
-
-   ret = i2c_read(0x53, 0, 1, (unsigned char *)spd_params, 256);
-
-   i2c_set_bus_num(old_bus);
-#else
struct udevice *dev;
 
ret = i2c_get_chip_for_busnum(1, 0x53, 1, &dev);
if (!ret)
ret = dm_i2c_read(dev, 0, (unsigned char *)spd_params, 256);
-#endif
if (ret) {
printf("Cannot read DIMM params\n");
return 1;
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index d25c5736ef08..72d06e4972b5 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -687,9 +687,9 @@ config SYS_I2C_SPEED
 
 config SYS_I2C_BUS_MAX
int "Max I2C busses"
-   depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_SOCFPGA
+   depends on ARCH_OMAP2PLUS || ARCH_SOCFPGA
default 2 if TI816X
-   default 3 if OMAP34XX || AM33XX || AM43XX || ARCH_KEYSTONE
+   default 3 if OMAP34XX || AM33XX || AM43XX
default 4 if ARCH_SOCFPGA || OMAP44XX || TI814X
default 5 if OMAP54XX
help
diff --git a/drivers/i2c/davinci_i2c.c b/drivers/i2c/davinci_i2c.c
index a4abd25c3987..ae177227dea3 100644
--- a/drivers/i2c/davinci_i2c.c
+++ b/drivers/i2c/davinci_i2c.c
@@ -21,14 +21,12 @@
 #include 
 #include "davinci_i2c.h"
 
-#if CONFIG_IS_ENABLED(DM_I2C)
 /* Information about i2c controller */
 struct i2c_bus {
int id;
uintspeed;
struct i2c_regs *regs;
 };
-#endif
 
 #define CHECK_NACK() \
do {\
@@ -340,99 +338,6 @@ static int _davinci_i2c_probe_chip(struct i2c_regs 
*i2c_base, uint8_t chip)
return rc;
 }
 
-#if !CONFIG_IS_ENABLED(DM_I2C)
-static struct i2c_regs *davinci_get_base(struct i2c_adapter *adap)
-{
-   switch (adap->hwadapnr) {
-#if CONFIG_SYS_I2C_BUS_MAX >= 3
-   case 2:
-   return (struct i2c_regs *)I2C2_BASE;
-#endif
-#if CONFIG_SYS_I2C_BUS_MAX >= 2
-   case 1:
-   return (struct i2c_regs *)I2C1_BASE;
-#endif
-   case 0:
-   return (struct i2c_regs *)I2C_BASE;
-
-   default:
-   printf("wrong hwadapnr: %d\n", adap->hwadapnr);
-   }
-
-   return NULL;
-}
-
-static uint davinci_i2c_setspeed(struct i2c_adapter *adap, uint speed)
-{
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-   uint ret;
-
-   adap->speed = speed;
-   ret =  _davinci_i2c_setspeed(i2c_base, speed);
-
-   return ret;
-}
-
-static void davinci_i2c_init(struct i2c_adapter *adap, int speed,
-int slaveadd)
-{
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-
-   adap->speed = speed;
-   _davinci_i2c_init(i2c_base, speed, slaveadd);
-
-   return;
-}
-
-static int davinci_i2c_read(struct i2c_adapter *adap, uint8_t chip,
-   uint32_t addr, int alen, uint8_t *buf, int len)
-{
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-   return _davinci_i2c_read(i2c_base, chip, addr, alen, buf, len);
-}
-
-static int davinci_i2c_write(struct i2c_adapter *adap, uint8_t chip,
-uint32_t addr, int alen, uint8_t *buf, int len)
-{
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-
-   return _davinci_i2c_write(i2c_base, chip, addr, alen, buf, len);
-}
-
-static int davinci_i2c_probe_chip(struct i2c_adapter *adap, uint8_t chip)
-{
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-
-   return _davinci_i2c_probe_chip(i2c_base, chip);
-}
-
-U_BOOT_I2C_ADAP_COMPLETE(davinci_0, davinci_i2c_init, davinci_i2c_probe_chip,
-davinci_i2c_read, davinci_i2c_write,
-davinci_i2c_setspeed,
-CONFIG_SYS_DAVINCI_I2C_SPEED,
-CONFIG_SYS_DAVINCI_I2C_SLAVE,
-0)
-
-#if CONFIG_SYS_I2C_BUS_MAX >= 2
-U_BOOT_I2C_ADAP_COMPLETE(davinci_1, davinci_i2c_init, davinci_i2c_probe_chip,
-

[PATCH 1/6] Convert CONFIG_SYS_CACHE_STASHING to Kconfig

2022-06-27 Thread Tom Rini
This converts the following to Kconfig:
   CONFIG_SYS_CACHE_STASHING

Signed-off-by: Tom Rini 
---
 arch/powerpc/cpu/mpc85xx/Kconfig  | 3 +++
 configs/P2041RDB_NAND_defconfig   | 1 +
 configs/P2041RDB_SDCARD_defconfig | 1 +
 configs/P2041RDB_SPIFLASH_defconfig   | 1 +
 configs/P2041RDB_defconfig| 1 +
 configs/P3041DS_NAND_defconfig| 1 +
 configs/P3041DS_SDCARD_defconfig  | 1 +
 configs/P3041DS_SPIFLASH_defconfig| 1 +
 configs/P3041DS_defconfig | 1 +
 configs/P4080DS_SDCARD_defconfig  | 1 +
 configs/P4080DS_SPIFLASH_defconfig| 1 +
 configs/P4080DS_defconfig | 1 +
 configs/P5040DS_NAND_defconfig| 1 +
 configs/P5040DS_SDCARD_defconfig  | 1 +
 configs/P5040DS_SPIFLASH_defconfig| 1 +
 configs/P5040DS_defconfig | 1 +
 configs/T1024RDB_NAND_defconfig   | 1 +
 configs/T1024RDB_SDCARD_defconfig | 1 +
 configs/T1024RDB_SPIFLASH_defconfig   | 1 +
 configs/T1024RDB_defconfig| 1 +
 configs/T1042D4RDB_NAND_defconfig | 1 +
 configs/T1042D4RDB_SDCARD_defconfig   | 1 +
 configs/T1042D4RDB_SPIFLASH_defconfig | 1 +
 configs/T1042D4RDB_defconfig  | 1 +
 configs/T2080QDS_NAND_defconfig   | 1 +
 configs/T2080QDS_SDCARD_defconfig | 1 +
 configs/T2080QDS_SECURE_BOOT_defconfig| 1 +
 configs/T2080QDS_SPIFLASH_defconfig   | 1 +
 configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 1 +
 configs/T2080QDS_defconfig| 1 +
 configs/T2080RDB_NAND_defconfig   | 1 +
 configs/T2080RDB_SDCARD_defconfig | 1 +
 configs/T2080RDB_SPIFLASH_defconfig   | 1 +
 configs/T2080RDB_defconfig| 1 +
 configs/T2080RDB_revD_NAND_defconfig  | 1 +
 configs/T2080RDB_revD_SDCARD_defconfig| 1 +
 configs/T2080RDB_revD_SPIFLASH_defconfig  | 1 +
 configs/T2080RDB_revD_defconfig   | 1 +
 configs/T4240RDB_SDCARD_defconfig | 1 +
 configs/T4240RDB_defconfig| 1 +
 configs/kmcent2_defconfig | 1 +
 include/configs/P2041RDB.h| 1 -
 include/configs/T102xRDB.h| 1 -
 include/configs/T104xRDB.h| 1 -
 include/configs/T208xQDS.h| 1 -
 include/configs/T208xRDB.h| 1 -
 include/configs/T4240RDB.h| 1 -
 include/configs/corenet_ds.h  | 1 -
 include/configs/kmcent2.h | 1 -
 scripts/config_whitelist.txt  | 1 -
 50 files changed, 43 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 915e28e11088..b6881bf1ff39 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -1230,6 +1230,9 @@ config SYS_CPC_REINIT_F
 config SYS_FSL_CPC
bool "Corenet Platform Cache support"
 
+config SYS_CACHE_STASHING
+   bool "Enable cache stashing"
+
 config SYS_MPC85XX_NO_RESETVEC
bool "Discard resetvec section and move bootpg section up"
depends on MPC85xx
diff --git a/configs/P2041RDB_NAND_defconfig b/configs/P2041RDB_NAND_defconfig
index 4c453a7cd943..30bf78be1e6e 100644
--- a/configs/P2041RDB_NAND_defconfig
+++ b/configs/P2041RDB_NAND_defconfig
@@ -10,6 +10,7 @@ CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
 CONFIG_SYS_BOOK3E_HV=y
 CONFIG_SYS_FSL_CPC=y
+CONFIG_SYS_CACHE_STASHING=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PCIE3=y
diff --git a/configs/P2041RDB_SDCARD_defconfig 
b/configs/P2041RDB_SDCARD_defconfig
index b5f920b013e4..d5ad60981a2a 100644
--- a/configs/P2041RDB_SDCARD_defconfig
+++ b/configs/P2041RDB_SDCARD_defconfig
@@ -10,6 +10,7 @@ CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
 CONFIG_SYS_BOOK3E_HV=y
 CONFIG_SYS_FSL_CPC=y
+CONFIG_SYS_CACHE_STASHING=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PCIE3=y
diff --git a/configs/P2041RDB_SPIFLASH_defconfig 
b/configs/P2041RDB_SPIFLASH_defconfig
index ecf63e59c6b3..97b01b498bf1 100644
--- a/configs/P2041RDB_SPIFLASH_defconfig
+++ b/configs/P2041RDB_SPIFLASH_defconfig
@@ -11,6 +11,7 @@ CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
 CONFIG_SYS_BOOK3E_HV=y
 CONFIG_SYS_FSL_CPC=y
+CONFIG_SYS_CACHE_STASHING=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PCIE3=y
diff --git a/configs/P2041RDB_defconfig b/configs/P2041RDB_defconfig
index e609dfcbf216..c1eb08053299 100644
--- a/configs/P2041RDB_defconfig
+++ b/configs/P2041RDB_defconfig
@@ -11,6 +11,7 @@ CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
 CONFIG_SYS_BOOK3E_HV=y
 CONFIG_SYS_FSL_CPC=y
+CONFIG_SYS_CACHE_STASHING=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PCIE3=y
diff --git a/configs/P3041DS_NAND_defconfig b/configs/P3041DS_NAND_defconfig
index 59fdc33ad47d..1df522a7449a 100644
--- a/configs/P3041DS_NAND_defconfig
+++ b/configs/P3041DS_NAND_defconfig
@@ -10,6 +10,7 @@ CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
 CONFIG_SYS_BOOK

[PATCH 6/6] powerpc: Use the poison value of 0xdeadbeef directly in DDR init

2022-06-27 Thread Tom Rini
On p1_p2_rdb_pc platforms, we set ddr_data_init to the "poison" value of
0xdeadbeef rather than a real calculated / derived value.  Do this
directly and comment rather than via CONFIG.

Signed-off-by: Tom Rini 
---
 board/freescale/corenet_ds/p4080ds_ddr.c | 1 -
 board/freescale/p1_p2_rdb_pc/ddr.c   | 2 +-
 include/configs/P1010RDB.h   | 1 -
 include/configs/p1_p2_rdb_pc.h   | 1 -
 4 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/board/freescale/corenet_ds/p4080ds_ddr.c 
b/board/freescale/corenet_ds/p4080ds_ddr.c
index 3469064562bd..9839eaceaf95 100644
--- a/board/freescale/corenet_ds/p4080ds_ddr.c
+++ b/board/freescale/corenet_ds/p4080ds_ddr.c
@@ -62,7 +62,6 @@
 #define CONFIG_SYS_DDR_INIT_ADDR   0x
 #define CONFIG_SYS_DDR_INIT_EXT_ADDR   0x
 #define CONFIG_SYS_DDR_CS1_CONFIG  0x80004202
-#define CONFIG_SYS_DDR_DATA_INIT   0xdeadbeef
 #define CONFIG_SYS_DDR_TIMING_40x0001
 #define CONFIG_SYS_DDR_TIMING_50x02401400
 #define CONFIG_SYS_DDR_MODE_CONTROL0x
diff --git a/board/freescale/p1_p2_rdb_pc/ddr.c 
b/board/freescale/p1_p2_rdb_pc/ddr.c
index be803ddf9c66..038e6736acec 100644
--- a/board/freescale/p1_p2_rdb_pc/ddr.c
+++ b/board/freescale/p1_p2_rdb_pc/ddr.c
@@ -227,7 +227,7 @@ phys_size_t fixed_sdram(void)
.ddr_sdram_mode_2 = CONFIG_SYS_DDR_MODE_2,
.ddr_sdram_md_cntl = CONFIG_SYS_DDR_MODE_CONTROL,
.ddr_sdram_interval = CONFIG_SYS_DDR_INTERVAL,
-   .ddr_data_init = CONFIG_SYS_DDR_DATA_INIT,
+   .ddr_data_init = 0xdeadbeef, /* Poison value */
.ddr_sdram_clk_cntl = CONFIG_SYS_DDR_CLK_CTRL,
.ddr_init_addr = CONFIG_SYS_DDR_INIT_ADDR,
.ddr_init_ext_addr = CONFIG_SYS_DDR_INIT_EXT_ADDR,
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index d263999b5a71..12a78eac17c9 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -118,7 +118,6 @@ extern unsigned long get_sdram_size(void);
 #define CONFIG_SYS_DDR_CS0_BNDS0x003f
 #define CONFIG_SYS_DDR_CS0_CONFIG  0x80014302
 #define CONFIG_SYS_DDR_CS0_CONFIG_20x
-#define CONFIG_SYS_DDR_DATA_INIT   0xdeadbeef
 #define CONFIG_SYS_DDR_INIT_ADDR   0x
 #define CONFIG_SYS_DDR_INIT_EXT_ADDR   0x
 #define CONFIG_SYS_DDR_MODE_CONTROL0x
diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index b0b3ec18d143..b421cf3efebd 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -132,7 +132,6 @@
 #define CONFIG_SYS_DDR_CS1_CONFIG  0x80014302
 #define CONFIG_SYS_DDR_CS1_CONFIG_20x
 
-#define CONFIG_SYS_DDR_DATA_INIT   0xdeadbeef
 #define CONFIG_SYS_DDR_INIT_ADDR   0x
 #define CONFIG_SYS_DDR_INIT_EXT_ADDR   0x
 #define CONFIG_SYS_DDR_MODE_CONTROL0x
-- 
2.25.1



[PATCH 2/6] arm: Remove strongarm support

2022-06-27 Thread Tom Rini
There are no platforms using this architecture anymore, remove it.

Signed-off-by: Tom Rini 
---
 arch/arm/Kconfig|7 -
 arch/arm/Makefile   |2 -
 arch/arm/cpu/sa1100/Makefile|9 -
 arch/arm/cpu/sa1100/cpu.c   |   65 -
 arch/arm/cpu/sa1100/start.S |  126 -
 arch/arm/cpu/sa1100/timer.c |   66 -
 arch/arm/include/asm/arch-sa1100/bitfield.h |  112 -
 arch/arm/include/asm/proc-armv/system.h |3 +-
 drivers/usb/gadget/ether.c  |   15 -
 drivers/usb/gadget/gadget_chips.h   |9 -
 include/SA-1100.h   | 2833 ---
 11 files changed, 1 insertion(+), 3246 deletions(-)
 delete mode 100644 arch/arm/cpu/sa1100/Makefile
 delete mode 100644 arch/arm/cpu/sa1100/cpu.c
 delete mode 100644 arch/arm/cpu/sa1100/start.S
 delete mode 100644 arch/arm/cpu/sa1100/timer.c
 delete mode 100644 arch/arm/include/asm/arch-sa1100/bitfield.h
 delete mode 100644 include/SA-1100.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 434c5e98fa36..163e94fec0c1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -330,11 +330,6 @@ config CPU_V7R
select SYS_ARM_MPU
select SYS_CACHE_SHIFT_6
 
-config CPU_SA1100
-   bool
-   select SYS_CACHE_SHIFT_5
-   imply SYS_ARM_MMU
-
 config SYS_CPU
default "arm720t" if CPU_ARM720T
default "arm920t" if CPU_ARM920T
@@ -345,7 +340,6 @@ config SYS_CPU
default "armv7" if CPU_V7A
default "armv7" if CPU_V7R
default "armv7m" if CPU_V7M
-   default "sa1100" if CPU_SA1100
default "armv8" if ARM64
 
 config SYS_ARM_ARCH
@@ -359,7 +353,6 @@ config SYS_ARM_ARCH
default 7 if CPU_V7A
default 7 if CPU_V7M
default 7 if CPU_V7R
-   default 4 if CPU_SA1100
default 8 if ARM64
 
 choice
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 09fc31887880..a37603035d8a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -10,7 +10,6 @@ arch-$(CONFIG_CPU_ARM720T)=-march=armv4
 arch-$(CONFIG_CPU_ARM920T) =-march=armv4t
 arch-$(CONFIG_CPU_ARM926EJS)   =-march=armv5te
 arch-$(CONFIG_CPU_ARM946ES)=-march=armv5te
-arch-$(CONFIG_CPU_SA1100)  =-march=armv4
 arch-$(CONFIG_CPU_ARM1136) =-march=armv5t
 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
 arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
@@ -39,7 +38,6 @@ tune-$(CONFIG_CPU_ARM720T)=-mtune=arm7tdmi
 tune-$(CONFIG_CPU_ARM920T) =
 tune-$(CONFIG_CPU_ARM926EJS)   =
 tune-$(CONFIG_CPU_ARM946ES)=
-tune-$(CONFIG_CPU_SA1100)  =-mtune=strongarm1100
 tune-$(CONFIG_CPU_ARM1136) =
 tune-$(CONFIG_CPU_ARM1176) =
 tune-$(CONFIG_CPU_V7A) =-mtune=generic-armv7-a
diff --git a/arch/arm/cpu/sa1100/Makefile b/arch/arm/cpu/sa1100/Makefile
deleted file mode 100644
index 38193092cdb0..
--- a/arch/arm/cpu/sa1100/Makefile
+++ /dev/null
@@ -1,9 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-
-extra-y= start.o
-
-obj-y  += cpu.o
-obj-y  += timer.o
diff --git a/arch/arm/cpu/sa1100/cpu.c b/arch/arm/cpu/sa1100/cpu.c
deleted file mode 100644
index 6f67f7fc2284..
--- a/arch/arm/cpu/sa1100/cpu.c
+++ /dev/null
@@ -1,65 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH 
- * Marius Groeger 
- *
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH 
- * Alex Zuepke 
- */
-
-/*
- * CPU specific code
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static void cache_flush(void);
-
-int cleanup_before_linux (void)
-{
-   /*
-* this function is called just before we call linux
-* it prepares the processor for linux
-*
-* just disable everything that can disturb booting linux
-*/
-
-   disable_interrupts();
-
-   /* turn off I-cache */
-   icache_disable();
-   dcache_disable();
-
-   /* flush I-cache */
-   cache_flush();
-
-   return (0);
-}
-
-/* flush I/D-cache */
-static void cache_flush (void)
-{
-   unsigned long i = 0;
-
-   asm ("mcr p15, 0, %0, c7, c5, 0": :"r" (i));
-}
-
-#define RST_BASE 0x9003
-#define RSRR   0x00
-#define RCSR   0x04
-
-__attribute__((noreturn)) void reset_cpu(void)
-{
-   /* repeat endlessly */
-   while (1) {
-   writel(0, RST_BASE + RCSR);
-   writel(1, RST_BASE + RSRR);
-   }
-}
diff --git a/arch/arm/cpu/sa1100/start.S b/arch/arm/cpu/sa1100/start.S
deleted file mode 100644
index 2f84f20575c9..
--- a/arch/arm/cpu/sa1100/start.S
+++ /dev/null
@@ -1,126 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- *  armboot - Startup Code for SA1100 CPU
- *
- *  Copyright (C) 1998 Dan Malek 
- *  Copyright (C) 1999 Magnus Damm 
- *  Copyright (C) 2000 Wolfgang Denk 
- *  

Re: [PATCH] i2c: fix stack buffer overflow vulnerability in i2c md command

2022-06-27 Thread Tom Rini
On Mon, Jun 27, 2022 at 06:33:01AM +0200, Heiko Schocher wrote:
> Hello Nicolas,
> 
> On 21.06.22 16:04, Nicolas IOOSS wrote:
> > Hello,
> > 
> > I sent some days ago the vulnerability fix below. I have not received any 
> > reply yet. Could a maintainer take a look at it, please?
> 
> Sorry for that, but I was on the road (embedded world in nuremberg).
> 
> > Best regards,
> > Nicolas
> > 
> > --- Original Message ---
> > Le vendredi 10 juin 2022 à 4:50 PM,  a 
> > écrit :
> > 
> > 
> >> From: Nicolas Iooss nicolas.iooss+ub...@ledger.fr
> >>
> >>
> >> When running "i2c md 0 0 8100", the function do_i2c_md parses the
> >> length into an unsigned int variable named length. The value is then
> >> moved to a signed variable:
> >>
> >> int nbytes = length;
> >> #define DISP_LINE_LEN 16
> >> int linebytes = (nbytes > DISP_LINE_LEN) ? DISP_LINE_LEN : nbytes;
> >>
> >> ret = dm_i2c_read(dev, addr, linebuf, linebytes);
> >>
> >> On systems where integers are 32 bits wide, 0x8100 is a negative
> >> value to "nbytes > DISP_LINE_LEN" is false and linebytes gets assigned
> >>
> >> 0x8100 instead of 16.
> >>
> >> The consequence is that the function which reads from the i2c device
> >> (dm_i2c_read or i2c_read) is called with a 16-byte stack buffer to fill
> >> but with a size parameter which is too large. In some cases, this could
> >> trigger a crash. But with some i2c drivers, such as drivers/i2c/nx_i2c.c
> >> (used with "nexell,s5pxx18-i2c" bus), the size is actually truncated to
> >> a 16-bit integer. This is because function i2c_transfer expects an
> >> unsigned short length. In such a case, an attacker who can control the
> >> response of an i2c device can overwrite the return address of a function
> >> and execute arbitrary code through Return-Oriented Programming.
> >>
> >> Fix this issue by using unsigned integers types in do_i2c_md. While at
> >> it, make also alen unsigned, as signed sizes can cause vulnerabilities
> >> when people forgot to check that they can be negative.
> >>
> >> Signed-off-by: Nicolas Iooss nicolas.iooss+ub...@ledger.fr
> >>
> >> ---
> >> cmd/i2c.c | 24 
> >> 1 file changed, 12 insertions(+), 12 deletions(-)
> 
> Reviewed-by: Heiko Schocher 
> 
> @Tom: Should we add this to 2022.07? If so, feel free to pick it up,
>   thanks!

I'll pick this up directly along with the squashfs fix in the next day
or two, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/5] lib: sha1: Add support for hardware specific sha1_process

2022-06-27 Thread Tom Rini
On Wed, Jun 01, 2022 at 08:26:27PM +0200, Loic Poulain wrote:

> Mark sha1_process as weak to allow hardware specific implementation.
> Add parameter to support for multiple blocks processing.
> 
> Signed-off-by: Loic Poulain 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/5] sha1: Fix digest state size/type

2022-06-27 Thread Tom Rini
On Wed, Jun 01, 2022 at 08:26:28PM +0200, Loic Poulain wrote:

> sha1 digest size is 5*32-bit => 160-bit. Using 64-bit unsigned long
> does not cause issue with the current sha1 implementation, but could
> be problematic for vectorized access.
> 
> Signed-off-by: Loic Poulain 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 3/5] armv8 SHA-1 using ARMv8 Crypto Extensions:

2022-06-27 Thread Tom Rini
On Wed, Jun 01, 2022 at 08:26:29PM +0200, Loic Poulain wrote:

> This patch adds support for the SHA-1 Secure Hash Algorithm for CPUs
> that have support for the SHA-1 part of the ARM v8 Crypto Extensions.
> 
> It greatly improves sha-1 based operations, about 10x faster on iMX8M
> evk board. ~12ms vs ~165ms for a 20MiB kernel sha-1 verification.
> 
> asm implementation is a simplified version of the Linux version (from
> Ard Biesheuvel).
> 
> Signed-off-by: Loic Poulain 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 4/5] lib: sha256: Add support for hardware specific sha256_process

2022-06-27 Thread Tom Rini
On Wed, Jun 01, 2022 at 08:26:30PM +0200, Loic Poulain wrote:

> Mark sha256_process as weak to allow hardware specific implementation.
> Add parameter for supporting multiple blocks processing.
> 
> Signed-off-by: Loic Poulain 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 5/5] armv8 SHA-256 using ARMv8 Crypto Extensions

2022-06-27 Thread Tom Rini
On Wed, Jun 01, 2022 at 08:26:31PM +0200, Loic Poulain wrote:

> This patch adds support for the SHA-256 Secure Hash Algorithm for CPUs
> that have support for the SHA-256 part of the ARM v8 Crypto Extensions.
> 
> It greatly improves sha-256 based operations, about 17x faster on iMX8M
> evk board. ~12ms vs ~208ms for a 20MiB kernel sha-256 verification.
> 
> asm implementation is a simplified version of the Linux version (from
> Ard Biesheuvel).
> 
> Signed-off-by: Loic Poulain 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] qemu_arm64: Enable CONFIG_ARMV8_CRYPTO support

2022-06-27 Thread Tom Rini
On Thu, Jun 23, 2022 at 03:51:31PM -0400, Tom Rini wrote:

> Now that we can make use of CPU features for sha1/sha256, enable in QEMU
> so that we get some test coverage.
> 
> Cc: Loic Poulain 
> Cc: Tuomas Tynkkynen 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Issue with booting U-Boot from SD card, but using QSPI Flash for its Environment

2022-06-27 Thread David Antliff
> 
> From: Michal Simek 
> Sent: 27 June 2022 22:03
> To: David Antliff; u-boot@lists.denx.de
> Subject: Re: Issue with booting U-Boot from SD card, but using QSPI Flash for 
> its Environment
>
> Hi,
>
> On 6/27/22 05:01, David Antliff wrote:
> > Hi,
> >
> > I'm having some difficulty configuring U-Boot, in particular setting it up 
> > so that it can load from an SD card,
> > but access its Environment from QSPI Flash.
> >
> > First of all, is this even possible? Can the U-Boot environment be stored 
> > in a different location from where
> > U-Boot was loaded?
> >
> > Currently, I have a U-Boot image running from QSPI Flash on a Xilinx MPSoC 
> > ARM64 platform. I'm using Xilinx
> > PetaLinux however I think I understand how this configures U-Boot "under 
> > the hood" so I'll try to refer to
> > uboot.cfg​ as much as I can.
> >
> > Along with all the defaults, I have set:
> >
> > #define CONFIG_ENV_OFFSET 0x2E0
> > #define CONFIG_ENV_OVERWRITE 1
> > #define CONFIG_CMD_ERASEENV 1
> >
> > On this particular platform, there is a physical switch to switch the 
> > Xilinx first-stage bootloader (and ARM
> > Trusted Firmware) between QSPI Flash to SD card. This platform also 
> > requires a so-called "BOOT.BIN", which
> > contains the u-boot binary and other things (like the Xilinx FSBL, ARM 
> > Trusted Firmware, an FPGA image and
> > other things), to be written to QSPI Flash, which I have done. This is all 
> > working correctly, and the serial console
> > looks like this:
> >
> > Xilinx Zynq MP First Stage Boot Loader
> > Release 2021.2   Oct 13 2021  -  07:15:53
> > NOTICE:  BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
> > NOTICE:  BL31: Built : 07:41:24, Oct 13 2021
> >
> >
> > U-Boot 2021.01 (Oct 12 2021 - 09:28:42 +)
> >
> > CPU:   ZynqMP
> > Silicon: v3
> > Model: ZynqMP ZCU208 RevA
> > Board: Xilinx ZynqMP
> > DRAM:  4 GiB
> > PMUFW:  v1.1
> > EL Level:   EL2
> > Chip ID:zu48dr
> > NAND:  0 MiB
> > MMC:   mmc@ff17: 0
> > Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 
> > 512 Bytes, erase size 128 KiB, total 512 MiB
> > ...
> >
> > As you can see, U-Boot loads from QSPI Flash and the Environment is also 
> > loaded from QSPI Flash. All good.
> >
> > What I want to do is modify the system so that the earlier bootloader 
> > "BL31" loads U-Boot from the SD card. In my config I
> > already have CONFIG_ENV_IS_IN_FAT set to 1. When I copy BOOT.BIN to the 
> > first, FAT partition on an SD card, and set my
> > platform's boot mode to "SD Card" via the physical switch, the unit loads 
> > U-Boot from the SD card successfully, and the
> > serial console shows the above but with:
> >
> > Loading Environment from FAT... *** Warning - bad CRC, using default 
> > environment
> >
> > It works, although this warning is expected because there is no Environment 
> > saved on the SD card yet.
> > It does show that the SD card is being checked for the Environment though, 
> > so that's good.
> >
> > Note that this is the same build that I used for the QSPI flash boot 
> > earlier, so I'm currently under the impression that
> > U-Boot only looks for its Environment based on where it was loaded from, 
> > even if other locations are enabled.
> >
> > The issue is that I would like to configure U-Boot to be loaded from the SD 
> > card, but to use QSPI for its Environment,
> > so that we can store persistent U-Boot configuration on the board itself. 
> > Experimentally, it appears that U-Boot uses the
> > medium it was loaded from as the place to look for its Environment, 
> > although I haven't been able to confirm this.
> >
> > According to the U-Boot documentation I've read, disabling FAT as the 
> > default should be achievable by unsetting the
> > following in u-boot.cfg:
> >
> > CONFIG_ENV_IS_IN_FAT
> > CONFIG_SYS_MMC_ENV_DEV
> > CONFIG_ENV_FAT_DEVICE_AND_PART
> > CONFIG_ENV_IS_IN_FAT
> > CONFIG_ENV_FAT_FILE
> > CONFIG_SYS_MMC_ENV_PART
> > CONFIG_ENV_FAT_INTERFACE
> >
> > Performing the same installation steps as above, to have this new U-Boot 
> > loaded from the SD card, results in the
> > following output:
> >
> > Xilinx Zynq MP First Stage Boot Loader
> > Release 2021.2   Oct 13 2021  -  07:15:53
> > NOTICE:  BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
> > NOTICE:  BL31: Built : 07:41:24, Oct 13 2021
> >
> > And that's it! No more output. There is an LED on the board that goes from 
> > red to green, which I think indicates that
> > the FPGA image within BOOT.BIN has been loaded into the gate array 
> > successfully, so I think the earlier boot loader
> > has found BOOT.BIN. I have no reason therefore to think that U-Boot has not 
> > also been loaded, but if it has, it is
> > generating no output. I tried increasing the debug level of U-Boot to 7 
> > (DEBUG) in the hope of seeing something
> > from U-Boot, but that makes no difference. It's also not booting Linux, 
> > which 

Re: [PATCH v1] drivers: spi: sunxi: Fix spi speed settting

2022-06-27 Thread Andre Przywara
On Thu,  9 Jun 2022 17:09:39 +0800
qianfangui...@163.com wrote:

Hi Qianfan,

> From: qianfan Zhao 
> 
> dm_spi_claim_bus run spi_set_speed_mode first and then ops->claim_bus,
> but spi clock is enabled when sun4i_spi_claim_bus, that will make
> sun4i_spi_set_speed doesn't work.

Thanks for bringing this up, and sorry for the delay (please CC: the
U-Boot sunxi maintainers!).
So this is very similar to the patch as I sent earlier:
https://lore.kernel.org/u-boot/20220503212040.27884-3-andre.przyw...@arm.com/

Can you please check whether this works for you as well, then reply to
that patch?
I put my version of the patch plus more fixes and F1C100s support to:
https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/

Also I am curious under what circumstances and on what board you saw the
issue? In my case it was on the F1C100s, which has a higher base clock
(200 MHz instead of 24 MHz), so everything gets badly overclocked.

Thanks!
Andre

> Fix it.
> 
> Signed-off-by: qianfan Zhao 
> ---
>  drivers/spi/spi-sunxi.c | 78 -
>  1 file changed, 30 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> index b6cd7ddafa..1043cde976 100644
> --- a/drivers/spi/spi-sunxi.c
> +++ b/drivers/spi/spi-sunxi.c
> @@ -224,6 +224,7 @@ err_ahb:
>  static int sun4i_spi_claim_bus(struct udevice *dev)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
> + u32 div, reg;
>   int ret;
>  
>   ret = sun4i_spi_set_clock(dev->parent, true);
> @@ -233,12 +234,38 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
>   setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
>SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
>  
> + /* Setup clock divider */
> + div = SUN4I_SPI_MAX_RATE / (2 * priv->freq);
> + reg = readl(SPI_REG(priv, SPI_CCR));
> +
> + if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
> + if (div > 0)
> + div--;
> +
> + reg &= ~(SUN4I_CLK_CTL_CDR2_MASK | SUN4I_CLK_CTL_DRS);
> + reg |= SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
> + } else {
> + div = __ilog2(SUN4I_SPI_MAX_RATE) - __ilog2(priv->freq);
> + reg &= ~((SUN4I_CLK_CTL_CDR1_MASK << 8) | SUN4I_CLK_CTL_DRS);
> + reg |= SUN4I_CLK_CTL_CDR1(div);
> + }
> +
> + writel(reg, SPI_REG(priv, SPI_CCR));
> +
>   if (priv->variant->has_soft_reset)
>   setbits_le32(SPI_REG(priv, SPI_GCR),
>SPI_BIT(priv, SPI_GCR_SRST));
>  
> - setbits_le32(SPI_REG(priv, SPI_TCR), SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
> -  SPI_BIT(priv, SPI_TCR_CS_ACTIVE_LOW));
> + /* Setup the transfer control register */
> + reg = SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
> +   SPI_BIT(priv, SPI_TCR_CS_ACTIVE_LOW);
> +
> + if (priv->mode & SPI_CPOL)
> + reg |= SPI_BIT(priv, SPI_TCR_CPOL);
> + if (priv->mode & SPI_CPHA)
> + reg |= SPI_BIT(priv, SPI_TCR_CPHA);
> +
> + writel(reg, SPI_REG(priv, SPI_TCR));
>  
>   return 0;
>  }
> @@ -329,67 +356,22 @@ static int sun4i_spi_set_speed(struct udevice *dev, 
> uint speed)
>  {
>   struct sun4i_spi_plat *plat = dev_get_plat(dev);
>   struct sun4i_spi_priv *priv = dev_get_priv(dev);
> - unsigned int div;
> - u32 reg;
>  
>   if (speed > plat->max_hz)
>   speed = plat->max_hz;
>  
>   if (speed < SUN4I_SPI_MIN_RATE)
>   speed = SUN4I_SPI_MIN_RATE;
> - /*
> -  * Setup clock divider.
> -  *
> -  * We have two choices there. Either we can use the clock
> -  * divide rate 1, which is calculated thanks to this formula:
> -  * SPI_CLK = MOD_CLK / (2 ^ (cdr + 1))
> -  * Or we can use CDR2, which is calculated with the formula:
> -  * SPI_CLK = MOD_CLK / (2 * (cdr + 1))
> -  * Whether we use the former or the latter is set through the
> -  * DRS bit.
> -  *
> -  * First try CDR2, and if we can't reach the expected
> -  * frequency, fall back to CDR1.
> -  */
> -
> - div = SUN4I_SPI_MAX_RATE / (2 * speed);
> - reg = readl(SPI_REG(priv, SPI_CCR));
> -
> - if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
> - if (div > 0)
> - div--;
> -
> - reg &= ~(SUN4I_CLK_CTL_CDR2_MASK | SUN4I_CLK_CTL_DRS);
> - reg |= SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
> - } else {
> - div = __ilog2(SUN4I_SPI_MAX_RATE) - __ilog2(speed);
> - reg &= ~((SUN4I_CLK_CTL_CDR1_MASK << 8) | SUN4I_CLK_CTL_DRS);
> - reg |= SUN4I_CLK_CTL_CDR1(div);
> - }
>  
>   priv->freq = speed;
> - writel(reg, SPI_REG(priv, SPI_CCR));
> -
>   return 0;
>  }
>  
>  static int sun4i_spi_set_mode(struct udevice *dev, uint mode)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(dev);
> - u32 reg;
> -
> - reg = readl(SPI_REG(pr

Re: [PATCH 6/7] reset: sunxi: Convert driver private data to platform data

2022-06-27 Thread Andre Przywara
On Mon,  9 May 2022 00:29:36 -0500
Samuel Holland  wrote:

> The reason here is the same as the reason for changing the clock driver:
> platform data can be provided when binding the driver.

Yes, that's right. Confirmed to be almost completely s/priv/plat/.

> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
> 
>  drivers/reset/reset-sunxi.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/reset/reset-sunxi.c b/drivers/reset/reset-sunxi.c
> index 4d02d02834..b060d7f5ed 100644
> --- a/drivers/reset/reset-sunxi.c
> +++ b/drivers/reset/reset-sunxi.c
> @@ -17,24 +17,24 @@
>  #include 
>  #include 
>  
> -struct sunxi_reset_priv {
> +struct sunxi_reset_plat {
>   void *base;
>   const struct ccu_desc *desc;
>  };
>  
> -static const struct ccu_reset *priv_to_reset(struct sunxi_reset_priv *priv,
> +static const struct ccu_reset *plat_to_reset(struct sunxi_reset_plat *plat,
>unsigned long id)
>  {
> - return  &priv->desc->resets[id];
> + return  &plat->desc->resets[id];
>  }
>  
>  static int sunxi_reset_request(struct reset_ctl *reset_ctl)
>  {
> - struct sunxi_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct sunxi_reset_plat *plat = dev_get_plat(reset_ctl->dev);
>  
>   debug("%s: (RST#%ld)\n", __func__, reset_ctl->id);
>  
> - if (reset_ctl->id >= priv->desc->num_resets)
> + if (reset_ctl->id >= plat->desc->num_resets)
>   return -EINVAL;
>  
>   return 0;
> @@ -49,8 +49,8 @@ static int sunxi_reset_free(struct reset_ctl *reset_ctl)
>  
>  static int sunxi_set_reset(struct reset_ctl *reset_ctl, bool on)
>  {
> - struct sunxi_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> - const struct ccu_reset *reset = priv_to_reset(priv, reset_ctl->id);
> + struct sunxi_reset_plat *plat = dev_get_plat(reset_ctl->dev);
> + const struct ccu_reset *reset = plat_to_reset(plat, reset_ctl->id);
>   u32 reg;
>  
>   if (!(reset->flags & CCU_RST_F_IS_VALID)) {
> @@ -61,13 +61,13 @@ static int sunxi_set_reset(struct reset_ctl *reset_ctl, 
> bool on)
>   debug("%s: (RST#%ld) off#0x%x, BIT(%d)\n", __func__,
> reset_ctl->id, reset->off, ilog2(reset->bit));
>  
> - reg = readl(priv->base + reset->off);
> + reg = readl(plat->base + reset->off);
>   if (on)
>   reg |= reset->bit;
>   else
>   reg &= ~reset->bit;
>  
> - writel(reg, priv->base + reset->off);
> + writel(reg, plat->base + reset->off);
>  
>   return 0;
>  }
> @@ -89,11 +89,11 @@ struct reset_ops sunxi_reset_ops = {
>   .rst_deassert = sunxi_reset_deassert,
>  };
>  
> -static int sunxi_reset_probe(struct udevice *dev)
> +static int sunxi_reset_of_to_plat(struct udevice *dev)
>  {
> - struct sunxi_reset_priv *priv = dev_get_priv(dev);
> + struct sunxi_reset_plat *plat = dev_get_plat(dev);
>  
> - priv->base = dev_read_addr_ptr(dev);
> + plat->base = dev_read_addr_ptr(dev);
>  
>   return 0;
>  }
> @@ -101,7 +101,7 @@ static int sunxi_reset_probe(struct udevice *dev)
>  int sunxi_reset_bind(struct udevice *dev)
>  {
>   struct udevice *rst_dev;
> - struct sunxi_reset_priv *priv;
> + struct sunxi_reset_plat *plat;
>   int ret;
>  
>   ret = device_bind_driver_to_node(dev, "sunxi_reset", "reset",
> @@ -110,9 +110,9 @@ int sunxi_reset_bind(struct udevice *dev)
>   debug("failed to bind sunxi_reset driver (ret=%d)\n", ret);
>   return ret;
>   }
> - priv = malloc(sizeof(struct sunxi_reset_priv));
> - priv->desc = (const struct ccu_desc *)dev_get_driver_data(dev);
> - dev_set_priv(rst_dev, priv);
> + plat = malloc(sizeof(struct sunxi_reset_plat));
> + plat->desc = (const struct ccu_desc *)dev_get_driver_data(dev);
> + dev_set_plat(rst_dev, plat);
>  
>   return 0;
>  }
> @@ -121,6 +121,6 @@ U_BOOT_DRIVER(sunxi_reset) = {
>   .name   = "sunxi_reset",
>   .id = UCLASS_RESET,
>   .ops= &sunxi_reset_ops,
> - .probe  = sunxi_reset_probe,
> - .priv_auto  = sizeof(struct sunxi_reset_priv),
> + .of_to_plat = sunxi_reset_of_to_plat,
> + .plat_auto  = sizeof(struct sunxi_reset_plat),
>  };



Re: [PATCH 2/7] spi: sunxi: refactor SPI speed/mode programming

2022-06-27 Thread Andre Przywara
On Tue,  3 May 2022 22:20:35 +0100
Andre Przywara  wrote:

Hi,

> As George rightfully pointed out [1], the spi-sunxi driver programs the
> speed and mode settings only when the respective functions are called,
> but this gets lost over a call to release_bus(). That asserts the
> reset line, thus forces each SPI register back to its default value.
> Adding to that, trying to program SPI_CCR and SPI_TCR might be pointless
> in the first place, when the reset line is still asserted (before
> claim_bus()), so those setting won't apply most of the time. In reality
> I see two nested claim_bus() calls for the first use, so settings between
> the two would work (for instance for the initial "sf probe"). However
> later on the speed setting is not programmed into the hardware anymore.

So this issue was addressed with patches by both George (earlier, in a
different way) and Qianfan (later, in a very similar way).

Can someone (Jagan?) please have a look at this change from the U-Boot
SPI perspective? And also the other changes in this series?
I pushed them to the sunxi/next branch:
https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/

So can people please test this and report whether this now works as
expected?

Thanks,
Andre
 
> So far we get away with that default frequency, because that is a rather
> tame 24 MHz, which most SPI flash chips can handle just fine.
> 
> Move the actual register programming into a separate function, and use
> .set_speed and .set_mode just to set the variables in our priv structure.
> Then we only call this new function in claim_bus(), when we are sure
> that register accesses actually work and are preserved.
> 
> [1] https://lore.kernel.org/u-boot/20210725231636.879913-17...@yifangu.com/
> 
> Signed-off-by: Andre Przywara 
> Reported-by: George Hilliard 
> ---
>  drivers/spi/spi-sunxi.c | 95 ++---
>  1 file changed, 52 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> index b6cd7ddafad..d6b2dd09514 100644
> --- a/drivers/spi/spi-sunxi.c
> +++ b/drivers/spi/spi-sunxi.c
> @@ -221,6 +221,56 @@ err_ahb:
>   return ret;
>  }
>  
> +static void sun4i_spi_set_speed_mode(struct udevice *dev)
> +{
> + struct sun4i_spi_priv *priv = dev_get_priv(dev);
> + unsigned int div;
> + u32 reg;
> +
> + /*
> +  * Setup clock divider.
> +  *
> +  * We have two choices there. Either we can use the clock
> +  * divide rate 1, which is calculated thanks to this formula:
> +  * SPI_CLK = MOD_CLK / (2 ^ (cdr + 1))
> +  * Or we can use CDR2, which is calculated with the formula:
> +  * SPI_CLK = MOD_CLK / (2 * (cdr + 1))
> +  * Whether we use the former or the latter is set through the
> +  * DRS bit.
> +  *
> +  * First try CDR2, and if we can't reach the expected
> +  * frequency, fall back to CDR1.
> +  */
> +
> + div = SUN4I_SPI_MAX_RATE / (2 * priv->freq);
> + reg = readl(SPI_REG(priv, SPI_CCR));
> +
> + if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
> + if (div > 0)
> + div--;
> +
> + reg &= ~(SUN4I_CLK_CTL_CDR2_MASK | SUN4I_CLK_CTL_DRS);
> + reg |= SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
> + } else {
> + div = __ilog2(SUN4I_SPI_MAX_RATE) - __ilog2(priv->freq);
> + reg &= ~((SUN4I_CLK_CTL_CDR1_MASK << 8) | SUN4I_CLK_CTL_DRS);
> + reg |= SUN4I_CLK_CTL_CDR1(div);
> + }
> +
> + writel(reg, SPI_REG(priv, SPI_CCR));
> +
> + reg = readl(SPI_REG(priv, SPI_TCR));
> + reg &= ~(SPI_BIT(priv, SPI_TCR_CPOL) | SPI_BIT(priv, SPI_TCR_CPHA));
> +
> + if (priv->mode & SPI_CPOL)
> + reg |= SPI_BIT(priv, SPI_TCR_CPOL);
> +
> + if (priv->mode & SPI_CPHA)
> + reg |= SPI_BIT(priv, SPI_TCR_CPHA);
> +
> + writel(reg, SPI_REG(priv, SPI_TCR));
> +}
> +
>  static int sun4i_spi_claim_bus(struct udevice *dev)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
> @@ -240,6 +290,8 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
>   setbits_le32(SPI_REG(priv, SPI_TCR), SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
>SPI_BIT(priv, SPI_TCR_CS_ACTIVE_LOW));
>  
> + sun4i_spi_set_speed_mode(dev->parent);
> +
>   return 0;
>  }
>  
> @@ -329,46 +381,14 @@ static int sun4i_spi_set_speed(struct udevice *dev, 
> uint speed)
>  {
>   struct sun4i_spi_plat *plat = dev_get_plat(dev);
>   struct sun4i_spi_priv *priv = dev_get_priv(dev);
> - unsigned int div;
> - u32 reg;
>  
>   if (speed > plat->max_hz)
>   speed = plat->max_hz;
>  
>   if (speed < SUN4I_SPI_MIN_RATE)
>   speed = SUN4I_SPI_MIN_RATE;
> - /*
> -  * Setup clock divider.
> -  *
> -  * We have two choices there. Either we can use the clock
> -  * divide rate 1, which is calculated thanks to this formula:
> -  * SPI_CLK = MOD_CLK / (2 ^ (

Re: [PATCH 0/7] clk: sunxi: Out-of-bounds access fix and driver cleanup

2022-06-27 Thread Andre Przywara
On Mon,  9 May 2022 00:29:30 -0500
Samuel Holland  wrote:

Hi Samuel,

> This series fixes an issue with out-of-bounds access to the gate array
> (patches 1-2), uses the rearranged array size information to remove a
> bunch of duplicate code (patches 3-4), and then simplifies how the reset
> driver is bound (patches 5-7).
> 
> The original motivation for these changes was adding a driver for the
> legacy A31/A23/A33 PRCM binding (which I will send separately), and
> trying to use OF_PLATDATA in SPL (which did not work out). But I think
> at least some of the cleanup is worth applying on its own.
> 
> Patch 4 is generally the same change I made between v1 and v2 of the
> pinctrl series, using some #ifdefs to share a U_BOOT_DRIVER. It's not
> quite as clean as the pinctrl case, because here the SoC-specific parts
> are in different files, so all of the CCU descriptors have to be global.

Many thanks for your work on this!
So I am done with reviewing this series, and as mentioned quite like it
and am fine with it. I added F1C100s support, which got added in U-Boot
meanwhile, and pushed that to sunxi/next:
https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/

Can you please have a look and confirm that this is fine? I will then
send the PR in about two weeks time, if nothing breaks.

Cheers,
Andre

> Samuel Holland (7):
>   clk: sunxi: Store the array sizes in the CCU descriptor
>   clk: sunxi: Prevent out-of-bounds gate array access
>   reset: sunxi: Get the reset count from the CCU descriptor
>   clk: sunxi: Use a single driver for all variants
>   clk: sunxi: Convert driver private data to platform data
>   reset: sunxi: Convert driver private data to platform data
>   reset: sunxi: Reuse the platform data from the clock driver
> 
>  drivers/clk/sunxi/clk_a10.c   |  27 +-
>  drivers/clk/sunxi/clk_a10s.c  |  27 +-
>  drivers/clk/sunxi/clk_a23.c   |  27 +-
>  drivers/clk/sunxi/clk_a31.c   |  25 +
>  drivers/clk/sunxi/clk_a31_r.c |  29 +-
>  drivers/clk/sunxi/clk_a64.c   |  25 +
>  drivers/clk/sunxi/clk_a80.c   |  36 ++--
>  drivers/clk/sunxi/clk_a83t.c  |  25 +
>  drivers/clk/sunxi/clk_h3.c|  27 +-
>  drivers/clk/sunxi/clk_h6.c|  25 +
>  drivers/clk/sunxi/clk_h616.c  |  25 +
>  drivers/clk/sunxi/clk_h6_r.c  |  27 +-
>  drivers/clk/sunxi/clk_r40.c   |  25 +
>  drivers/clk/sunxi/clk_sunxi.c | 168 ++
>  drivers/clk/sunxi/clk_v3s.c   |  27 +-
>  drivers/reset/reset-sunxi.c   |  55 ++-
>  include/clk/sunxi.h   |  21 +
>  17 files changed, 208 insertions(+), 413 deletions(-)
> 



Re: [PATCH 5/7] clk: sunxi: Convert driver private data to platform data

2022-06-27 Thread Andre Przywara
On Mon,  9 May 2022 00:29:35 -0500
Samuel Holland  wrote:

> All of the driver private data should really be platform data since it
> is determined statically (selected by the compatible string or extracted
> from the devicetree). Move everything to platform data, so it can be
> provided when binding the driver. This is useful for SPL, or for
> instantiating the driver as part of an MFD.

Indeed, nothing in struct ccu_priv is private to the instance (of where
there is really only one anyway).
Confirmed to be mostly s/priv/plat/, the rest looks fine as well.

Reviewed-by: Andre Przywara 

Cheers,
Andre

> 
> Signed-off-by: Samuel Holland 
> ---
> 
>  drivers/clk/sunxi/clk_sunxi.c | 41 ---
>  include/clk/sunxi.h   |  4 ++--
>  2 files changed, 26 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk_sunxi.c b/drivers/clk/sunxi/clk_sunxi.c
> index 7d9e6029ff..cadfca767b 100644
> --- a/drivers/clk/sunxi/clk_sunxi.c
> +++ b/drivers/clk/sunxi/clk_sunxi.c
> @@ -15,19 +15,19 @@
>  #include 
>  #include 
>  
> -static const struct ccu_clk_gate *priv_to_gate(struct ccu_priv *priv,
> +static const struct ccu_clk_gate *plat_to_gate(struct ccu_plat *plat,
>  unsigned long id)
>  {
> - if (id >= priv->desc->num_gates)
> + if (id >= plat->desc->num_gates)
>   return NULL;
>  
> - return &priv->desc->gates[id];
> + return &plat->desc->gates[id];
>  }
>  
>  static int sunxi_set_gate(struct clk *clk, bool on)
>  {
> - struct ccu_priv *priv = dev_get_priv(clk->dev);
> - const struct ccu_clk_gate *gate = priv_to_gate(priv, clk->id);
> + struct ccu_plat *plat = dev_get_plat(clk->dev);
> + const struct ccu_clk_gate *gate = plat_to_gate(plat, clk->id);
>   u32 reg;
>  
>   if (!gate || !(gate->flags & CCU_CLK_F_IS_VALID)) {
> @@ -38,13 +38,13 @@ static int sunxi_set_gate(struct clk *clk, bool on)
>   debug("%s: (CLK#%ld) off#0x%x, BIT(%d)\n", __func__,
> clk->id, gate->off, ilog2(gate->bit));
>  
> - reg = readl(priv->base + gate->off);
> + reg = readl(plat->base + gate->off);
>   if (on)
>   reg |= gate->bit;
>   else
>   reg &= ~gate->bit;
>  
> - writel(reg, priv->base + gate->off);
> + writel(reg, plat->base + gate->off);
>  
>   return 0;
>  }
> @@ -71,19 +71,10 @@ static int sunxi_clk_bind(struct udevice *dev)
>  
>  static int sunxi_clk_probe(struct udevice *dev)
>  {
> - struct ccu_priv *priv = dev_get_priv(dev);
>   struct clk_bulk clk_bulk;
>   struct reset_ctl_bulk rst_bulk;
>   int ret;
>  
> - priv->base = dev_read_addr_ptr(dev);
> - if (!priv->base)
> - return -ENOMEM;
> -
> - priv->desc = (const struct ccu_desc *)dev_get_driver_data(dev);
> - if (!priv->desc)
> - return -EINVAL;
> -
>   ret = clk_get_bulk(dev, &clk_bulk);
>   if (!ret)
>   clk_enable_bulk(&clk_bulk);
> @@ -95,6 +86,21 @@ static int sunxi_clk_probe(struct udevice *dev)
>   return 0;
>  }
>  
> +static int sunxi_clk_of_to_plat(struct udevice *dev)
> +{
> + struct ccu_plat *plat = dev_get_plat(dev);
> +
> + plat->base = dev_read_addr_ptr(dev);
> + if (!plat->base)
> + return -ENOMEM;
> +
> + plat->desc = (const struct ccu_desc *)dev_get_driver_data(dev);
> + if (!plat->desc)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  extern const struct ccu_desc a10_ccu_desc;
>  extern const struct ccu_desc a10s_ccu_desc;
>  extern const struct ccu_desc a23_ccu_desc;
> @@ -205,6 +211,7 @@ U_BOOT_DRIVER(sunxi_clk) = {
>   .of_match   = sunxi_clk_ids,
>   .bind   = sunxi_clk_bind,
>   .probe  = sunxi_clk_probe,
> - .priv_auto  = sizeof(struct ccu_priv),
> + .of_to_plat = sunxi_clk_of_to_plat,
> + .plat_auto  = sizeof(struct ccu_plat),
>   .ops= &sunxi_clk_ops,
>  };
> diff --git a/include/clk/sunxi.h b/include/clk/sunxi.h
> index 11caf12b17..e90e078972 100644
> --- a/include/clk/sunxi.h
> +++ b/include/clk/sunxi.h
> @@ -70,12 +70,12 @@ struct ccu_desc {
>  };
>  
>  /**
> - * struct ccu_priv - sunxi clock control unit
> + * struct ccu_plat - sunxi clock control unit platform data
>   *
>   * @base:base address
>   * @desc:ccu descriptor
>   */
> -struct ccu_priv {
> +struct ccu_plat {
>   void *base;
>   const struct ccu_desc *desc;
>  };



Re: [PATCH 7/7] reset: sunxi: Reuse the platform data from the clock driver

2022-06-27 Thread Andre Przywara
On Mon,  9 May 2022 00:29:37 -0500
Samuel Holland  wrote:

Hi,

> The clock and reset drivers use the exact same platform data. Simplify
> them by sharing the object. This is safe because the parent device
> (the clock device) always gets its driver model callbacks run first.
> 
> Signed-off-by: Samuel Holland 

I am not too familiar with U-Boot's DM internals (device_bind()), but
the idea is certainly good, and it seems to work, so I am happy with
that.

Acked-by: Andre Przywara 

Cheers,
Andre


> ---
> 
>  drivers/clk/sunxi/clk_sunxi.c |  7 +-
>  drivers/reset/reset-sunxi.c   | 43 +++
>  include/clk/sunxi.h   |  8 ---
>  3 files changed, 9 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk_sunxi.c b/drivers/clk/sunxi/clk_sunxi.c
> index cadfca767b..10c5d2f4b6 100644
> --- a/drivers/clk/sunxi/clk_sunxi.c
> +++ b/drivers/clk/sunxi/clk_sunxi.c
> @@ -12,9 +12,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +extern U_BOOT_DRIVER(sunxi_reset);
> +
>  static const struct ccu_clk_gate *plat_to_gate(struct ccu_plat *plat,
>  unsigned long id)
>  {
> @@ -66,7 +69,9 @@ struct clk_ops sunxi_clk_ops = {
>  
>  static int sunxi_clk_bind(struct udevice *dev)
>  {
> - return sunxi_reset_bind(dev);
> + /* Reuse the platform data for the reset driver. */
> + return device_bind(dev, DM_DRIVER_REF(sunxi_reset), "reset",
> +dev_get_plat(dev), dev_ofnode(dev), NULL);
>  }
>  
>  static int sunxi_clk_probe(struct udevice *dev)
> diff --git a/drivers/reset/reset-sunxi.c b/drivers/reset/reset-sunxi.c
> index b060d7f5ed..5d4b8dc92f 100644
> --- a/drivers/reset/reset-sunxi.c
> +++ b/drivers/reset/reset-sunxi.c
> @@ -12,17 +12,10 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  
> -struct sunxi_reset_plat {
> - void *base;
> - const struct ccu_desc *desc;
> -};
> -
> -static const struct ccu_reset *plat_to_reset(struct sunxi_reset_plat *plat,
> +static const struct ccu_reset *plat_to_reset(struct ccu_plat *plat,
>unsigned long id)
>  {
>   return  &plat->desc->resets[id];
> @@ -30,7 +23,7 @@ static const struct ccu_reset *plat_to_reset(struct 
> sunxi_reset_plat *plat,
>  
>  static int sunxi_reset_request(struct reset_ctl *reset_ctl)
>  {
> - struct sunxi_reset_plat *plat = dev_get_plat(reset_ctl->dev);
> + struct ccu_plat *plat = dev_get_plat(reset_ctl->dev);
>  
>   debug("%s: (RST#%ld)\n", __func__, reset_ctl->id);
>  
> @@ -49,7 +42,7 @@ static int sunxi_reset_free(struct reset_ctl *reset_ctl)
>  
>  static int sunxi_set_reset(struct reset_ctl *reset_ctl, bool on)
>  {
> - struct sunxi_reset_plat *plat = dev_get_plat(reset_ctl->dev);
> + struct ccu_plat *plat = dev_get_plat(reset_ctl->dev);
>   const struct ccu_reset *reset = plat_to_reset(plat, reset_ctl->id);
>   u32 reg;
>  
> @@ -89,38 +82,8 @@ struct reset_ops sunxi_reset_ops = {
>   .rst_deassert = sunxi_reset_deassert,
>  };
>  
> -static int sunxi_reset_of_to_plat(struct udevice *dev)
> -{
> - struct sunxi_reset_plat *plat = dev_get_plat(dev);
> -
> - plat->base = dev_read_addr_ptr(dev);
> -
> - return 0;
> -}
> -
> -int sunxi_reset_bind(struct udevice *dev)
> -{
> - struct udevice *rst_dev;
> - struct sunxi_reset_plat *plat;
> - int ret;
> -
> - ret = device_bind_driver_to_node(dev, "sunxi_reset", "reset",
> -  dev_ofnode(dev), &rst_dev);
> - if (ret) {
> - debug("failed to bind sunxi_reset driver (ret=%d)\n", ret);
> - return ret;
> - }
> - plat = malloc(sizeof(struct sunxi_reset_plat));
> - plat->desc = (const struct ccu_desc *)dev_get_driver_data(dev);
> - dev_set_plat(rst_dev, plat);
> -
> - return 0;
> -}
> -
>  U_BOOT_DRIVER(sunxi_reset) = {
>   .name   = "sunxi_reset",
>   .id = UCLASS_RESET,
>   .ops= &sunxi_reset_ops,
> - .of_to_plat = sunxi_reset_of_to_plat,
> - .plat_auto  = sizeof(struct sunxi_reset_plat),
>  };
> diff --git a/include/clk/sunxi.h b/include/clk/sunxi.h
> index e90e078972..b9587050d9 100644
> --- a/include/clk/sunxi.h
> +++ b/include/clk/sunxi.h
> @@ -82,12 +82,4 @@ struct ccu_plat {
>  
>  extern struct clk_ops sunxi_clk_ops;
>  
> -/**
> - * sunxi_reset_bind() - reset binding
> - *
> - * @dev:   reset device
> - * Return: 0 success, or error value
> - */
> -int sunxi_reset_bind(struct udevice *dev);
> -
>  #endif /* _CLK_SUNXI_H */



RE: [PATCH RESEND 3/5] config/ast2600: Disable hash hardware accel

2022-06-27 Thread Neal Liu
> On Mon, 27 Jun 2022 at 08:55, Neal Liu  wrote:
> >
> > > Reviewed-by: Chia-Wei Wang 
> > >
> > > The QEMU emulation issue is under investigation by Steven.
> > > The CRC32 and MD5 SW support will be added before we re-enabling HW
> > > crypto drivers.
> > >
> > > Chiawei
> > >
> > > > From: joel.s...@gmail.com  On Behalf Of Joel
> > > > Stanley
> > > > Sent: Monday, June 27, 2022 3:58 PM
> > > >
> > > > The HACE driver lacks support for all the hash types, causing boot
> > > > to fail with the default FIT configuration which uses CRC32.
> > > >
> > > > Additionally the Qemu model or the u-boot driver is unable to
> > > > correctly compute the SHA256 hash used in a FIT.
> > > >
> > > > Disable HACE by default while the above issues are worked out to
> > > > enable boot testing in Qemu.
> >
> > I don't think this is the right way to do it.
> >
> > First, it's fine that drivers can only support some algos. There is no 
> > rules that
> it must support CRC32.
> > Second, if Qemu test is failure, it should fix the Qemu HACE driver or 
> > disable
> it in Qemu, not in common defconfig in u-boot.
> > This will affect lots of people who use mainline for developments and
> productions.
> 
> While I agree with you in general, this board didn't boot until recently, and 
> it
> certainly doesn't have any users. Mainline u-boot lacks drivers for the 
> ast2600
> hardware it claims to support. There's no working storage driver in the tree
> (SPI NOR or eMMC).
> 
> While qemu support is not required for u-boot's CI, it is a hard dependency 
> of it
> being used in the OpenBMC project, which is where the majority of users come
> from. In that project we use a fork of the Aspeed SDK, which itself is a few
> thousand patches on top of u-boot v2019.04.
> 
> I propose this change as a way to get CI working for the board, so we can have
> a baseline set of working functionality, and make improvements from there.
> I've started submitting those improvements; we have changes on the list for
> eMMC support, I2C, and the Aspeed developers have a spi-nor driver under
> review.
> 

Okay, just make sure to re-enable these configs once the issue fixed.
Thanks

> Cheers,
> 
> Joel
> 
> > Thanks,
> >
> > -Neal
> >
> > > >
> > > > Signed-off-by: Joel Stanley 
> > > > ---
> > > >  configs/evb-ast2600_defconfig | 3 ---
> > > >  1 file changed, 3 deletions(-)
> > > >
> > > > diff --git a/configs/evb-ast2600_defconfig
> > > > b/configs/evb-ast2600_defconfig index f3a6cb222020..160bccff48e2
> > > > 100644
> > > > --- a/configs/evb-ast2600_defconfig
> > > > +++ b/configs/evb-ast2600_defconfig
> > > > @@ -59,9 +59,6 @@ CONFIG_REGMAP=y
> > > >  CONFIG_SPL_OF_TRANSLATE=y
> > > >  CONFIG_CLK=y
> > > >  CONFIG_SPL_CLK=y
> > > > -CONFIG_DM_HASH=y
> > > > -CONFIG_HASH_ASPEED=y
> > > > -CONFIG_ASPEED_ACRY=y
> > > >  CONFIG_ASPEED_GPIO=y
> > > >  CONFIG_DM_I2C=y
> > > >  CONFIG_MISC=y
> > > > --
> > > > 2.35.1
> >


Re: [PATCH 0/7] clk: sunxi: Out-of-bounds access fix and driver cleanup

2022-06-27 Thread Samuel Holland
Hi Andre,

On 6/27/22 7:40 PM, Andre Przywara wrote:
> On Mon,  9 May 2022 00:29:30 -0500
> Samuel Holland  wrote:
> 
> Hi Samuel,
> 
>> This series fixes an issue with out-of-bounds access to the gate array
>> (patches 1-2), uses the rearranged array size information to remove a
>> bunch of duplicate code (patches 3-4), and then simplifies how the reset
>> driver is bound (patches 5-7).
>>
>> The original motivation for these changes was adding a driver for the
>> legacy A31/A23/A33 PRCM binding (which I will send separately), and
>> trying to use OF_PLATDATA in SPL (which did not work out). But I think
>> at least some of the cleanup is worth applying on its own.
>>
>> Patch 4 is generally the same change I made between v1 and v2 of the
>> pinctrl series, using some #ifdefs to share a U_BOOT_DRIVER. It's not
>> quite as clean as the pinctrl case, because here the SoC-specific parts
>> are in different files, so all of the CCU descriptors have to be global.
> 
> Many thanks for your work on this!
> So I am done with reviewing this series, and as mentioned quite like it
> and am fine with it. I added F1C100s support, which got added in U-Boot
> meanwhile, and pushed that to sunxi/next:
> https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/
> 
> Can you please have a look and confirm that this is fine? I will then
> send the PR in about two weeks time, if nothing breaks.

Looks good to me, and thanks for taking care of F1C100s. My only trivial comment
is that you left out Sean's ack.

Regards,
Samuel


Re: [PATCH 2/7] spi: sunxi: refactor SPI speed/mode programming

2022-06-27 Thread Jesse Taube




On 6/27/22 20:31, Andre Przywara wrote:

On Tue,  3 May 2022 22:20:35 +0100
Andre Przywara  wrote:

Hi,


As George rightfully pointed out [1], the spi-sunxi driver programs the
speed and mode settings only when the respective functions are called,
but this gets lost over a call to release_bus(). That asserts the
reset line, thus forces each SPI register back to its default value.
Adding to that, trying to program SPI_CCR and SPI_TCR might be pointless
in the first place, when the reset line is still asserted (before
claim_bus()), so those setting won't apply most of the time. In reality
I see two nested claim_bus() calls for the first use, so settings between
the two would work (for instance for the initial "sf probe"). However
later on the speed setting is not programmed into the hardware anymore.


So this issue was addressed with patches by both George (earlier, in a
different way) and Qianfan (later, in a very similar way).

Can someone (Jagan?) please have a look at this change from the U-Boot
SPI perspective? And also the other changes in this series?
I pushed them to the sunxi/next branch:
https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/

So can people please test this and report whether this now works as
expected?


I'm very confused I have forgotten much about this patch set.
I'm going to test it, but why has it only been merged now?

Thanks,
Jesse

Thanks,
Andre
  

So far we get away with that default frequency, because that is a rather
tame 24 MHz, which most SPI flash chips can handle just fine.

Move the actual register programming into a separate function, and use
.set_speed and .set_mode just to set the variables in our priv structure.
Then we only call this new function in claim_bus(), when we are sure
that register accesses actually work and are preserved.

[1] https://lore.kernel.org/u-boot/20210725231636.879913-17...@yifangu.com/

Signed-off-by: Andre Przywara 
Reported-by: George Hilliard 
---
  drivers/spi/spi-sunxi.c | 95 ++---
  1 file changed, 52 insertions(+), 43 deletions(-)

diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
index b6cd7ddafad..d6b2dd09514 100644
--- a/drivers/spi/spi-sunxi.c
+++ b/drivers/spi/spi-sunxi.c
@@ -221,6 +221,56 @@ err_ahb:
return ret;
  }
  
+static void sun4i_spi_set_speed_mode(struct udevice *dev)

+{
+   struct sun4i_spi_priv *priv = dev_get_priv(dev);
+   unsigned int div;
+   u32 reg;
+
+   /*
+* Setup clock divider.
+*
+* We have two choices there. Either we can use the clock
+* divide rate 1, which is calculated thanks to this formula:
+* SPI_CLK = MOD_CLK / (2 ^ (cdr + 1))
+* Or we can use CDR2, which is calculated with the formula:
+* SPI_CLK = MOD_CLK / (2 * (cdr + 1))
+* Whether we use the former or the latter is set through the
+* DRS bit.
+*
+* First try CDR2, and if we can't reach the expected
+* frequency, fall back to CDR1.
+*/
+
+   div = SUN4I_SPI_MAX_RATE / (2 * priv->freq);
+   reg = readl(SPI_REG(priv, SPI_CCR));
+
+   if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
+   if (div > 0)
+   div--;
+
+   reg &= ~(SUN4I_CLK_CTL_CDR2_MASK | SUN4I_CLK_CTL_DRS);
+   reg |= SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
+   } else {
+   div = __ilog2(SUN4I_SPI_MAX_RATE) - __ilog2(priv->freq);
+   reg &= ~((SUN4I_CLK_CTL_CDR1_MASK << 8) | SUN4I_CLK_CTL_DRS);
+   reg |= SUN4I_CLK_CTL_CDR1(div);
+   }
+
+   writel(reg, SPI_REG(priv, SPI_CCR));
+
+   reg = readl(SPI_REG(priv, SPI_TCR));
+   reg &= ~(SPI_BIT(priv, SPI_TCR_CPOL) | SPI_BIT(priv, SPI_TCR_CPHA));
+
+   if (priv->mode & SPI_CPOL)
+   reg |= SPI_BIT(priv, SPI_TCR_CPOL);
+
+   if (priv->mode & SPI_CPHA)
+   reg |= SPI_BIT(priv, SPI_TCR_CPHA);
+
+   writel(reg, SPI_REG(priv, SPI_TCR));
+}
+
  static int sun4i_spi_claim_bus(struct udevice *dev)
  {
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
@@ -240,6 +290,8 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
setbits_le32(SPI_REG(priv, SPI_TCR), SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
 SPI_BIT(priv, SPI_TCR_CS_ACTIVE_LOW));
  
+	sun4i_spi_set_speed_mode(dev->parent);

+
return 0;
  }
  
@@ -329,46 +381,14 @@ static int sun4i_spi_set_speed(struct udevice *dev, uint speed)

  {
struct sun4i_spi_plat *plat = dev_get_plat(dev);
struct sun4i_spi_priv *priv = dev_get_priv(dev);
-   unsigned int div;
-   u32 reg;
  
  	if (speed > plat->max_hz)

speed = plat->max_hz;
  
  	if (speed < SUN4I_SPI_MIN_RATE)

speed = SUN4I_SPI_MIN_RATE;
-   /*
-* Setup clock divider.
-*
-* We have two choices there. Either we can use the clock
-* divide rate 1, which is c

Re: [PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-27 Thread Jim Liu
Hi Marek

Thank you for your reminder.
Dell is use novuton uboot git repo now.
and request us upstream it.

npcm7xx normal defconfig is poleg_evb_defconfig, so all people use
this config to build uboot.
and poleg_evb_defconfig is in uboot master now.

I separate all the drivers to several commits,after I modify each
driver coding style.
and the poleg_evb_defconfig will be updated in the last commit

When the upstream task is finished , Dell or others will use upstream uboot.

If you have any suggestions please let me know.


On Mon, Jun 27, 2022 at 5:31 PM Marek Vasut  wrote:
>
> On 6/27/22 07:30, Jim Liu wrote:
> > Hi Marek
>
> Hello all,
>
> > Thanks for your reply.
> > The answer is yes.
> > Our customer Dell is using our driver now.
> > so need upstream uboot source to uboot master.
>
> All right, so this Dell device is also going to be upstreamed then ?
>
> If the driver is just going to be upstream and never enabled, it would
> bitrot and be useless -- that's my concern.


Re: [PATCH] configs: ast2600: Move SPL bss section to DRAM space

2022-06-27 Thread Joel Stanley
Hi Chai Wei,

On Wed, 1 Jun 2022 at 08:21, Chia-Wei Wang  wrote:
>
> The commit b583348ca8c8 ("image: fit: Align hash output buffers") places
> the hash output buffer at the .bss section. However, AST2600 by default
> executes SPL in the NOR flash XIP way. This results in the hash output
> cannot be written to the buffer as it is located at the R/X only region.
>
> We need to move the .bss section out of the SPL body to the DRAM space,
> where hash output can be written to. This patch includes:
>  - Define the .bss section base and size
>  - A new SPL linker script is added with a separate .bss region specified
>  - Enable CONFIG_SPL_SEPARATE_BSS kconfig option
>
> Signed-off-by: Chia-Wei Wang 

This patch breaks booting for me.

My concern with the approach is it creates extra maintenance work.
When changes are made to the main linker script they need to be
mirrored here, or else the aspeed port will miss out. (Having the
machine tested in CI will help this somewhat, but only for the code
paths we can test under emulation).

I know the patch has been merged, but I have a few questions:

I imagine the ast2600 is not the only board that runs XIP. How do
other boards solve the problem?

What happens when a symbol that is used before DRAM training has
completed is placed in bss?

How do you plan to support systems that don't have NOR?

Cheers,

Joel


> ---
>  arch/arm/mach-aspeed/ast2600/u-boot-spl.lds | 94 +
>  configs/evb-ast2600_defconfig   |  3 +
>  include/configs/evb_ast2600.h   |  3 +
>  3 files changed, 100 insertions(+)
>  create mode 100644 arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
>
> diff --git a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds 
> b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
> new file mode 100644
> index 00..22b4e16d35
> --- /dev/null
> +++ b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
> @@ -0,0 +1,94 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2004-2008 Texas Instruments
> + *
> + * (C) Copyright 2002
> + * Gary Jennejohn, DENX Software Engineering, 
> + *
> + * (C) Copyright 2022
> + * Chia-Wei Wang 
> + */
> +
> +MEMORY { .nor : ORIGIN = CONFIG_SPL_TEXT_BASE,
> +   LENGTH = CONFIG_SPL_SIZE_LIMIT }
> +MEMORY { .bss : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
> +   LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
> +
> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> +OUTPUT_ARCH(arm)
> +ENTRY(_start)
> +SECTIONS
> +{
> +   . = 0x;
> +
> +   . = ALIGN(4);
> +   .text :
> +   {
> +   __image_copy_start = .;
> +   *(.vectors)
> +   CPUDIR/start.o (.text*)
> +   *(.text*)
> +   *(.glue*)
> +   } > .nor
> +
> +   . = ALIGN(4);
> +   .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } > .nor
> +
> +   . = ALIGN(4);
> +   .data : {
> +   *(.data*)
> +   } > .nor
> +
> +   . = ALIGN(4);
> +   .u_boot_list : {
> +   KEEP(*(SORT(.u_boot_list*)));
> +   } > .nor
> +
> +   . = ALIGN(4);
> +   .binman_sym_table : {
> +   __binman_sym_start = .;
> +   KEEP(*(SORT(.binman_sym*)));
> +   __binman_sym_end = .;
> +   } > .nor
> +
> +   . = ALIGN(4);
> +
> +   __image_copy_end = .;
> +
> +   .rel.dyn : {
> +   __rel_dyn_start = .;
> +   *(.rel*)
> +   __rel_dyn_end = .;
> +   } > .nor
> +
> +   .end :
> +   {
> +   *(.__end)
> +   } > .nor
> +
> +   _image_binary_end = .;
> +
> +   .bss : {
> +   __bss_start = .;
> +   *(.bss*)
> +. = ALIGN(4);
> +   __bss_end = .;
> +   } > .bss
> +
> +   __bss_size = __bss_end - __bss_start;
> +}
> +
> +#if defined(IMAGE_MAX_SIZE)
> +ASSERT(__image_copy_end - __image_copy_start <= (IMAGE_MAX_SIZE), \
> +   "SPL image too big");
> +#endif
> +
> +#if defined(CONFIG_SPL_BSS_MAX_SIZE)
> +ASSERT(__bss_end - __bss_start <= (CONFIG_SPL_BSS_MAX_SIZE), \
> +   "SPL image BSS too big");
> +#endif
> +
> +#if defined(CONFIG_SPL_MAX_FOOTPRINT)
> +ASSERT(__bss_end - _start <= (CONFIG_SPL_MAX_FOOTPRINT), \
> +   "SPL image plus BSS too big");
> +#endif
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> index f84b723bbb..d19e1d79ec 100644
> --- a/configs/evb-ast2600_defconfig
> +++ b/configs/evb-ast2600_defconfig
> @@ -1,6 +1,7 @@
>  CONFIG_ARM=y
>  CONFIG_SYS_DCACHE_OFF=y
>  CONFIG_SPL_SYS_THUMB_BUILD=y
> +CONFIG_SPL_LDSCRIPT="arch/arm/mach-aspeed/ast2600/u-boot-spl.lds"
>  CONFIG_ARCH_ASPEED=y
>  CONFIG_SYS_TEXT_BASE=0x8000
>  CONFIG_SYS_MALLOC_LEN=0x200
> @@ -35,6 +36,8 @@ CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
> +CONFIG_SPL_SEPARATE_BSS=y
> +# CONFIG_TPL_SEPARATE_BSS is not se

[PATCH] aspeed/ast2600: Fix SPL linker script

2022-06-27 Thread Joel Stanley
The commit 99e2fbcb69f0 ("linker_lists: Rename sections to remove .
prefix") changed the name of the linker list sections. As the Aspeed SPL
linker wasn't in the tree yet, it missed the change.

This updates the SPL linker to match arch/arm/cpu/u-boot-spl.lds which
Aspeed was copied from.

Fixes: 442a69c14375 ("configs: ast2600: Move SPL bss section to DRAM space")
Signed-off-by: Joel Stanley 
---

Note that the Aspeed script is still missing the following sections,
which would be a problem if --orphan-handling=warn or similar was added
to LDFLAGS in the future (or if some used data ended up in one of these
sections):

   .dynsym _image_binary_end : { *(.dynsym) }
   .dynbss : { *(.dynbss) }
   .dynstr : { *(.dynstr*) }
   .dynamic : { *(.dynamic*) }
   .hash : { *(.hash*) }
   .plt : { *(.plt*) }
   .interp : { *(.interp*) }
   .gnu : { *(.gnu*) }
   .ARM.exidx : { *(.ARM.exidx*) }

I assume we're safe because they're relating to dynamic objects, so we
don't generate any.

The following sections are not accounted for in both the aspeed linker script 
and
the generic arm one:

 orphan section `.vfp11_veneer' from `linker stubs' being placed in section 
`.vfp11_veneer'
 orphan section `.v4_bx' from `linker stubs' being placed in section `.v4_bx'
 orphan section `.iplt' from `arch/arm/cpu/armv7/start.o' being placed in 
section `.iplt'
 orphan section `.igot.plt' from `arch/arm/cpu/armv7/start.o' being placed in 
section `.igot.plt'

I assume they're not required as u-boot works without them.

 arch/arm/mach-aspeed/ast2600/u-boot-spl.lds | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds 
b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
index 22b4e16d35c5..95a509ba3f31 100644
--- a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
+++ b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
@@ -40,8 +40,8 @@ SECTIONS
} > .nor
 
. = ALIGN(4);
-   .u_boot_list : {
-   KEEP(*(SORT(.u_boot_list*)));
+   __u_boot_list : {
+   KEEP(*(SORT(__u_boot_list*)));
} > .nor
 
. = ALIGN(4);
@@ -68,7 +68,7 @@ SECTIONS
 
_image_binary_end = .;
 
-   .bss : {
+   .bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;
*(.bss*)
 . = ALIGN(4);
-- 
2.35.1



Re: [PATCH] configs: ast2600: Move SPL bss section to DRAM space

2022-06-27 Thread Sean Anderson

Hi Chai,

On 6/28/22 12:23 AM, Joel Stanley wrote:

Hi Chai Wei,

On Wed, 1 Jun 2022 at 08:21, Chia-Wei Wang  wrote:


The commit b583348ca8c8 ("image: fit: Align hash output buffers") places
the hash output buffer at the .bss section. However, AST2600 by default
executes SPL in the NOR flash XIP way. This results in the hash output
cannot be written to the buffer as it is located at the R/X only region.

We need to move the .bss section out of the SPL body to the DRAM space,
where hash output can be written to. This patch includes:
  - Define the .bss section base and size
  - A new SPL linker script is added with a separate .bss region specified
  - Enable CONFIG_SPL_SEPARATE_BSS kconfig option

Signed-off-by: Chia-Wei Wang 


This patch breaks booting for me.


Does the patch Joel posted [1] fix your issue? It seems like I used the wrong 
macro
in the first place, so hopefully this patch shouldn't be necessary.

--Sean

[1] https://lore.kernel.org/u-boot/20220620070117.3443066-1-j...@jms.id.au/





Re: [PATCH] efi: test/py: repair authenticated capsules tests

2022-06-27 Thread AKASHI Takahiro
Heinrich,

On Mon, Jun 27, 2022 at 12:46:07PM +0200, Heinrich Schuchardt wrote:
> On 6/27/22 12:23, Vincent Stehlé wrote:
> > The UEFI console initialisation has been modified by commit 68edbed454b8
> > ("efi_loader: initialize console size late"). A corresponding workaround is
> > now necessary for the automated tests, as added to some of the tests
> > already by commit e05bd68ed5fc ("test: work around for EFI terminal size
> > probing").
> > 
> > Add the same workaround to the UEFI authenticated capsules tests to repair
> > them.
> > 
> > This can be tested with sandbox_defconfig, sandbox64_defconfig or
> > sandbox_flattree_defconfig, plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.
> > 
> > Signed-off-by: Vincent Stehlé 
> 
> Why are these tests not run in Gitlab?
> Can't we permanently adjust one of said defconfigs for this purpose?
> Or do we need a new defconfig for testing?

Because we cannot turn on or off capsule authentication dynamically
on a single U-Boot image, we cannot test non-signed test cases
and signed test cases simultaneously in CI.

That is why I proposed a new config file for sandbox with
EFI_CAPSULE_AUTHENTICATE, but the idea was rejected (if I remember correctly, 
by Simon).

That said, I also made a small change to unsigned test cases
(test_efi_capsule_firmware(_*).py) so that they can *pass* even with
EFI_CAPSULE_AUTHENTICATE enabled.
(As you can image, however, actual capsule update never happens in
this test environment.)

commit e012550cd7d6 ("test/py: efi_capsule: check the results in case of
CAPSULE_AUTHENTICATE")


-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> > Cc: Heinrich Schuchardt 
> > ---
> >   .../tests/test_efi_capsule/test_capsule_firmware_signed_fit.py | 3 +++
> >   .../tests/test_efi_capsule/test_capsule_firmware_signed_raw.py | 2 ++
> >   2 files changed, 5 insertions(+)
> > 
> > diff --git 
> > a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py 
> > b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
> > index 4400b8f1368..d6ca9b16745 100644
> > --- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
> > +++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
> > @@ -40,6 +40,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
> >   with u_boot_console.log.section('Test Case 1-a, before reboot'):
> >   output = u_boot_console.run_command_list([
> >   'host bind 0 %s' % disk_img,
> > +'printenv -e PlatformLangCodes', # workaround for terminal 
> > size determination
> >   'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
> >   'efidebug boot order 1',
> >   'env set -e -nv -bs -rt OsIndications 
> > =0x0004',
> > @@ -115,6 +116,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
> >   with u_boot_console.log.section('Test Case 2-a, before reboot'):
> >   output = u_boot_console.run_command_list([
> >   'host bind 0 %s' % disk_img,
> > +'printenv -e PlatformLangCodes', # workaround for terminal 
> > size determination
> >   'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
> >   'efidebug boot order 1',
> >   'env set -e -nv -bs -rt OsIndications 
> > =0x0004',
> > @@ -192,6 +194,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
> >   with u_boot_console.log.section('Test Case 3-a, before reboot'):
> >   output = u_boot_console.run_command_list([
> >   'host bind 0 %s' % disk_img,
> > +'printenv -e PlatformLangCodes', # workaround for terminal 
> > size determination
> >   'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
> >   'efidebug boot order 1',
> >   'env set -e -nv -bs -rt OsIndications 
> > =0x0004',
> > diff --git 
> > a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py 
> > b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
> > index 1b5a1bb42eb..2bbaa9cc55f 100644
> > --- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
> > +++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
> > @@ -112,6 +112,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
> >   with u_boot_console.log.section('Test Case 2-a, before reboot'):
> >   output = u_boot_console.run_command_list([
> >   'host bind 0 %s' % disk_img,
> > +'printenv -e PlatformLangCodes', # workaround for terminal 
> > size determination
> >   'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
> >   'efidebug boot order 1',
> >   'env set -e -nv -bs -rt OsIndications 
> > =0x0004',
> > @@ -189,6 +190,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
> >   with u_boot_console.log.section('Tes