Re: [PATCH] ci: riscv: Update OpenSBI to v1.2

2023-07-04 Thread Leo Liang
On Tue, Jun 20, 2023 at 01:55:00PM +0800, Bin Meng wrote:
> Use the latest OpenSBI v1.2 release binaries for the RISC-V CI.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  .azure-pipelines.yml | 8 
>  .gitlab-ci.yml   | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
>

Reviewed-by: Leo Yu-Chi Liang 


Re: [PATCH 1/1] RISC-V: CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS description

2023-07-04 Thread Leo Liang
On Tue, Jul 04, 2023 at 02:14:21AM +0200, Heinrich Schuchardt wrote:
> Describe which numeric values can be used for as scratch options for
> OpenSBI.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/spl/Kconfig | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>

Reviewed-by: Leo Yu-Chi Liang 


Re: [PATCH] phy: phy-uclass: Add a missing error handling path

2023-07-04 Thread Bhupesh Sharma
Hi Jonas,

On Mon, 3 Jul 2023 at 01:18, Jonas Karlman  wrote:
>
> On 2023-07-02 20:47, Bhupesh Sharma wrote:
> > Since function 'phy_get_counts()' can return NULL,
> > add handling for that error path inside callers of
> > this function.
>
> Do you have any example where this can/has happened?

Yes, it happened while I was writing a UFS Host Controller driver for
u-boot and tried to initialize the UFS PHY via the generic u-boot PHY
CLASS utility functions, namely:

/* get phy */
ret = generic_phy_get_by_name(hba->dev, "ufsphy", );
...

/* phy initialization */
ret = generic_phy_init();
...
 /* power on phy */
ret = generic_phy_power_on();

> Counts should never be NULL in a normal working call flow. I am a bit
> worried that this patch may hide some other bug or use of an
> uninitialized phy struct.

I agree, but I found that if the UFS Host Controller driver would mess
up the phy call sequences while it was in a 'power_up_sequence',
instead of using the standard UCLASS_PHY
'generic_phy_get_by_index_nodev' flow, it might get a counts value
NULL and then the PHY driver would silently crash while setting /
accessing members of 'counts'.

int generic_phy_init(struct phy *phy)
{
counts = phy_get_counts(phy);
 ...
if (counts->init_count > 0) {
// crash
..

> The phy struct is initialized in generic_phy_get_by_index_nodev. That
> function should fail when counts cannot be allocated.
>
> Maybe generic_phy_get_by_index_nodev should unset phy->dev if it fails,
> or generic_phy_valid should be extended to also check phy->counts.
> That way generic_phy_valid would return false and these functions
> should return earlier before trying to use counts.

I agree, this error handling should be here for counts being
uninitialized, whether we do it per-function or at the top level.. As
I can see several users of the flow I described in the u-boot code
itself (for setting up a PHY), for e.g.:

 board/sunxi/board.c
 drivers/usb/cdns3/core.c

etc..

Thanks,
Bhupesh


Re: [PATCH 2/2] board: ae350: Add missing env variables for booti

2023-07-04 Thread Leo Liang
On Tue, Jul 04, 2023 at 07:13:21PM +0800, Yu Chien Peter Lin wrote:
> The 'booti' command is unable to boot Image.gz due to the absence
> of required environment variables 'kernel_comp_addr_r' and
> 'kernel_comp_size'.
> 
> This commit adds these variables and reorganizes the memory layout
> to prevent any overlap between binaries and files.
> 
> Signed-off-by: Yu Chien Peter Lin 
> ---
>  include/configs/ae350.h | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 

Reviewed-by: Leo Yu-Chi Liang 


Re: [PATCH 1/2] riscv: andes_plicsw: Fix IPI during OpenSBI invocation

2023-07-04 Thread Leo Liang
On Tue, Jul 04, 2023 at 07:13:20PM +0800, Yu Chien Peter Lin wrote:
> On some AE350 boards, we need to explicitly initialize the priority
> registers to a non-zero value so the boot hart can instruct secondary
> harts to jump to OpenSBI.
> 
> This patch also updates the information about PLICSW.
> 
> Signed-off-by: Yu Chien Peter Lin 
> ---
>  arch/riscv/lib/andes_plicsw.c | 25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 

Reviewed-by: Leo Yu-Chi Liang 


Re: [PATCH v1 0/4] Fix rtl8169 compile warning and add a new device ID

2023-07-04 Thread Minda Chen


Hi Joe and Ramon

 Sorry to disturb you. Could you please review this patchset. Thanks

On 2023/6/21 17:05, Minda Chen wrote:
> StarFive JH7110 uboot support PCIe and using rtl8169 network adapter
> PCIe device. But compile warning in rtl8169 driver cause CI test fail.
> So commit this patch set to fix it, Also a new device ID to adjust the
> PCI bar regions in rtl8169.
> 
> The StarFive JH7110 PCIe driver link:
> https://patchwork.ozlabs.org/project/uboot/cover/20230509082617.119018-1-minda.c...@starfivetech.com/
> 
> patch 1 is fix make pointer from integer warning.
>  eg: /home/minda/vf2/visionfive/u-boot/drivers/net/rtl8169.c:103:52: warning:
> passing argument 2 of ‘writew’ makes pointer from integer without a cast 
> [-Wint-conversion]
> patch 2 fix RISC-V 8169 descriptor less than DMA min aligned size warning
> patch 3 add new device ID
> patch 4 enable 8169 in JH7110 SoC configs file.
> 
> Minda Chen (4):
>   net: rtl8169: Fix compile warning in rtl8169 network adapter
>   net: rtl8169: Fix DMA min aligned compile warning in riscv
>   net: rtl8169: Add one more device ID
>   configs: starfive-jh7110: Add CONFIG_RTL8169
> 
>  configs/starfive_visionfive2_defconfig |  1 +
>  drivers/net/rtl8169.c  | 22 +-
>  2 files changed, 14 insertions(+), 9 deletions(-)
> 
> 
> base-commit: 50842b217fef505a0ec6662cc2acdc55d0bb23c5


RE: [PATCH v2 1/5] dm: test: Fix partition test to use mmc2

2023-07-04 Thread Jaehoon Chung



> -Original Message-
> From: U-Boot  On Behalf Of Joshua Watt
> Sent: Monday, July 3, 2023 10:40 PM
> To: u-boot@lists.denx.de
> Cc: Joshua Watt ; Simon Glass 
> Subject: [PATCH v2 1/5] dm: test: Fix partition test to use mmc2
> 
> d94d9844bc ("dm: part: Update test to use mmc2") attempted to make the
> test use mmc2, but the change was incomplete in that it didn't also
> change the strings that reference a specific partition. Fix these so
> that the test passes again
> 
> Signed-off-by: Joshua Watt 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  test/dm/part.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/test/dm/part.c b/test/dm/part.c
> index 35e99eeb01..d5c58d6e3f 100644
> --- a/test/dm/part.c
> +++ b/test/dm/part.c
> @@ -76,15 +76,15 @@ static int dm_test_part(struct unit_test_state *uts)
>   test(-EINVAL, "#test1", true);
>   test(1, "2", false);
>   test(1, "2", true);
> - test(-ENOENT, "1:0", false);
> - test(0, "1:0", true);
> - test(1, "1:1", false);
> - test(2, "1:2", false);
> - test(1, "1.0", false);
> - test(0, "1.0:0", true);
> - test(1, "1.0:1", false);
> - test(2, "1.0:2", false);
> - test(-EINVAL, "1#bogus", false);
> + test(-ENOENT, "2:0", false);
> + test(0, "2:0", true);
> + test(1, "2:1", false);
> + test(2, "2:2", false);
> + test(1, "2.0", false);
> + test(0, "2.0:0", true);
> + test(1, "2.0:1", false);
> + test(2, "2.0:2", false);
> + test(-EINVAL, "2#bogus", false);
>   test(1, "2#test1", false);
>   test(2, "2#test2", false);
>   ret = 0;
> --
> 2.33.0




[bug report] sunxi: H6: no ethernet on Orange Pi One Plus

2023-07-04 Thread Anne Macedo
Hey!

I'm trying to bake Linux images for the Orange Pi One Plus using Yocto.
Everything works fine, except for Ethernet.

On the u-boot prompt:

=> dhcp
No ethernet found.

After adding:

CONFIG_SPL_SPI_SUNXI=y
CONFIG_SUN8I_EMAC=y

to configs/orangepi_one_plus_defconfig, I started seeing this error:

=> dhcp
sun8i_emac_eth_start: Timeout

I saw this other bug report but I couldn't really understand what has
been made to fix this issue [1].

More context here [2].

[1] https://lists.denx.de/pipermail/u-boot/2021-June/451357.html
[2] https://github.com/linux-sunxi/meta-sunxi/issues/387

Regards,
Anne


Re: [PATCH 12/12] binman: Support simple templates

2023-07-04 Thread Simon Glass
Hi Jan,

On Mon, 3 Jul 2023 at 20:34, Jan Kiszka  wrote:
>
> Hi Simon,
>
> On 28.06.23 13:41, Simon Glass wrote:
> > Collections can used to collect the contents of other entries into a
> > single entry, but they result in a single entry, with the original entries
> > 'left behind' in their old place.
> >
> > It is useful to be able to specific a set of entries ones and have it used
> > in multiple images, or parts of an image.
> >
> > Implement this mechanism.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/binman/binman.rst  | 80 
> >  tools/binman/control.py  |  9 +++
> >  tools/binman/etype/section.py|  3 +-
> >  tools/binman/ftest.py|  8 +++
> >  tools/binman/test/286_entry_template.dts | 42 +
> >  5 files changed, 141 insertions(+), 1 deletion(-)
> >  create mode 100644 tools/binman/test/286_entry_template.dts
> >
> > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> > index a4b31fe5397b..9be979ae1c5b 100644
> > --- a/tools/binman/binman.rst
> > +++ b/tools/binman/binman.rst
> > @@ -727,6 +727,13 @@ optional:
> >  Note that missing, optional blobs do not produce a non-zero exit code 
> > from
> >  binman, although it does show a warning about the missing external 
> > blob.
> >
> > +insert-template:
> > +This is not strictly speaking an entry property, since it is processed 
> > early
> > +in Binman before the entries are read. It is a list of phandles of 
> > nodes to
> > +include in the current (target) node. For each node, its subnodes and 
> > their
> > +properties are brought into the target node. See Templates_ below for
> > +more information.
> > +
> >  The attributes supported for images and sections are described below. 
> > Several
> >  are similar to those for entries.
> >
> > @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is going 
> > on, you can use
> >   arch/arm/dts/u-boot.dtsi ... found: "arch/arm/dts/juno-r2-u-boot.dtsi"
> >
> >
> > +Templates
> > +=
> > +
> > +Sometimes multiple images need to be created which have all have a common
> > +part. For example, a board may generate SPI and eMMC images which both 
> > include
> > +a FIT. Since the FIT includes many entries, it is tedious to repeat them 
> > twice
> > +in the image description.
> > +
> > +Templates provide a simple way to handle this::
> > +
> > +binman {
> > +multiple-images;
> > +common_part: template-1 {
> > +fit {
> > +... lots of entries in here
> > +};
> > +
> > +text {
> > +text = "base image";
> > +};
> > +};
> > +
> > +spi-image {
> > +filename = "image-spi.bin";
> > +insert-template = <>;
> > +
> > +/* things specific to SPI follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "SPI image";
> > +};
> > +};
> > +
> > +mmc-image {
> > +filename = "image-mmc.bin";
> > +insert-template = <>;
> > +
> > +/* things specific to MMC follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "MMC image";
> > +};
> > +};
> > +};
> > +
> > +The template node name must start with 'template', so it is not considered 
> > to be
> > +an image itself.
> > +
> > +The mechanism is very simple. For each phandle in the 'insert-templates'
> > +property, the source node is looked up. Then the subnodes of that source 
> > node
> > +are copied into the target node, i.e. the one containing the 
> > `insert-template`
> > +property.
> > +
> > +If the target node has a node with the same name as a template, its 
> > properties
> > +override corresponding properties in the template. This allows the 
> > template to
> > +be uses as a base, with the node providing updates to the properties as 
> > needed.
> > +The overriding happens recursively.
> > +
> > +At present there is an unpleasant limitation on this feature: it works by
> > +appending the template nodes after any existing subnodes to the target 
> > node.
> > +This means that if the target node includes any subnodes, these appear in 
> > order
> > +before the template node. In the above example, 'header' becomes the first
> > +subnode of each image, followed by `fit` and `text`. If this is not what is
> > +desired, there is no way to adjust it.
> > +
> > +Note: The above limitation will likely be removed in future, so that the
> > +template subnodes appear before the target subnodes.
> > +
> > +
> >  Updating an ELF file
> >  
> >
> > diff --git a/tools/binman/control.py b/tools/binman/control.py
> > index 68597c4e7792..e7faca78e9aa 100644
> > --- a/tools/binman/control.py
> > +++ b/tools/binman/control.py
> > @@ -22,6 +22,7 @@ from 

Re: [PATCH] ARM: stm32: Power cycle Buck3 in reset on DHSOM

2023-07-04 Thread Marek Vasut

On 5/18/23 00:02, Marek Vasut wrote:

In case the DHSOM is in suspend state and either reset button is pushed
or IWDG2 triggers a watchdog reset, then DRAM initialization could fail
as follows:

   "
   RAM: DDR3L 32bits 2x4Gb 533MHz
   DDR invalid size : 0x4, expected 0x4000
   DRAM init failed: -22
   ### ERROR ### Please RESET the board ###
   "

Avoid this failure by not keeping any Buck regulators enabled during reset,
let the SoC and DRAMs power cycle fully. Since the change which keeps Buck3
VDD enabled during reset is ST specific, move this addition to ST specific
SPL board initialization so that it wouldn't affect the DHSOM .

Signed-off-by: Marek Vasut 
---
NOTE: This is 2023.07 material


I don't see this one in 2023.07 yet, can you please pick it and send PR?

Thanks


Re: [PATCH 1/1] tools: spkgimage: correct printf specifier

2023-07-04 Thread Marek Vasut

On 7/4/23 22:18, Heinrich Schuchardt wrote:

Compiling on armv7 results in:

tools/renesas_spkgimage.c: In function ‘spkgimage_parse_config_line’:
tools/renesas_spkgimage.c:76:66: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 3 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
76 | "config error: unknown keyword on line %ld\n",
   |~~^
   |  |
   |  long int
   |%d
77 | line_num);
   | 
   | |
   | size_t {aka unsigned int}

The correct printf specifier for size_t is '%zu'.

Fixes: afdfcb11f97c ("tools: spkgimage: add Renesas SPKG format")
Signed-off-by: Heinrich Schuchardt 
---
  tools/renesas_spkgimage.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/renesas_spkgimage.c b/tools/renesas_spkgimage.c
index fa0a468cc4..605d0ab149 100644
--- a/tools/renesas_spkgimage.c
+++ b/tools/renesas_spkgimage.c
@@ -73,7 +73,7 @@ static int spkgimage_parse_config_line(char *line, size_t 
line_num)
conf.padding = check_range(name, value, 1, INT_MAX);
} else {
fprintf(stderr,
-   "config error: unknown keyword on line %ld\n",
+   "config error: unknown keyword on line %zu\n",
line_num);
return -EINVAL;
}


Reviewed-by: Marek Vasut 

Tom, can you pick this directly for 2023.07 ? It is low impact and fixes 
a warning.


[PATCH 1/1] tools: spkgimage: correct printf specifier

2023-07-04 Thread Heinrich Schuchardt
Compiling on armv7 results in:

tools/renesas_spkgimage.c: In function ‘spkgimage_parse_config_line’:
tools/renesas_spkgimage.c:76:66: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 3 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
   76 | "config error: unknown keyword on line %ld\n",
  |~~^
  |  |
  |  long int
  |%d
   77 | line_num);
  | 
  | |
  | size_t {aka unsigned int}

The correct printf specifier for size_t is '%zu'.

Fixes: afdfcb11f97c ("tools: spkgimage: add Renesas SPKG format")
Signed-off-by: Heinrich Schuchardt 
---
 tools/renesas_spkgimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/renesas_spkgimage.c b/tools/renesas_spkgimage.c
index fa0a468cc4..605d0ab149 100644
--- a/tools/renesas_spkgimage.c
+++ b/tools/renesas_spkgimage.c
@@ -73,7 +73,7 @@ static int spkgimage_parse_config_line(char *line, size_t 
line_num)
conf.padding = check_range(name, value, 1, INT_MAX);
} else {
fprintf(stderr,
-   "config error: unknown keyword on line %ld\n",
+   "config error: unknown keyword on line %zu\n",
line_num);
return -EINVAL;
}
-- 
2.40.1



[PATCH v4 2/2] board: rockchip: add Radxa ROCK5A Rk3588 board

2023-07-04 Thread Eugen Hristev
ROCK 5A is a Rockchip RK3588S based SBC (Single Board Computer) by Radxa.

There are tree variants depending on the DRAM size : 4G, 8G and 16G.

Specifications:

 Rockchip Rk3588S SoC
 4x ARM Cortex-A76, 4x ARM Cortex-A55
 4/8/16GB memory LPDDR4x
 Mali G610MC4 GPU
 MIPI CSI 2 multiple lanes connector
 4-lane MIPI DSI connector
 Audio – 3.5mm earphone jack
 eMMC module connector
 uSD slot (up to 128GB)
 2x USB 2.0, 2x USB 3.0
 2x micro HDMI 2.1 ports, one up to 8Kp60, the other up to 4Kp60
 Gigabit Ethernet RJ45 with optional PoE support
 40-pin IO header including UART, SPI, I2C and 5V DC power in
 USB PD over USB Type-C
 Size: 85mm x 56mm (Raspberry Pi 4 form factor)

Kernel commits:
d1824cf95799 ("arm64: dts: rockchip: Add rock-5a board")
991f136c9f8d ("arm64: dts: rockchip: Update sdhci alias for rock-5a")
304c8a759953 ("arm64: dts: rockchip: Remove empty line from rock-5a")
cda0c2ea65a0 ("arm64: dts: rockchip: Fix RX delay for ethernet phy on 
rk3588s-rock5a")

Signed-off-by: Eugen Hristev 
---
Resent with correct email addresses

Changes in v4:
- tweaked the defconfig as reviewed by Jonas
- moved some of bootph-all to rk3588s-u-boot.dtsi
- renamed fdt fixup function
Changes in v3:
- forgot to add defconfig and include file, added now, sorry
Changes in v2:
-fixed wrong Kconfig text (rk3588s instead of rk3588)
-changed doc name (rk3588s instead of rk3588)

 arch/arm/dts/Makefile   |  1 +
 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi| 34 ++
 arch/arm/dts/rk3588s-rock-5a.dts| 73 +
 arch/arm/mach-rockchip/rk3588/Kconfig   | 28 
 board/radxa/rock5a-rk3588s/Kconfig  | 15 +
 board/radxa/rock5a-rk3588s/MAINTAINERS  |  6 ++
 board/radxa/rock5a-rk3588s/Makefile |  6 ++
 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c | 39 +++
 configs/rock5a-rk3588s_defconfig| 72 
 doc/board/rockchip/rockchip.rst |  1 +
 include/configs/rock5a-rk3588s.h| 15 +
 11 files changed, 290 insertions(+)
 create mode 100644 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588s-rock-5a.dts
 create mode 100644 board/radxa/rock5a-rk3588s/Kconfig
 create mode 100644 board/radxa/rock5a-rk3588s/MAINTAINERS
 create mode 100644 board/radxa/rock5a-rk3588s/Makefile
 create mode 100644 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c
 create mode 100644 configs/rock5a-rk3588s_defconfig
 create mode 100644 include/configs/rock5a-rk3588s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..cd9b96c5ba7c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -174,6 +174,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
 dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-evb1-v10.dtb \
+   rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RV1108) += \
diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi 
b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
new file mode 100644
index ..9bb0e4f89e11
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   aliases {
+   mmc1 = 
+   };
+
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus8 _clk _cmd _data_strobe 
_rstnout>;
+};
+
diff --git a/arch/arm/dts/rk3588s-rock-5a.dts b/arch/arm/dts/rk3588s-rock-5a.dts
new file mode 100644
index ..901825514f9d
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a.dts
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include "rk3588s.dtsi"
+
+/ {
+   model = "Radxa ROCK 5 Model A";
+   compatible = "radxa,rock-5a", "rockchip,rk3588s";
+
+   aliases {
+   mmc0 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+};
+
+ {
+   clock_in_out = "output";
+   phy-handle = <_phy1>;
+   phy-mode = "rgmii";
+   pinctrl-0 = <_miim
+_tx_bus2
+_rx_bus2
+_rgmii_clk
+_rgmii_bus>;
+   pinctrl-names = "default";
+   tx_delay = <0x3a>;
+   rx_delay = <0x3e>;
+   status = "okay";
+};
+
+ {
+   rgmii_phy1: ethernet-phy@1 {
+   /* RTL8211F */
+   compatible = "ethernet-phy-id001c.c916";
+   reg = <0x1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rst>;
+   

[PATCH v4 1/2] ARM: dts: rockchip: rk3588: Move bootph-all props to common file

2023-07-04 Thread Eugen Hristev
Move bootph-all prop to common SoC dt file, because they are typically used
by multiple boards.
Unreferenced nodes are removed from the SPL device tree during a
normal build.

Suggested-by: Jonas Karlman 
Signed-off-by: Eugen Hristev 
---

Resent with correct mail addresses

Changes in v4:
- new patch

 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 54 
 arch/arm/dts/rk3588s-u-boot.dtsi| 56 +
 2 files changed, 56 insertions(+), 54 deletions(-)

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index f453aeeaf526..2a80422390e7 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -77,26 +77,6 @@
status = "okay";
 };
 
-_bus8 {
-   bootph-all;
-};
-
-_clk {
-   bootph-all;
-};
-
-_cmd {
-   bootph-all;
-};
-
-_data_strobe {
-   bootph-all;
-};
-
-_rstnout {
-   bootph-all;
-};
-
 _pins {
bootph-all;
 };
@@ -109,8 +89,6 @@
 };
 
  {
-   bootph-all;
-
pcie {
pcie_reset_h: pcie-reset-h {
rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO _pull_none>;
@@ -139,39 +117,11 @@
};
 };
 
-_pull_none {
-   bootph-all;
-};
-
-_pull_up_drv_level_2 {
-   bootph-all;
-};
-
-_pull_up {
-   bootph-all;
-};
-
  {
bus-width = <4>;
status = "okay";
 };
 
-_bus4 {
-   bootph-all;
-};
-
-_clk {
-   bootph-all;
-};
-
-_cmd {
-   bootph-all;
-};
-
-_det {
-   bootph-all;
-};
-
  {
cap-mmc-highspeed;
mmc-ddr-1_8v;
@@ -199,10 +149,6 @@
};
 };
 
-_xfer {
-   bootph-all;
-};
-
 _host0_ehci {
companion = <_host0_ohci>;
phys = <_host>;
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index acb1cfe20063..2d0b0d8ce2fc 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -302,6 +302,42 @@
};
 };
 
+_bus8 {
+   bootph-all;
+};
+
+_clk {
+   bootph-all;
+};
+
+_cmd {
+   bootph-all;
+};
+
+_data_strobe {
+   bootph-all;
+};
+
+_rstnout {
+   bootph-all;
+};
+
+ {
+   bootph-all;
+};
+
+_pull_none {
+   bootph-all;
+};
+
+_pull_up_drv_level_2 {
+   bootph-all;
+};
+
+_pull_up {
+   bootph-all;
+};
+
  {
bootph-all;
status = "okay";
@@ -335,12 +371,32 @@
u-boot,spl-fifo-mode;
 };
 
+_bus4 {
+   bootph-all;
+};
+
+_clk {
+   bootph-all;
+};
+
+_cmd {
+   bootph-all;
+};
+
+_det {
+   bootph-all;
+};
+
  {
clock-frequency = <2400>;
bootph-pre-ram;
status = "okay";
 };
 
+_xfer {
+   bootph-all;
+};
+
  {
bootph-pre-ram;
 };
-- 
2.34.1



[PATCH v4 2/2] board: rockchip: add Radxa ROCK5A Rk3588 board

2023-07-04 Thread Eugen Hristev
ROCK 5A is a Rockchip RK3588S based SBC (Single Board Computer) by Radxa.

There are tree variants depending on the DRAM size : 4G, 8G and 16G.

Specifications:

 Rockchip Rk3588S SoC
 4x ARM Cortex-A76, 4x ARM Cortex-A55
 4/8/16GB memory LPDDR4x
 Mali G610MC4 GPU
 MIPI CSI 2 multiple lanes connector
 4-lane MIPI DSI connector
 Audio – 3.5mm earphone jack
 eMMC module connector
 uSD slot (up to 128GB)
 2x USB 2.0, 2x USB 3.0
 2x micro HDMI 2.1 ports, one up to 8Kp60, the other up to 4Kp60
 Gigabit Ethernet RJ45 with optional PoE support
 40-pin IO header including UART, SPI, I2C and 5V DC power in
 USB PD over USB Type-C
 Size: 85mm x 56mm (Raspberry Pi 4 form factor)

Kernel commits:
d1824cf95799 ("arm64: dts: rockchip: Add rock-5a board")
991f136c9f8d ("arm64: dts: rockchip: Update sdhci alias for rock-5a")
304c8a759953 ("arm64: dts: rockchip: Remove empty line from rock-5a")
cda0c2ea65a0 ("arm64: dts: rockchip: Fix RX delay for ethernet phy on 
rk3588s-rock5a")

Signed-off-by: Eugen Hristev 
---
Changes in v4:
- tweaked the defconfig as reviewed by Jonas
- moved some of bootph-all to rk3588s-u-boot.dtsi
- renamed fdt fixup function
Changes in v3:
- forgot to add defconfig and include file, added now, sorry
Changes in v2:
-fixed wrong Kconfig text (rk3588s instead of rk3588)
-changed doc name (rk3588s instead of rk3588)

 arch/arm/dts/Makefile   |  1 +
 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi| 34 ++
 arch/arm/dts/rk3588s-rock-5a.dts| 73 +
 arch/arm/mach-rockchip/rk3588/Kconfig   | 28 
 board/radxa/rock5a-rk3588s/Kconfig  | 15 +
 board/radxa/rock5a-rk3588s/MAINTAINERS  |  6 ++
 board/radxa/rock5a-rk3588s/Makefile |  6 ++
 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c | 39 +++
 configs/rock5a-rk3588s_defconfig| 72 
 doc/board/rockchip/rockchip.rst |  1 +
 include/configs/rock5a-rk3588s.h| 15 +
 11 files changed, 290 insertions(+)
 create mode 100644 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588s-rock-5a.dts
 create mode 100644 board/radxa/rock5a-rk3588s/Kconfig
 create mode 100644 board/radxa/rock5a-rk3588s/MAINTAINERS
 create mode 100644 board/radxa/rock5a-rk3588s/Makefile
 create mode 100644 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c
 create mode 100644 configs/rock5a-rk3588s_defconfig
 create mode 100644 include/configs/rock5a-rk3588s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..cd9b96c5ba7c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -174,6 +174,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
 dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-evb1-v10.dtb \
+   rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RV1108) += \
diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi 
b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
new file mode 100644
index ..9bb0e4f89e11
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   aliases {
+   mmc1 = 
+   };
+
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus8 _clk _cmd _data_strobe 
_rstnout>;
+};
+
diff --git a/arch/arm/dts/rk3588s-rock-5a.dts b/arch/arm/dts/rk3588s-rock-5a.dts
new file mode 100644
index ..901825514f9d
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a.dts
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include "rk3588s.dtsi"
+
+/ {
+   model = "Radxa ROCK 5 Model A";
+   compatible = "radxa,rock-5a", "rockchip,rk3588s";
+
+   aliases {
+   mmc0 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+};
+
+ {
+   clock_in_out = "output";
+   phy-handle = <_phy1>;
+   phy-mode = "rgmii";
+   pinctrl-0 = <_miim
+_tx_bus2
+_rx_bus2
+_rgmii_clk
+_rgmii_bus>;
+   pinctrl-names = "default";
+   tx_delay = <0x3a>;
+   rx_delay = <0x3e>;
+   status = "okay";
+};
+
+ {
+   rgmii_phy1: ethernet-phy@1 {
+   /* RTL8211F */
+   compatible = "ethernet-phy-id001c.c916";
+   reg = <0x1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rst>;
+   reset-assert-us = <2>;
+ 

[PATCH v4 1/2] ARM: dts: rockchip: rk3588: Move bootph-all props to common file

2023-07-04 Thread Eugen Hristev
Move bootph-all prop to common SoC dt file, because they are typically used
by multiple boards.
Unreferenced nodes are removed from the SPL device tree during a
normal build.

Suggested-by: Jonas Karlman 
Signed-off-by: Eugen Hristev 
---
Changes in v4:
- new patch

 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 54 
 arch/arm/dts/rk3588s-u-boot.dtsi| 56 +
 2 files changed, 56 insertions(+), 54 deletions(-)

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index f453aeeaf526..2a80422390e7 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -77,26 +77,6 @@
status = "okay";
 };
 
-_bus8 {
-   bootph-all;
-};
-
-_clk {
-   bootph-all;
-};
-
-_cmd {
-   bootph-all;
-};
-
-_data_strobe {
-   bootph-all;
-};
-
-_rstnout {
-   bootph-all;
-};
-
 _pins {
bootph-all;
 };
@@ -109,8 +89,6 @@
 };
 
  {
-   bootph-all;
-
pcie {
pcie_reset_h: pcie-reset-h {
rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO _pull_none>;
@@ -139,39 +117,11 @@
};
 };
 
-_pull_none {
-   bootph-all;
-};
-
-_pull_up_drv_level_2 {
-   bootph-all;
-};
-
-_pull_up {
-   bootph-all;
-};
-
  {
bus-width = <4>;
status = "okay";
 };
 
-_bus4 {
-   bootph-all;
-};
-
-_clk {
-   bootph-all;
-};
-
-_cmd {
-   bootph-all;
-};
-
-_det {
-   bootph-all;
-};
-
  {
cap-mmc-highspeed;
mmc-ddr-1_8v;
@@ -199,10 +149,6 @@
};
 };
 
-_xfer {
-   bootph-all;
-};
-
 _host0_ehci {
companion = <_host0_ohci>;
phys = <_host>;
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index acb1cfe20063..2d0b0d8ce2fc 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -302,6 +302,42 @@
};
 };
 
+_bus8 {
+   bootph-all;
+};
+
+_clk {
+   bootph-all;
+};
+
+_cmd {
+   bootph-all;
+};
+
+_data_strobe {
+   bootph-all;
+};
+
+_rstnout {
+   bootph-all;
+};
+
+ {
+   bootph-all;
+};
+
+_pull_none {
+   bootph-all;
+};
+
+_pull_up_drv_level_2 {
+   bootph-all;
+};
+
+_pull_up {
+   bootph-all;
+};
+
  {
bootph-all;
status = "okay";
@@ -335,12 +371,32 @@
u-boot,spl-fifo-mode;
 };
 
+_bus4 {
+   bootph-all;
+};
+
+_clk {
+   bootph-all;
+};
+
+_cmd {
+   bootph-all;
+};
+
+_det {
+   bootph-all;
+};
+
  {
clock-frequency = <2400>;
bootph-pre-ram;
status = "okay";
 };
 
+_xfer {
+   bootph-all;
+};
+
  {
bootph-pre-ram;
 };
-- 
2.34.1



[PATCH 6/6] configs: am64x_evm_a53_defconfig: Enable I2C GPIO drivers

2023-07-04 Thread Roger Quadros
We need the I2C GPIO drivers to detect expansion cards.

Signed-off-by: Roger Quadros 
---
 configs/am64x_evm_a53_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 4589624e96..3a8d2ed3b6 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -105,7 +105,11 @@ CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_PCA953X=y
+CONFIG_SPL_DM_PCA953X=y
 CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_DM_I2C_GPIO=y
 CONFIG_SYS_I2C_OMAP24XX=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
-- 
2.34.1



[PATCH 4/6] arm: dts: k3-am642-r5-evm: Add I2C0 and Card detect GPIOs

2023-07-04 Thread Roger Quadros
Card detect GPIOs are on I2C GPIO Expander on I2C0.
Enable I2C0 and GPIO Expander for r5-evm.

Signed-off-by: Roger Quadros 
---
 arch/arm/dts/k3-am642-r5-evm.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index e870492a69..01b4a61852 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -209,6 +209,13 @@
AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11) 
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>;
};
+
+   main_i2c0_pins_default: main-i2c0-default-pins {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18) 
I2C0_SCL */
+   AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18) 
I2C0_SDA */
+   >;
+   };
 };
 
  {
@@ -267,6 +274,18 @@
 /* EEPROM might be read before SYSFW is available */
 _i2c0 {
/delete-property/ power-domains;
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_pins_default>;
+   clock-frequency = <40>;
+
+   tca9554: gpio@38 {
+/* TCA9554 */
+compatible = "nxp,pca9554";
+reg = <0x38>;
+gpio-controller;
+   #gpio-cells = <2>;
+};
 };
 
  {
-- 
2.34.1



[PATCH 5/6] arm: dts: k3-am642: Add I2C GPIO Expander

2023-07-04 Thread Roger Quadros
The I2C GPIO expander at address 0x38 is used for card detect GPIOs.

Signed-off-by: Roger Quadros 
---
 arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4 
 arch/arm/dts/k3-am642-evm.dts | 8 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi 
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 80c04d0117..f274d11697 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -40,6 +40,10 @@
bootph-pre-ram;
 };
 
+ {
+   bootph-pre-ram;
+};
+
 _uart0 {
bootph-pre-ram;
 };
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 529eb81538..bc7e6f29b0 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -353,6 +353,14 @@
compatible = "atmel,24c1024";
reg = <0x50>;
};
+
+   tca9554: gpio@38 {
+   /* TCA9554 */
+   compatible = "nxp,pca9554";
+   reg = <0x38>;
+   gpio-controller;
+   #gpio-cells = <2>;
+};
 };
 
 _i2c1 {
-- 
2.34.1



[PATCH 3/6] arm: dts: k3-am642: Sync main_i2c0 with kernel

2023-07-04 Thread Roger Quadros
main_i2c0 and pinmux should be in k3-am642-evm.dts.
Also add the I2C EEPROM.

Signed-off-by: Roger Quadros 
---
 arch/arm/dts/k3-am642-evm-u-boot.dtsi | 11 ---
 arch/arm/dts/k3-am642-evm.dts | 20 
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi 
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b0909..80c04d0117 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -34,21 +34,10 @@
 
 _pmx0 {
bootph-pre-ram;
-   main_i2c0_pins_default: main-i2c0-pins-default {
-   bootph-pre-ram;
-   pinctrl-single,pins = <
-   AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18) 
I2C0_SCL */
-   AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18) 
I2C0_SDA */
-   >;
-   };
 };
 
 _i2c0 {
-   status = "okay";
bootph-pre-ram;
-   pinctrl-names = "default";
-   pinctrl-0 = <_i2c0_pins_default>;
-   clock-frequency = <40>;
 };
 
 _uart0 {
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 39feea78a0..529eb81538 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -233,6 +233,13 @@
>;
};
 
+   main_i2c0_pins_default: main-i2c0-default-pins {
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18) 
I2C0_SCL */
+   AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18) 
I2C0_SDA */
+   >;
+   };
+
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18) 
I2C1_SCL */
@@ -335,6 +342,19 @@
status = "reserved";
 };
 
+_i2c0 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_pins_default>;
+   clock-frequency = <40>;
+
+   eeprom@50 {
+   /* AT24CM01 */
+   compatible = "atmel,24c1024";
+   reg = <0x50>;
+   };
+};
+
 _i2c1 {
status = "okay";
pinctrl-names = "default";
-- 
2.34.1



[PATCH 2/6] board: ti: am64x: Add HSE NAND card detection support

2023-07-04 Thread Roger Quadros
Add expansion card detection support. Add NAND card detection
support.

am64-sk EVM doesn't support daughtercards so let's restrict
daughtercard probing to am64-evm.

Signed-off-by: Roger Quadros 
---
 board/ti/am64x/evm.c | 177 +++
 1 file changed, 177 insertions(+)

diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 42795cbd22..a7ddee9d64 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -11,8 +11,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -24,6 +26,17 @@
 #define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
 
+#define AM64X_MAX_DAUGHTER_CARDS   8
+
+/* Daughter card presence detection signals */
+enum {
+   AM64X_EVM_HSE_BRD_DET,
+   AM64X_EVM_BRD_DET_COUNT,
+};
+
+/* Max number of MAC addresses that are parsed/processed per daughter card */
+#define DAUGHTER_CARD_NO_OF_MAC_ADDR   8
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
@@ -219,10 +232,170 @@ static void setup_serial(void)
snprintf(serial_string, sizeof(serial_string), "%016lx", board_serial);
env_set("serial#", serial_string);
 }
+
 #endif
 #endif
 
 #ifdef CONFIG_BOARD_LATE_INIT
+static const char *k3_dtbo_list[AM64X_MAX_DAUGHTER_CARDS] = {NULL};
+
+static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
+{
+   int ret;
+
+   memset(desc, 0, sizeof(*desc));
+
+   ret = dm_gpio_lookup_name(gpio_name, desc);
+   if (ret < 0) {
+   pr_err("Failed to lookup gpio %s: %d\n", gpio_name, ret);
+   return ret;
+   }
+
+   /* Request GPIO, simply re-using the name as label */
+   ret = dm_gpio_request(desc, gpio_name);
+   if (ret < 0) {
+   pr_err("Failed to request gpio %s: %d\n", gpio_name, ret);
+   return ret;
+   }
+
+   return dm_gpio_set_dir_flags(desc, GPIOD_IS_IN);
+}
+
+static int probe_daughtercards(void)
+{
+   struct ti_am6_eeprom ep;
+   struct gpio_desc board_det_gpios[AM64X_EVM_BRD_DET_COUNT];
+   char mac_addr[DAUGHTER_CARD_NO_OF_MAC_ADDR][TI_EEPROM_HDR_ETH_ALEN];
+   u8 mac_addr_cnt;
+   char name_overlays[1024] = { 0 };
+   int i, nb_dtbos = 0;
+   int ret;
+
+   /*
+* Daughter card presence detection signal name to GPIO (via I2C I/O
+* expander @ address 0x38) name and EEPROM I2C address mapping.
+*/
+   const struct {
+   char *gpio_name;
+   u8 i2c_addr;
+   } slot_map[AM64X_EVM_BRD_DET_COUNT] = {
+   { "gpio@38_0", 0x52, }, /* AM64X_EVM_HSE_BRD_DET */
+   };
+
+   /* Declaration of daughtercards to probe */
+   const struct {
+   u8 slot_index;  /* Slot the card is installed */
+   char *card_name;/* EEPROM-programmed card name */
+   char *dtbo_name;/* Device tree overlay to apply */
+   u8 eth_offset;  /* ethXaddr MAC address index offset */
+   } cards[] = {
+   {
+   AM64X_EVM_HSE_BRD_DET,
+   "TMDS64DC02EVM",
+   "k3-am642-evm-nand.dtbo",
+   0,
+   },
+   };
+
+   /*
+* Initialize GPIO used for daughtercard slot presence detection and
+* keep the resulting handles in local array for easier access.
+*/
+   for (i = 0; i < AM64X_EVM_BRD_DET_COUNT; i++) {
+   ret = init_daughtercard_det_gpio(slot_map[i].gpio_name,
+_det_gpios[i]);
+   if (ret < 0)
+   return ret;
+   }
+
+   memset(k3_dtbo_list, 0, sizeof(k3_dtbo_list));
+   for (i = 0; i < ARRAY_SIZE(cards); i++) {
+   /* Obtain card-specific slot index and associated I2C address */
+   u8 slot_index = cards[i].slot_index;
+   u8 i2c_addr = slot_map[slot_index].i2c_addr;
+   const char *dtboname;
+
+   /*
+* The presence detection signal is active-low, hence skip
+* over this card slot if anything other than 0 is returned.
+*/
+   ret = dm_gpio_get_value(_det_gpios[slot_index]);
+   if (ret < 0)
+   return ret;
+   else if (ret)
+   continue;
+
+   /* Get and parse the daughter card EEPROM record */
+   ret = ti_i2c_eeprom_am6_get(CONFIG_EEPROM_BUS_ADDRESS, i2c_addr,
+   ,
+   (char **)mac_addr,
+   DAUGHTER_CARD_NO_OF_MAC_ADDR,
+   _addr_cnt);
+   if (ret) {
+   pr_err("Reading daughtercard EEPROM at 

[PATCH 1/6] board: ti: am64x: Recognize AM64-HSEVM

2023-07-04 Thread Roger Quadros
use "am64x_evm" board name in environment for both AM64-GPEVM and
AM64-HSEVM.

Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header"

Signed-off-by: Roger Quadros 
---
 board/ti/am64x/evm.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 96f4e3013a..42795cbd22 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,7 +18,8 @@
 
 #include "../common/board_detect.h"
 
-#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
+#define board_is_am64x_evm()   (board_ti_k3_is("AM64-GPEVM") || \
+   board_ti_k3_is("AM64-HSEVM"))
 
 #define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
@@ -57,7 +58,7 @@ int board_fit_config_name_match(const char *name)
 {
bool eeprom_read = board_ti_was_eeprom_read();
 
-   if (!eeprom_read || board_is_am64x_gpevm()) {
+   if (!eeprom_read || board_is_am64x_evm()) {
if (!strcmp(name, "k3-am642-r5-evm") || !strcmp(name, 
"k3-am642-evm"))
return 0;
} else if (board_is_am64x_skevm()) {
@@ -182,13 +183,13 @@ int checkboard(void)
 #ifdef CONFIG_BOARD_LATE_INIT
 static void setup_board_eeprom_env(void)
 {
-   char *name = "am64x_gpevm";
+   char *name = "am64x_evm";
 
if (do_board_detect())
goto invalid_eeprom;
 
-   if (board_is_am64x_gpevm())
-   name = "am64x_gpevm";
+   if (board_is_am64x_evm())
+   name = "am64x_evm";
else if (board_is_am64x_skevm())
name = "am64x_skevm";
else
-- 
2.34.1



[PATCH 0/6] ti: k3-am642: Add daughtercard support

2023-07-04 Thread Roger Quadros
Hi,

This series adds daughtercard detection support for am642-evm.

NAND card support is added.

cheers,
-roger

Roger Quadros (6):
  board: ti: am64x: Recognize AM64-HSEVM
  board: ti: am64x: Add HSE NAND card detection support
  arm: dts: k3-am642: Sync main_i2c0 with kernel
  arm: dts: k3-am642-r5-evm: Add I2C0 and Card detect GPIOs
  arm: dts: k3-am642: Add I2C GPIO Expander
  configs: am64x_evm_a53_defconfig: Enable I2C GPIO drivers

 arch/arm/dts/k3-am642-evm-u-boot.dtsi |  15 +-
 arch/arm/dts/k3-am642-evm.dts |  28 
 arch/arm/dts/k3-am642-r5-evm.dts  |  19 +++
 board/ti/am64x/evm.c  | 188 +-
 configs/am64x_evm_a53_defconfig   |   4 +
 5 files changed, 238 insertions(+), 16 deletions(-)

-- 
2.34.1



Re: [PATCH v2] board: stm32mp1: add splash screen on dk2

2023-07-04 Thread Grzegorz Szymaszek
On Tue, Jul 04, 2023 at 07:31:21PM +0200, Dario Binacchi wrote:
> Display the STMicroelectronics logo.
> 
> Signed-off-by: Dario Binacchi 

Reviewed-by: Grzegorz Szymaszek 


signature.asc
Description: PGP signature


[PATCH v2] board: stm32mp1: add splash screen on dk2

2023-07-04 Thread Dario Binacchi
Display the STMicroelectronics logo.

Signed-off-by: Dario Binacchi 


---

Changes in v2:
- move "splash.h" and "st_logo_data.h" headers before "syscon.h" in order
  to keep includes sorted alphabetically.
- remove "logo" variable and pass 
"(ulong)stmicroelectronics_uboot_logo_8bit_rle"
  directly to the bmp_display() function.

 board/st/stm32mp1/stm32mp1.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 1a1b1844c8c0..ebd3948d519c 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -31,8 +31,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -684,6 +687,14 @@ int board_init(void)
fw_images[0].fw_name = u"STM32MP-FIP";
fw_images[0].image_index = 1;
 #endif
+
+   if (IS_ENABLED(CONFIG_CMD_BMP)) {
+   if (board_is_stm32mp15x_dk2()) {
+   
bmp_display((ulong)stmicroelectronics_uboot_logo_8bit_rle,
+   BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
+   }
+   }
+
return 0;
 }
 
-- 
2.32.0



Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Fabio Estevam

On 04/07/2023 14:04, Francesco Dolcini wrote:


The boards that do not check the return value might start to behave
wrongly without an obvious error to help the debugging.


Yes, the current implementation of fdt_status_disabled() is fragile, but
there's not so much we can do for the upcoming 2023.07.

I can try to prepare a patch to improve it after 2023.07 is out next 
week.


[PATCH v2] colibri-imx7: Call fdt_increase_size()

2023-07-04 Thread Fabio Estevam
From: Fabio Estevam 

For changing the USB OTG node status from "okay" to "disabled" more
space is needed, so call fdt_increase_size() to avoid the following
error:

```
 U-Boot 2023.07-rc5-0.0.0-devel+git.580eb31199be (Jun 27 2023 - 13:39:58 +)
 CPU:   Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
 CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
 Reset cause: POR
 DRAM:  initcall sequence 8786eafc failed at call 8781b351 (err=-3)
 ### ERROR ### Please RESET the board ###
```

Ideally, fdt_status_disabled() should call fdt_increase_size() internally,
so that there would be no need for manually calling it in board code.

Do it manually for now to fix the regression.

Based on the code from board/CZ.NIC/turris_omnia/turris_omnia.c.

Reported-by: Francesco Dolcini 
Signed-off-by: Fabio Estevam 
Reviewed-by: Francesco Dolcini 
Tested-by: Francesco Dolcini  # Toradex Colibri 
iMX7S
---
Changes since v1:
- Fix indentation. (Francesco)

 board/toradex/colibri_imx7/colibri_imx7.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 3e79ab93a982..119e67b47f79 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -311,10 +311,23 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 #ifdef CONFIG_USB_EHCI_MX7
 int board_fix_fdt(void *rw_fdt_blob)
 {
+   int ret;
+
/* i.MX 7Solo has only one single USB OTG1 but no USB host port */
if (is_cpu_type(MXC_CPU_MX7S)) {
int offset = fdt_path_offset(rw_fdt_blob, 
"/soc/bus@3080/usb@30b2");
 
+   /*
+* We're changing from status = "okay" to status = "disabled".
+* In this case we'll need more space, so increase the size
+* a little bit.
+*/
+   ret = fdt_increase_size(rw_fdt_blob, 32);
+   if (ret < 0) {
+   printf("Cannot increase FDT size: %d\n", ret);
+   return ret;
+   }
+
return fdt_status_disabled(rw_fdt_blob, offset);
}
 
-- 
2.34.1



Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Francesco Dolcini
On Tue, Jul 04, 2023 at 12:57:34PM -0300, Fabio Estevam wrote:
> On Tue, Jul 4, 2023 at 12:12 PM Francesco Dolcini  
> wrote:
> 
> > Now that the situation is pretty much clear I am not overly concerned for
> > colibri-imx7s.
> >
> > Do we consider this something to be worried about for other boards?
> 
> There are only three boards that check the return value from

The boards that do not check the return value might start to behave
wrongly without an obvious error to help the debugging.

Francesco



Re: [PATCH] colibri-imx7: Call fdt_increase_size()

2023-07-04 Thread Francesco Dolcini
On Tue, Jul 04, 2023 at 01:10:03PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> For changing the USB OTG node status from "okay" to "disabled" more
> space is needed, so call fdt_increase_size() to avoid the following
> error:
> 
> ```
>  U-Boot 2023.07-rc5-0.0.0-devel+git.580eb31199be (Jun 27 2023 - 13:39:58 
> +)
>  CPU:   Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
>  CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
>  Reset cause: POR
>  DRAM:  initcall sequence 8786eafc failed at call 8781b351 (err=-3)
>  ### ERROR ### Please RESET the board ###
> ```
> 
> Ideally, fdt_status_disabled() should call fdt_increase_size() internally,
> so that there would be no need for manually calling it in board code.
> 
> Do it manually for now to fix the regression.
> 
> Based on the code from board/CZ.NIC/turris_omnia/turris_omnia.c.
> 
> Reported-by: Francesco Dolcini 
> Signed-off-by: Fabio Estevam 
> ---
>  board/toradex/colibri_imx7/colibri_imx7.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
> b/board/toradex/colibri_imx7/colibri_imx7.c
> index 3e79ab93a982..78be17c3b550 100644
> --- a/board/toradex/colibri_imx7/colibri_imx7.c
> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
> @@ -311,10 +311,22 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>  #ifdef CONFIG_USB_EHCI_MX7
>  int board_fix_fdt(void *rw_fdt_blob)
>  {
> + int ret;
> +
>   /* i.MX 7Solo has only one single USB OTG1 but no USB host port */
>   if (is_cpu_type(MXC_CPU_MX7S)) {
>   int offset = fdt_path_offset(rw_fdt_blob, 
> "/soc/bus@3080/usb@30b2");
>  
> + /*
> +  * We're changing from status = "okay" to status = "disabled".
> +  * In this case we'll need more space, so increase the size
> +  * a little bit.
> +  */
> + ret = fdt_increase_size(rw_fdt_blob, 32);
> + if (ret < 0) {
> + printf("Cannot increase FDT size: %d\n", ret);
> + return ret;
> + }

Thanks for the patch!

You miss one level of indentation here, with this fixed
Reviewed-by: Francesco Dolcini 

And, in any case,
Tested-by: Francesco Dolcini  # Toradex Colibri 
iMX7S

Francesco



[PATCH] colibri-imx7: Call fdt_increase_size()

2023-07-04 Thread Fabio Estevam
From: Fabio Estevam 

For changing the USB OTG node status from "okay" to "disabled" more
space is needed, so call fdt_increase_size() to avoid the following
error:

```
 U-Boot 2023.07-rc5-0.0.0-devel+git.580eb31199be (Jun 27 2023 - 13:39:58 +)
 CPU:   Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
 CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
 Reset cause: POR
 DRAM:  initcall sequence 8786eafc failed at call 8781b351 (err=-3)
 ### ERROR ### Please RESET the board ###
```

Ideally, fdt_status_disabled() should call fdt_increase_size() internally,
so that there would be no need for manually calling it in board code.

Do it manually for now to fix the regression.

Based on the code from board/CZ.NIC/turris_omnia/turris_omnia.c.

Reported-by: Francesco Dolcini 
Signed-off-by: Fabio Estevam 
---
 board/toradex/colibri_imx7/colibri_imx7.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 3e79ab93a982..78be17c3b550 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -311,10 +311,22 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 #ifdef CONFIG_USB_EHCI_MX7
 int board_fix_fdt(void *rw_fdt_blob)
 {
+   int ret;
+
/* i.MX 7Solo has only one single USB OTG1 but no USB host port */
if (is_cpu_type(MXC_CPU_MX7S)) {
int offset = fdt_path_offset(rw_fdt_blob, 
"/soc/bus@3080/usb@30b2");
 
+   /*
+* We're changing from status = "okay" to status = "disabled".
+* In this case we'll need more space, so increase the size
+* a little bit.
+*/
+   ret = fdt_increase_size(rw_fdt_blob, 32);
+   if (ret < 0) {
+   printf("Cannot increase FDT size: %d\n", ret);
+   return ret;
+   }
return fdt_status_disabled(rw_fdt_blob, offset);
}
 
-- 
2.34.1



Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Fabio Estevam
On Tue, Jul 4, 2023 at 12:12 PM Francesco Dolcini  wrote:

> Now that the situation is pretty much clear I am not overly concerned for
> colibri-imx7s.
>
> Do we consider this something to be worried about for other boards?

There are only three boards that check the return value from
fdt_status_disabled():

- board/toradex/colibri_imx7/colibri_imx7.c
- board/gdsys/a38x/dt_helpers.c
- board/CZ.NIC/turris_omnia/turris_omnia.c

As of today, only turris_omnia calls the fdt_increase_size() prior to
fdt_status_disabled().


Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Tom Rini
On Tue, Jul 04, 2023 at 05:23:03PM +0200, Francesco Dolcini wrote:
> On Tue, Jul 04, 2023 at 11:14:57AM -0400, Tom Rini wrote:
> > On Tue, Jul 04, 2023 at 05:12:42PM +0200, Francesco Dolcini wrote:
> > > On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> > > > Then for the next cycle, we should plan on adding this
> > > > fdt_increase_size() into the common fdt_status_disabled().
> > > > 
> > > > Does it work?
> > > 
> > > Now that the situation is pretty much clear I am not overly concerned for
> > > colibri-imx7s.
> > > 
> > > Do we consider this something to be worried about for other boards?
> > 
> > The cases calling fdt_status_disabled itself are small enough that I
> > think a quick audit isn't unreasonable (and PowerPC should probably
> > mirror the kernel and pass -p 0x1000 in DTC_FLAGS so it becomes a
> > non-issue).
> 
> Do we expect this to not affect fdt_setprop() or other fdt_*() APIs?
> fdt_increase_size() seems not to be used most of the time, unless I am
> missing something here.

It depends on the case. For example, fdt_node_set_part_info is
big/complex enough that it does call fdt_increase_size (which is not
cheap) when there's no space.  Other cases already do check for no space
and grow+retry.  And then the general answer is that if you're expecting
needing to make "big" changes to the dtb you should pad it to start with
as that's a free operation at run time.

-- 
Tom


signature.asc
Description: PGP signature


Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Francesco Dolcini
On Tue, Jul 04, 2023 at 11:14:57AM -0400, Tom Rini wrote:
> On Tue, Jul 04, 2023 at 05:12:42PM +0200, Francesco Dolcini wrote:
> > On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> > > Then for the next cycle, we should plan on adding this
> > > fdt_increase_size() into the common fdt_status_disabled().
> > > 
> > > Does it work?
> > 
> > Now that the situation is pretty much clear I am not overly concerned for
> > colibri-imx7s.
> > 
> > Do we consider this something to be worried about for other boards?
> 
> The cases calling fdt_status_disabled itself are small enough that I
> think a quick audit isn't unreasonable (and PowerPC should probably
> mirror the kernel and pass -p 0x1000 in DTC_FLAGS so it becomes a
> non-issue).

Do we expect this to not affect fdt_setprop() or other fdt_*() APIs?
fdt_increase_size() seems not to be used most of the time, unless I am
missing something here.

Francesco



Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Francesco Dolcini
On Tue, Jul 04, 2023 at 11:09:06AM -0400, Tom Rini wrote:
> On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> > Then for the next cycle, we should plan on adding this
> > fdt_increase_size() into the common fdt_status_disabled().
> 
> I'm a little leary of generic changes here having an unexpected size /
> performance impact.  The API specifically does not "just" handle this
> case like it does for some others. We should update the docs around
> fdt_set_node_status and fdt_status_disabled to reference the return
> codes of fdt_setprop_string itself and check for anyone else that hasn't
> been considering this possible failure case.

Maybe we can just add a new additional small wrapper that does the
fdt_increase_size() if required? This is a generic need, not something
every board should implement on its own.

Francesco



Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Tom Rini
On Tue, Jul 04, 2023 at 05:12:42PM +0200, Francesco Dolcini wrote:
> On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> > Then for the next cycle, we should plan on adding this
> > fdt_increase_size() into the common fdt_status_disabled().
> > 
> > Does it work?
> 
> Now that the situation is pretty much clear I am not overly concerned for
> colibri-imx7s.
> 
> Do we consider this something to be worried about for other boards?

The cases calling fdt_status_disabled itself are small enough that I
think a quick audit isn't unreasonable (and PowerPC should probably
mirror the kernel and pass -p 0x1000 in DTC_FLAGS so it becomes a
non-issue).

-- 
Tom


signature.asc
Description: PGP signature


Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Francesco Dolcini
On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> Then for the next cycle, we should plan on adding this
> fdt_increase_size() into the common fdt_status_disabled().
> 
> Does it work?

Now that the situation is pretty much clear I am not overly concerned for
colibri-imx7s.

Do we consider this something to be worried about for other boards?

Francesco



Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Tom Rini
On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> Hi Francesco,
> 
> On Mon, Jul 3, 2023 at 5:49 PM Francesco Dolcini  wrote:
> 
> > If I do this small partial revert
> >
> > --- a/arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi
> > +++ b/arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi
> > @@ -15,7 +15,8 @@
> > pinctrl-0 = <_lcdif_dat
> >  _lcdif_ctrl>;
> > display = <>;
> > -   u-boot,dm-pre-reloc;
> > +   bootph-all;
> 
> I managed to reproduce the behavior on a imx7d-sabresd by doing:
> 
> --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
> +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> @@ -289,6 +290,20 @@ int power_init_board(void)
>  }
>  #endif
> 
> +int board_fix_fdt(void *rw_fdt_blob)
> +{
> +   int ret;
> +
> +   int offset = fdt_path_offset(rw_fdt_blob,
> "/soc/bus@3080/usb@30b2");
> +
> +   ret = fdt_status_disabled(rw_fdt_blob, offset);
> +
> +   printf(" offset is 0x%x\n", offset);
> +   printf(" ret is %d\n", ret);
> +
> +   return 0;
> +}
> +
>  int board_late_init(void)
> 
> --- a/configs/mx7dsabresd_defconfig
> +++ b/configs/mx7dsabresd_defconfig
> @@ -86,3 +86,4 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
>  CONFIG_CI_UDC=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_OF_BOARD_FIXUP=y
> 
> With top of tree U-Boot it fails with:
> 
>  offset is 0x7ba4
>  ret is -3
> 
> If u-boot.dtsi gets smaller, for example, by reverting 0aea5dda2928
> then it succeeds:
> 
>  offset is 0x7988
>  ret is 0
> 
> > fdt_status_disabled() returns 0 again.
> >
> > With the current master, fdt_status_disabled() returns -3,
> > -FDT_ERR_NOSPACE, and I assume I could just change my code to call
> > fdt_increase_size() and call it done.
> >
> > However, what the reason for this different behavior triggered by that
> > change in the *-u-boot.dtsi ? Is this expected?
> >
> > From a quick check multiple place in the code just disable/enable nodes
> > or set properties without taking care of this, are those going to be
> > affected by that commit that created the regression? Are those all
> > buggy?
> >
> > $ git grep fdt_setprop |wc -l
> > 461
> >
> > We have some helper around, for example
> > arch/arm/mach-imx/imx8/fdt.c:disable_fdt_node(), but this is for example
> > just specific on that file.
> 
> Here is my suggestion: let's increase the fdt size locally on your
> board for now, just like turris_omnia.c:
> 
> --- a/board/toradex/colibri_imx7/colibri_imx7.c
> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
> @@ -315,6 +315,15 @@ int board_fix_fdt(void *rw_fdt_blob)
> if (is_cpu_type(MXC_CPU_MX7S)) {
> int offset = fdt_path_offset(rw_fdt_blob,
> "/soc/bus@3080/usb@30b2");
> 
> +   /*
> +* We're either adding status = "disabled" property, or changing
> +* status = "okay" to status = "disabled". In both cases we'll need 
> more
> +* space. Increase the size a little.
> +*/
> +   if (fdt_increase_size(rw_fdt_blob, 32) < 0) {
> +   printf("Cannot increase FDT size.\n");
> +   return -ENOMEM;
> +   }
> return fdt_status_disabled(rw_fdt_blob, offset);
> }
> 
> Then for the next cycle, we should plan on adding this
> fdt_increase_size() into the common fdt_status_disabled().

I'm a little leary of generic changes here having an unexpected size /
performance impact.  The API specifically does not "just" handle this
case like it does for some others. We should update the docs around
fdt_set_node_status and fdt_status_disabled to reference the return
codes of fdt_setprop_string itself and check for anyone else that hasn't
been considering this possible failure case.

-- 
Tom


signature.asc
Description: PGP signature


Re: v2023.07-rc5 regression: Image overlaps SPL

2023-07-04 Thread Fabio Estevam
Hi Francesco,

On Mon, Jul 3, 2023 at 5:49 PM Francesco Dolcini  wrote:

> If I do this small partial revert
>
> --- a/arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi
> +++ b/arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi
> @@ -15,7 +15,8 @@
> pinctrl-0 = <_lcdif_dat
>  _lcdif_ctrl>;
> display = <>;
> -   u-boot,dm-pre-reloc;
> +   bootph-all;

I managed to reproduce the behavior on a imx7d-sabresd by doing:

--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;

@@ -289,6 +290,20 @@ int power_init_board(void)
 }
 #endif

+int board_fix_fdt(void *rw_fdt_blob)
+{
+   int ret;
+
+   int offset = fdt_path_offset(rw_fdt_blob,
"/soc/bus@3080/usb@30b2");
+
+   ret = fdt_status_disabled(rw_fdt_blob, offset);
+
+   printf(" offset is 0x%x\n", offset);
+   printf(" ret is %d\n", ret);
+
+   return 0;
+}
+
 int board_late_init(void)

--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -86,3 +86,4 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_ERRNO_STR=y
+CONFIG_OF_BOARD_FIXUP=y

With top of tree U-Boot it fails with:

 offset is 0x7ba4
 ret is -3

If u-boot.dtsi gets smaller, for example, by reverting 0aea5dda2928
then it succeeds:

 offset is 0x7988
 ret is 0

> fdt_status_disabled() returns 0 again.
>
> With the current master, fdt_status_disabled() returns -3,
> -FDT_ERR_NOSPACE, and I assume I could just change my code to call
> fdt_increase_size() and call it done.
>
> However, what the reason for this different behavior triggered by that
> change in the *-u-boot.dtsi ? Is this expected?
>
> From a quick check multiple place in the code just disable/enable nodes
> or set properties without taking care of this, are those going to be
> affected by that commit that created the regression? Are those all
> buggy?
>
> $ git grep fdt_setprop |wc -l
> 461
>
> We have some helper around, for example
> arch/arm/mach-imx/imx8/fdt.c:disable_fdt_node(), but this is for example
> just specific on that file.

Here is my suggestion: let's increase the fdt size locally on your
board for now, just like turris_omnia.c:

--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -315,6 +315,15 @@ int board_fix_fdt(void *rw_fdt_blob)
if (is_cpu_type(MXC_CPU_MX7S)) {
int offset = fdt_path_offset(rw_fdt_blob,
"/soc/bus@3080/usb@30b2");

+   /*
+* We're either adding status = "disabled" property, or changing
+* status = "okay" to status = "disabled". In both cases we'll need more
+* space. Increase the size a little.
+*/
+   if (fdt_increase_size(rw_fdt_blob, 32) < 0) {
+   printf("Cannot increase FDT size.\n");
+   return -ENOMEM;
+   }
return fdt_status_disabled(rw_fdt_blob, offset);
}

Then for the next cycle, we should plan on adding this
fdt_increase_size() into the common fdt_status_disabled().

Does it work?


Re: [PATCH 2/2] mxs: Don't enable 4P2 reg if MXS is powered only from DCDC_BATT

2023-07-04 Thread Cody Green
On Tue, Jul 4, 2023 at 9:19 AM Lukasz Majewski  wrote:
Hi Lukasz,
>
> Hi Marek, Cody,
>
> > On 7/3/23 18:33, Cody Green wrote:
> > > 'mxs_power_enable_4p2()' function call was added to
> > > 'mxs_batt_boot()' in 'commit a0f97610757d' to enable DCDC converter
> > > when board is powered from 5V and has detected sufficient battery
> > > voltage. This involves enabling 4P2 regulator and there is a code
> > > in 'mxs_power_enable_4p2()' that disables VDDIO, VDDA, VDDD outputs
> > > of the DCDC converter and enables BO for each power rail:
> > >
> > >    setbits_le32(_regs->hw_power_vddioctrl,
> > >      POWER_VDDIOCTRL_DISABLE_FET | POWER_VDDIOCTRL_PWDN_BRNOUT);
> > >
> > > There is no issue if the MXS is powered from the 5V source and
> > > linear regulators are supplying power to the VDDIO, VDDA, VDDD
> > > rails. However, if the MXS is powered only from the DCDC_BATT
> > > without 5V, disabling the DCDC converter outputs causes VDDIO,
> > > VDDA, VDDD rails to lose power.
>
> I think that I've also hit the same issue with the XEA board
> (upstreamed).
>
> I've prepared a set of patches:
> https://patchwork.ozlabs.org/project/uboot/patch/20230509143243.1523791-5-lu...@denx.de/
>
> to fix this problem.
>
> Those patches are now for some time on the mailing list for review - and
> I do hope that Stefano will pull them with next PR for u-boot-imx
> repository.
>
> > >
> > > The proposed solution is not to call the 'mxs_power_enable_4p2()'
> > > function if the MXS is powered only by the DCDC_BATT, because there
> > > is no reason to enable 4P2 regulator in this case.
>
> I think this patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20230509143243.1523791-3-lu...@denx.de/
>
> address exactly this issue.

Yes, your patch [3/5] addresses the issue perfectly!
I was considering to add the Kconfig option, but decided against it,
as I thought nobody else is running the MXS only from DCDC_BATT without 5V.
In my opinion Kconfig option is better solution than my patch and
I am happy to add 'Tested-by' tag to your patch [3/5], if you wish.

>
> > > Also 5V brownout
> > > should not be enabled in 'mxs_power_init()' and linear regulator
> > > checks should be disabled in 'mxs_power_set_vddx()'.
> > >
>
> I've also added some code to limit the VDD5V current when we intend to
> use DCDC_BATT input as the _primary_ source of power (AN4199 advises
> this one for industrial applications as the most reliable).
>

I checked other patches in your set and as far as I can tell
the rest of them apply if the board is powered from both 
DCDC_BATT and 5V source. This is all good stuff, but what shall
we do about enabling 5V brownout:

writel(POWER_5VCTRL_PWDN_5VBRNOUT, _regs->hw_power_5vctrl_set);
in 'void mxs_power_init()'?

Would you consider using the new 'MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR'
option to not enable 5V brownout as well? e.g.

if (CONFIG_IS_ENABLED(MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR))
writel(POWER_5VCTRL_PWDN_5VBRNOUT, 
_regs->hw_power_5vctrl_set);

My reasoning is the 4P2 regulator would be disabled only in the
scenario if the board is running without 5V hence there is no need
for a 5V brownout.

There is a slightly different problem with:

if (cfg->powered_by_linreg)
powered_by_linreg = cfg->powered_by_linreg();
in 'mxs_power_set_vddx()'.

I noticed that function 'mxs_get_vddd_power_source_off()'
returns '1' (i.e. powered_by_linreg) because of the following code:

if (!(tmp & POWER_VDDDCTRL_ENABLE_LINREG)) {
if ((tmp & POWER_VDDDCTRL_LINREG_OFFSET_MASK) ==
POWER_VDDDCTRL_LINREG_OFFSET_1STEPS_BELOW) {
return 1;
}
}

I am not sure why this piece of code even exists, but rather than 
risking to brake something by removing it, I decided that we can simply
disable calling 'mxs_get_vddd_power_source_off()' if the board is
powered from DCDC_BATT only. So would you consider the following as well?

if (CONFIG_IS_ENABLED(MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR))
if (cfg->powered_by_linreg)
powered_by_linreg = cfg->powered_by_linreg();

>
> > > Signed-off-by: Cody Green 
> > > Cc: Stefano Babic 
> > > Cc: Marek Vasut 
> > > Cc: Fabio Estevam 
> > > ---
> > >   arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 7 +++
> > >   1 file changed, 7 insertions(+)
> > >
> > > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> > > b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index
> > > 33b76533e4..72172705f2 100644 ---
> > > a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++
> > > b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -752,7 +752,9 @@
> > > static void mxs_batt_boot(void) POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK,
> > >             0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
> > >   
> > > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > >     mxs_power_enable_4p2();
> > > +#endif
> > >   }
> > >   
> > >   /**
> > > @@ -1137,8 

[PATCH v2 1/2] mxs: Fix VDDx brownout interrupt disable/enable

2023-07-04 Thread Cody Green
Incorrect registers HW_POWER_VDDIOCTRL, HW_POWER_VDDACTRL
and HW_POWER_VDDDCTRL are used in the current code to disable/enable
brownout interrupts in 'mxs_power_set_vddx()'.
Change register to HW_POWER_CTRL which contains brownout interrupt
enable bits ENIRQ_VDDIO_BO, ENIRQ_VDDA_BO and ENIRQ_VDDD_BO.

Signed-off-by: Cody Green 
Cc: Stefano Babic 
Cc: Marek Vasut 
Cc: Fabio Estevam 
Cc: Lukasz Majewski 
---
Changes for v2:
- Commit message reworded to be more specific.

 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index c33170f06d..33b76533e4 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -1142,8 +1142,9 @@ static void mxs_power_set_vddx(const struct mxs_vddx_cfg 
*cfg,
 
if (adjust_up && cfg->bo_irq) {
if (powered_by_linreg) {
-   bo_int = readl(cfg->reg);
-   clrbits_le32(cfg->reg, cfg->bo_enirq);
+   bo_int = readl(_regs->hw_power_ctrl);
+   clrbits_le32(_regs->hw_power_ctrl,
+   cfg->bo_enirq);
}
setbits_le32(cfg->reg, cfg->bo_offset_mask);
}
@@ -1185,7 +1186,8 @@ static void mxs_power_set_vddx(const struct mxs_vddx_cfg 
*cfg,
if (adjust_up && powered_by_linreg) {
writel(cfg->bo_irq, _regs->hw_power_ctrl_clr);
if (bo_int & cfg->bo_enirq)
-   setbits_le32(cfg->reg, cfg->bo_enirq);
+   setbits_le32(_regs->hw_power_ctrl,
+   cfg->bo_enirq);
}
 
clrsetbits_le32(cfg->reg, cfg->bo_offset_mask,
-- 
2.25.1



Re: [PATCH 1/2] mxs: Fix VDDx brownout interrupt disable/enable

2023-07-04 Thread Cody Green
On Mon, Jul 3, 2023 at 5:40 PM Marek Vasut  wrote:
>
> On 7/3/23 18:33, Cody Green wrote:
> > HW_POWER_CTRL register contains brownout interrupt
> > enable bits ENIRQ_VDDIO_BO, ENIRQ_VDDA_BO and
> > ENIRQ_VDDD_BO.
>
> So what does this patch do (that is missing in the commit message) ?

There are incorrect registers HW_POWER_VDDIOCTRL, HW_POWER_VDDACTRL
and HW_POWER_VDDDCTRL used in the current code to disable/enable
brownout interrupts in 'mxs_power_set_vddx()'. This patch ensures the
correct register HW_POWER_CTRL is used.
Sorry for the unspecific commit message, I will amend the patch.


sipeed maix bit resets every 90 seconds with watchdog enabled

2023-07-04 Thread Jaap Aart

Dear sean, and others,

I encountered a small problem running linux on the sipeed maix bit from 
u-boot.
Every 90 seconds (exactly) after boot it resets, if booted into linux, 
unless I disable the watchdog.
This has occurred since this feature was enabled 
(e3282b1bbae4e8558c2b85bf27560d12358ed25f)


Although I do not completely understand the watchdog features, it notes 
it is set to 60 seconds,

and I am convinced that the point is not to reset every X seconds.
Especially because this is enabled by default.

I have not really found a good workaround besides disabling the WDT at 
runtime which is cumbersome.


Is this expected behavior? And if so, how do I disable this feature at 
compile time?


Kind regards,

Jaap Aarts




[PATCH 2/2] mxs: Don't enable 4P2 reg if MXS is powered only from DCDC_BATT

2023-07-04 Thread Cody Green
'mxs_power_enable_4p2()' function call was added to 'mxs_batt_boot()'
in 'commit a0f97610757d' to enable DCDC converter when board is powered
from 5V and has detected sufficient battery voltage.
This involves enabling 4P2 regulator and there is a code
in 'mxs_power_enable_4p2()' that disables VDDIO, VDDA, VDDD outputs of
the DCDC converter and enables BO for each power rail:

  setbits_le32(_regs->hw_power_vddioctrl,
POWER_VDDIOCTRL_DISABLE_FET | POWER_VDDIOCTRL_PWDN_BRNOUT);

There is no issue if the MXS is powered from the 5V source and linear
regulators are supplying power to the VDDIO, VDDA, VDDD rails.
However, if the MXS is powered only from the DCDC_BATT without 5V,
disabling the DCDC converter outputs causes VDDIO, VDDA, VDDD rails to
lose power.

The proposed solution is not to call the 'mxs_power_enable_4p2()'
function if the MXS is powered only by the DCDC_BATT, because there is
no reason to enable 4P2 regulator in this case. Also 5V brownout should
not be enabled in 'mxs_power_init()' and linear regulator checks should
be disabled in 'mxs_power_set_vddx()'.

Signed-off-by: Cody Green 
Cc: Stefano Babic 
Cc: Marek Vasut 
Cc: Fabio Estevam 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 33b76533e4..72172705f2 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -752,7 +752,9 @@ static void mxs_batt_boot(void)
POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK,
0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
 
+#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
mxs_power_enable_4p2();
+#endif
 }
 
 /**
@@ -1137,8 +1139,11 @@ static void mxs_power_set_vddx(const struct mxs_vddx_cfg 
*cfg,
cur_target += cfg->lowest_mV;
 
adjust_up = new_target > cur_target;
+
+#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
if (cfg->powered_by_linreg)
powered_by_linreg = cfg->powered_by_linreg();
+#endif
 
if (adjust_up && cfg->bo_irq) {
if (powered_by_linreg) {
@@ -1269,7 +1274,9 @@ void mxs_power_init(void)
POWER_CTRL_VBUS_VALID_IRQ | POWER_CTRL_BATT_BO_IRQ |
POWER_CTRL_DCDC4P2_BO_IRQ, _regs->hw_power_ctrl_clr);
 
+#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
writel(POWER_5VCTRL_PWDN_5VBRNOUT, _regs->hw_power_5vctrl_set);
+#endif
 
early_delay(1000);
 }
-- 
2.25.1



[PATCH 1/2] mxs: Fix VDDx brownout interrupt disable/enable

2023-07-04 Thread Cody Green
HW_POWER_CTRL register contains brownout interrupt
enable bits ENIRQ_VDDIO_BO, ENIRQ_VDDA_BO and
ENIRQ_VDDD_BO.

Signed-off-by: Cody Green 
Cc: Stefano Babic 
Cc: Marek Vasut 
Cc: Fabio Estevam 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index c33170f06d..33b76533e4 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -1142,8 +1142,9 @@ static void mxs_power_set_vddx(const struct mxs_vddx_cfg 
*cfg,
 
if (adjust_up && cfg->bo_irq) {
if (powered_by_linreg) {
-   bo_int = readl(cfg->reg);
-   clrbits_le32(cfg->reg, cfg->bo_enirq);
+   bo_int = readl(_regs->hw_power_ctrl);
+   clrbits_le32(_regs->hw_power_ctrl,
+   cfg->bo_enirq);
}
setbits_le32(cfg->reg, cfg->bo_offset_mask);
}
@@ -1185,7 +1186,8 @@ static void mxs_power_set_vddx(const struct mxs_vddx_cfg 
*cfg,
if (adjust_up && powered_by_linreg) {
writel(cfg->bo_irq, _regs->hw_power_ctrl_clr);
if (bo_int & cfg->bo_enirq)
-   setbits_le32(cfg->reg, cfg->bo_enirq);
+   setbits_le32(_regs->hw_power_ctrl,
+   cfg->bo_enirq);
}
 
clrsetbits_le32(cfg->reg, cfg->bo_offset_mask,
-- 
2.25.1



[PATCH] tpm: Add TPM2_GetTestResult command support

2023-07-04 Thread Julia Daxenberger
Add TPM2_GetTestResult command support and change the command file and the
help accordingly. Add Python tests and sandbox driver functionality.

The TPM2_GetTestResult command is performed after the TPM2_SelfTest command
and returns manufacturer-specific information regarding the results of the
self-test and an indication of the test status.

Signed-off-by: Julia Daxenberger 
---
 cmd/tpm-v2.c   | 60 +
 drivers/tpm/tpm2_tis_sandbox.c | 47 ++-
 include/tpm-v2.h   | 23 ++
 lib/tpm-v2.c   | 82 ++
 test/py/tests/test_tpm2.py | 50 +
 5 files changed, 261 insertions(+), 1 deletion(-)

diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index d93b83ada9..c6bec7387a 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -2,6 +2,7 @@
 /*
  * Copyright (c) 2018 Bootlin
  * Author: Miquel Raynal 
+ * Copyright (C) 2023 Infineon Technologies AG
  */
 
 #include 
@@ -13,6 +14,8 @@
 #include 
 #include "tpm-user-utils.h"
 
+#define TEST_RESULT_DATA_BUFFER_SIZE 256
+
 static int do_tpm2_startup(struct cmd_tbl *cmdtp, int flag, int argc,
   char *const argv[])
 {
@@ -356,6 +359,57 @@ static int do_tpm_pcr_setauthvalue(struct cmd_tbl *cmdtp, 
int flag,
key, key_sz));
 }
 
+static int do_tpm2_get_test_result(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+   struct udevice *dev;
+   int ret;
+   u8 data[TEST_RESULT_DATA_BUFFER_SIZE];
+   size_t data_len = TEST_RESULT_DATA_BUFFER_SIZE;
+   u32 test_result;
+   u32 rc;
+
+   ret = get_tpm();
+   if (ret)
+   return ret;
+
+   if (argc != 1)
+   return CMD_RET_USAGE;
+
+   rc = tpm2_get_test_result(dev, data, _len, _result);
+   if (rc)
+   goto out;
+
+   printf("Test Result:\n\t0x%08X", test_result);
+   switch (test_result) {
+   case 0x:
+   printf("\tTPM2_RC_SUCCESS\n");
+   break;
+   case 0x0101:
+   printf("\tTPM2_RC_FAILURE\n");
+   break;
+   case 0x0153:
+   printf("\tTPM2_RC_NEEDS_TEST\n");
+   break;
+   case 0x090A:
+   printf("\tTPM2_RC_TESTING\n");
+   break;
+   }
+
+   if (!data_len) {
+   printf("No Test Result Data available\n");
+   goto out;
+   }
+
+   printf("Test Result Data of Self Test:\n\t0x");
+   for (int i = 0; i < data_len; i++)
+   printf("%02X", data[i]);
+   printf("\n");
+
+out:
+   return report_return_code(rc);
+}
+
 static struct cmd_tbl tpm2_commands[] = {
U_BOOT_CMD_MKENT(device, 0, 1, do_tpm_device, "", ""),
U_BOOT_CMD_MKENT(info, 0, 1, do_tpm_info, "", ""),
@@ -374,6 +428,8 @@ static struct cmd_tbl tpm2_commands[] = {
 do_tpm_pcr_setauthpolicy, "", ""),
U_BOOT_CMD_MKENT(pcr_setauthvalue, 0, 1,
 do_tpm_pcr_setauthvalue, "", ""),
+   U_BOOT_CMD_MKENT(get_test_result, 0, 1,
+do_tpm2_get_test_result, "", ""),
 };
 
 struct cmd_tbl *get_tpm2_commands(unsigned int *size)
@@ -447,4 +503,8 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a 
TPMv2.x command",
 ": index of the PCR\n"
 ": secret to protect the access of PCR #\n"
 ": optional password of the PLATFORM hierarchy\n"
+"get_test_result\n"
+"Show manufacturer-specific information regarding the results of a\n"
+"self-test and an indication of the test status.\n"
+
 );
diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
index e4004cfcca..17979cd33a 100644
--- a/drivers/tpm/tpm2_tis_sandbox.c
+++ b/drivers/tpm/tpm2_tis_sandbox.c
@@ -2,6 +2,7 @@
 /*
  * Copyright (c) 2018, Bootlin
  * Author: Miquel Raynal 
+ * Copyright (C) 2023 Infineon Technologies AG
  */
 
 #include 
@@ -231,6 +232,7 @@ static int sandbox_tpm2_check_session(struct udevice *dev, 
u32 command, u16 tag,
case TPM2_CC_SELF_TEST:
case TPM2_CC_GET_CAPABILITY:
case TPM2_CC_PCR_READ:
+   case TPM2_CC_GET_TEST_RESULT:
if (tag != TPM2_ST_NO_SESSIONS) {
printf("No session required for command 0x%x\n",
   command);
@@ -364,6 +366,13 @@ static int sandbox_tpm2_check_readyness(struct udevice 
*dev, int command)
if (!tpm->startup_done)
return TPM2_RC_INITIALIZE;
 
+   break;
+   case TPM2_CC_GET_TEST_RESULT:
+   if (!tpm->init_done || !tpm->startup_done)
+   return TPM2_RC_INITIALIZE;
+   if (!tpm->tests_done)
+   return TPM2_RC_NEEDS_TEST;
+
break;
default:
/* Skip this, since the startup may have happened 

[PATCH] sysreset: Change Kconfig GPIO dependency

2023-07-04 Thread Michal Simek
DM_GPIO depends on GPIO to be enabled but select will cause that DM_GPIO is
selected without GPIO which ends up in compilation error:
undefined reference to `dm_gpio_set_value'
undefined reference to `dm_gpio_get_value'
undefined reference to `dm_gpio_free'
undefined reference to `gpio_request_by_name'

Signed-off-by: Michal Simek 
---

 drivers/sysreset/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 03f7fdd59785..bdbe2a95364d 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -61,14 +61,14 @@ endif
 
 config POWEROFF_GPIO
bool "Enable support for GPIO poweroff driver"
-   select DM_GPIO
+   depends on DM_GPIO
help
  Support for system poweroff using a GPIO pin. This can be used
  for systems having a single GPIO to trigger a system poweroff.
 
 config SYSRESET_GPIO
bool "Enable support for GPIO reset driver"
-   select DM_GPIO
+   depends on DM_GPIO
help
  Reset support via GPIO pin connected reset logic. This is used for
  example on Microblaze where reset logic can be controlled via GPIO
-- 
2.36.1



[PATCH] mtd: Add missing MTD dependency for cfi_mtd

2023-07-04 Thread Michal Simek
cfi_mtd requires add_mtd_device() which is available only when MTD is
enabled that's why record this dependency.

Signed-off-by: Michal Simek 
---

 drivers/mtd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 5fa88dae5f33..c56840c84975 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -128,7 +128,7 @@ config FLASH_SPANSION_S29WS_N
 
 config FLASH_CFI_MTD
bool "Enable CFI MTD driver"
-   depends on FLASH_CFI_DRIVER
+   depends on FLASH_CFI_DRIVER && MTD
help
  This option enables the building of the cfi_mtd driver
  in the drivers directory. The driver exports CFI flash
-- 
2.36.1



[PATCH] git-mailrc: add alias for Eugen Hristev

2023-07-04 Thread Eugen Hristev
add my patchwork alias

Signed-off-by: Eugen Hristev 
---
 doc/git-mailrc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index 96623c3b4ee1..0ceb9eb88b52 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -22,6 +22,7 @@ alias apritzel   Andre Przywara 
 alias bmeng  Bin Meng 
 alias danielschwierzeck Daniel Schwierzeck 
 alias dinh   Dinh Nguyen 
+alias ehristev   Eugen Hristev 
 alias hs Heiko Schocher 
 alias freenixPeng Fan 
 alias iwamatsu   Nobuhiro Iwamatsu 
-- 
2.34.1



[PATCH 2/2] board: ae350: Add missing env variables for booti

2023-07-04 Thread Yu Chien Peter Lin
The 'booti' command is unable to boot Image.gz due to the absence
of required environment variables 'kernel_comp_addr_r' and
'kernel_comp_size'.

This commit adds these variables and reorganizes the memory layout
to prevent any overlap between binaries and files.

Signed-off-by: Yu Chien Peter Lin 
---
 include/configs/ae350.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/include/configs/ae350.h b/include/configs/ae350.h
index b566ecf296f..23e4801379d 100644
--- a/include/configs/ae350.h
+++ b/include/configs/ae350.h
@@ -83,11 +83,15 @@
 #include 
 
 #define CFG_EXTRA_ENV_SETTINGS \
-   "kernel_addr_r=0x0008\0" \
-   "pxefile_addr_r=0x01f0\0" \
-   "scriptaddr=0x01f0\0" \
-   "fdt_addr_r=0x0200\0" \
-   "ramdisk_addr_r=0x0280\0" \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0" \
+   "kernel_addr_r=0x0060\0" \
+   "kernel_comp_addr_r=0x0460\0" \
+   "kernel_comp_size=0x0400\0" \
+   "pxefile_addr_r=0x0860\0" \
+   "scriptaddr=0x0870\0" \
+   "fdt_addr_r=0x0880\0" \
+   "ramdisk_addr_r=0x0890\0" \
BOOTENV
 
 #endif /* __CONFIG_H */
-- 
2.34.1



[PATCH 1/2] riscv: andes_plicsw: Fix IPI during OpenSBI invocation

2023-07-04 Thread Yu Chien Peter Lin
On some AE350 boards, we need to explicitly initialize the priority
registers to a non-zero value so the boot hart can instruct secondary
harts to jump to OpenSBI.

This patch also updates the information about PLICSW.

Signed-off-by: Yu Chien Peter Lin 
---
 arch/riscv/lib/andes_plicsw.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/lib/andes_plicsw.c b/arch/riscv/lib/andes_plicsw.c
index 324eb445aaa..75184080890 100644
--- a/arch/riscv/lib/andes_plicsw.c
+++ b/arch/riscv/lib/andes_plicsw.c
@@ -2,9 +2,10 @@
 /*
  * Copyright (C) 2019, Rick Chen 
  *
- * U-Boot syscon driver for Andes's Platform Level Interrupt Controller (PLIC).
- * The PLIC block holds memory-mapped claim and pending registers
- * associated with software interrupt.
+ * U-Boot syscon driver for Andes' PLICSW
+ * The PLICSW block is an Andes-specific design for software interrupts,
+ * contains memory-mapped priority, enable, claim and pending registers
+ * similar to RISC-V PLIC.
  */
 
 #include 
@@ -26,9 +27,13 @@
 #define ENABLE_REG(base, hart) ((ulong)(base) + 0x2000 + (hart) * 0x80)
 /* claim register */
 #define CLAIM_REG(base, hart)  ((ulong)(base) + 0x24 + (hart) * 0x1000)
+/* priority register */
+#define PRIORITY_REG(base) ((ulong)(base) + PLICSW_PRIORITY_BASE)
 
 #define ENABLE_HART_IPI (0x01010101)
 #define SEND_IPI_TO_HART(hart)  (0x1 << (hart))
+#define PLICSW_PRIORITY_BASE0x4
+#define PLICSW_INTERRUPT_PER_HART   0x8
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -43,9 +48,21 @@ static int enable_ipi(int hart)
return 0;
 }
 
+static void init_priority_ipi(int hart_num)
+{
+uint32_t *priority = (void *)PRIORITY_REG(gd->arch.plicsw);
+
+for (int i = 0; i < hart_num * PLICSW_INTERRUPT_PER_HART; i++) {
+writel(1, [i]);
+}
+
+return;
+}
+
 int riscv_init_ipi(void)
 {
int ret;
+   int hart_num = 0;
long *base = syscon_get_first_range(RISCV_SYSCON_PLICSW);
ofnode node;
struct udevice *dev;
@@ -79,8 +96,10 @@ int riscv_init_ipi(void)
ret = ofnode_read_u32(node, "reg", );
if (ret == 0)
enable_ipi(reg);
+   hart_num++;
}
 
+   init_priority_ipi(hart_num);
return 0;
 }
 
-- 
2.34.1



Re: [PATCH] board: stm32mp1: add splash screen on dk2

2023-07-04 Thread Grzegorz Szymaszek
On Tue, Jul 04, 2023 at 11:14:39AM +0200, Dario Binacchi wrote:
> On Tue, Jul 4, 2023 at 10:11 AM Grzegorz Szymaszek  
> wrote:
> > > + ulong logo =
> > > + (ulong)stmicroelectronics_uboot_logo_8bit_rle;
> > > + bmp_display(logo, BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
> > 
> > Technically logo is const.
> 
> int bmp_display(ulong addr, int x, int y);
> And throughout the code, I only find ulong parameters being passed to
> this function.
> Perhaps I can replace "logo" with "addr".

I'm afraid my comment was perhaps too terse: I wanted to point out that
your "ulong logo" variable is assigned to only once, its value is never
changed, so instead of plain "ulong", you could declare its type as
"const ulong". I won't insist on this change since the code is trivial.

Consider simply removing the new variable and just passing
"(ulong)stmicroelectronics_uboot_logo_8bit_rle" directly as the
bmp_display()'s argument, like in
board/st/stm32f746-disco/stm32f746-disco.c.


signature.asc
Description: PGP signature


Re: [PATCH v3] board: rockchip: add Radxa ROCK5A Rk3588 board

2023-07-04 Thread Jonas Karlman
On 2023-07-04 10:50, Eugen Hristev wrote:
> ROCK 5A is a Rockchip RK3588S based SBC (Single Board Computer) by Radxa.
> 
> There are tree variants depending on the DRAM size : 4G, 8G and 16G.
> 
> Specifications:
> 
>  Rockchip Rk3588S SoC
>  4x ARM Cortex-A76, 4x ARM Cortex-A55
>  4/8/16GB memory LPDDR4x
>  Mali G610MC4 GPU
>  MIPI CSI 2 multiple lanes connector
>  4-lane MIPI DSI connector
>  Audio – 3.5mm earphone jack
>  eMMC module connector
>  uSD slot (up to 128GB)
>  2x USB 2.0, 2x USB 3.0
>  2x micro HDMI 2.1 ports, one up to 8Kp60, the other up to 4Kp60
>  Gigabit Ethernet RJ45 with optional PoE support
>  40-pin IO header including UART, SPI, I2C and 5V DC power in
>  USB PD over USB Type-C
>  Size: 85mm x 56mm (Raspberry Pi 4 form factor)
> 
> Kernel commits:
> d1824cf95799 ("arm64: dts: rockchip: Add rock-5a board")
> 991f136c9f8d ("arm64: dts: rockchip: Update sdhci alias for rock-5a")
> 304c8a759953 ("arm64: dts: rockchip: Remove empty line from rock-5a")
> cda0c2ea65a0 ("arm64: dts: rockchip: Fix RX delay for ethernet phy on 
> rk3588s-rock5a")
> 
> Signed-off-by: Eugen Hristev 
> ---
> Changes in v3:
> - forgot to add defconfig and include file, added now, sorry
> Changes in v2:
> -fixed wrong Kconfig text (rk3588s instead of rk3588)
> -changed doc name (rk3588s instead of rk3588)
> 
> 
>  arch/arm/dts/Makefile   |  1 +
>  arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi| 90 +
>  arch/arm/dts/rk3588s-rock-5a.dts| 73 +
>  arch/arm/mach-rockchip/rk3588/Kconfig   | 28 +++
>  board/radxa/rock5a-rk3588s/Kconfig  | 15 
>  board/radxa/rock5a-rk3588s/MAINTAINERS  |  6 ++
>  board/radxa/rock5a-rk3588s/Makefile |  6 ++
>  board/radxa/rock5a-rk3588s/rock5a-rk3588s.c | 39 +
>  configs/rock5a-rk3588s_defconfig| 71 
>  doc/board/rockchip/rockchip.rst |  1 +
>  include/configs/rock5a-rk3588s.h| 15 
>  11 files changed, 345 insertions(+)
>  create mode 100644 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3588s-rock-5a.dts
>  create mode 100644 board/radxa/rock5a-rk3588s/Kconfig
>  create mode 100644 board/radxa/rock5a-rk3588s/MAINTAINERS
>  create mode 100644 board/radxa/rock5a-rk3588s/Makefile
>  create mode 100644 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c
>  create mode 100644 configs/rock5a-rk3588s_defconfig
>  create mode 100644 include/configs/rock5a-rk3588s.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 480269fa6065..cd9b96c5ba7c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -174,6 +174,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
>  dtb-$(CONFIG_ROCKCHIP_RK3588) += \
>   rk3588-edgeble-neu6a-io.dtb \
>   rk3588-evb1-v10.dtb \
> + rk3588s-rock-5a.dtb \
>   rk3588-rock-5b.dtb
>  
>  dtb-$(CONFIG_ROCKCHIP_RV1108) += \
> diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi 
> b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
> new file mode 100644
> index ..a546f9e4dcc2
> --- /dev/null
> +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Collabora Ltd.
> + */
> +
> +#include "rk3588s-u-boot.dtsi"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + aliases {
> + mmc1 = 
> + };
> +
> + chosen {
> + u-boot,spl-boot-order = "same-as-spl", , 
> + };
> +};
> +
> +_bus8 {
> + bootph-all;
> +};
> +
> +_clk {
> + bootph-all;
> +};
> +
> +_cmd {
> + bootph-all;
> +};
> +
> +_data_strobe {
> + bootph-all;
> +};
> +
> +_rstnout {
> + bootph-all;
> +};
> +
> + {
> + bootph-all;
> +};

This and other common pinctrl nodes could be moved to rk3588s-u-boot.dtsi.

I did something like that for rk3568, instead of having to repeat these
for multiple boards.

See 
https://patchwork.ozlabs.org/project/uboot/patch/20230702173433.3818521-4-jo...@kwiboo.se/

> +
> +_pull_none {
> + bootph-all;
> +};
> +
> +_pull_up_drv_level_2 {
> + bootph-all;
> +};
> +
> +_pull_up {
> + bootph-all;
> +};
> +
> + {
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +_bus4 {
> + bootph-all;
> +};
> +
> +_clk {
> + bootph-all;
> +};
> +
> +_cmd {
> + bootph-all;
> +};
> +
> +_det {
> + bootph-all;
> +};
> +
> + {
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + pinctrl-names = "default";
> + pinctrl-0 = <_bus8 _clk _cmd _data_strobe 
> _rstnout>;
> +};
> +
> +_xfer {
> + bootph-all;
> +};
> +
> diff --git a/arch/arm/dts/rk3588s-rock-5a.dts 
> b/arch/arm/dts/rk3588s-rock-5a.dts
> new file mode 100644
> index ..901825514f9d
> --- /dev/null
> +++ b/arch/arm/dts/rk3588s-rock-5a.dts
> @@ -0,0 +1,73 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +

Re: [PATCH] board: stm32mp1: add splash screen on dk2

2023-07-04 Thread Dario Binacchi
Hi all,

On Tue, Jul 4, 2023 at 10:11 AM Grzegorz Szymaszek  wrote:
>
> Hi,
>
> On Mon, Jul 03, 2023 at 06:27:54PM +0200, Dario Binacchi wrote:
> > diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> > -%<-
> >  #include 
> > +#include 
> > +#include 
> >  #include 
>
> These two should be put above syscon.h if you want to keep the includes
> sorted alphabetically.

yes, you are right. I will update in v2

>
> > + ulong logo =
> > + (ulong)stmicroelectronics_uboot_logo_8bit_rle;
> > + bmp_display(logo, BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
>
> Technically logo is const.

int bmp_display(ulong addr, int x, int y);
And throughout the code, I only find ulong parameters being passed to
this function.
Perhaps I can replace "logo" with "addr".

Thanks and regards,
Dario

>
>
> All the best
>
> --
> Grzegorz



-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

__


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
i...@amarulasolutions.com

www.amarulasolutions.com


[PATCH v2 3/3] binman: Add tests for etype encrypted

2023-07-04 Thread christian . taedcke-oss
From: Christian Taedcke 

Add tests to reach 100% code coverage for the added etype encrypted.

Signed-off-by: Christian Taedcke 
---

Changes in v2:
- adapt tests for changed entry implementation

 tools/binman/ftest.py | 52 +++
 .../binman/test/282_encrypted_no_content.dts  | 15 ++
 tools/binman/test/283_encrypted_no_algo.dts   | 19 +++
 .../test/284_encrypted_invalid_iv_file.dts| 23 
 .../binman/test/285_encrypted_missing_key.dts | 28 ++
 .../binman/test/286_encrypted_key_source.dts  | 29 +++
 tools/binman/test/287_encrypted_key_file.dts  | 29 +++
 7 files changed, 195 insertions(+)
 create mode 100644 tools/binman/test/282_encrypted_no_content.dts
 create mode 100644 tools/binman/test/283_encrypted_no_algo.dts
 create mode 100644 tools/binman/test/284_encrypted_invalid_iv_file.dts
 create mode 100644 tools/binman/test/285_encrypted_missing_key.dts
 create mode 100644 tools/binman/test/286_encrypted_key_source.dts
 create mode 100644 tools/binman/test/287_encrypted_key_file.dts

diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 43b4f850a6..d51139799f 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -94,6 +94,8 @@ ROCKCHIP_TPL_DATA = b'rockchip-tpl'
 TEST_FDT1_DATA= b'fdt1'
 TEST_FDT2_DATA= b'test-fdt2'
 ENV_DATA  = b'var1=1\nvar2="2"'
+ENCRYPTED_IV_DATA = b'123456'
+ENCRYPTED_KEY_DATA= b'1234567890123456'
 PRE_LOAD_MAGIC= b'UBSH'
 PRE_LOAD_VERSION  = 0x11223344.to_bytes(4, 'big')
 PRE_LOAD_HDR_SIZE = 0x1000.to_bytes(4, 'big')
@@ -226,6 +228,10 @@ class TestFunctional(unittest.TestCase):
 # Newer OP_TEE file in v1 binary format
 cls.make_tee_bin('tee.bin')
 
+# test files for encrypted tests
+TestFunctional._MakeInputFile('encrypted-file.iv', ENCRYPTED_IV_DATA)
+TestFunctional._MakeInputFile('encrypted-file.key', ENCRYPTED_KEY_DATA)
+
 cls.comp_bintools = {}
 for name in COMP_BINTOOLS:
 cls.comp_bintools[name] = bintool.Bintool.create(name)
@@ -6676,6 +6682,52 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 ['fit'])
 self.assertIn("Node '/fit': Missing tool: 'mkimage'", str(e.exception))
 
+def testEncryptedNoContent(self):
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('282_encrypted_no_content.dts')
+self.assertIn("Node '/binman/fit/images/u-boot/encrypted': Collection 
must have a 'content' property", str(e.exception))
+
+def testEncryptedNoAlgo(self):
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('283_encrypted_no_algo.dts')
+self.assertIn("Node '/binman/fit/images/u-boot/encrypted': 'encrypted' 
entry is missing properties: algo iv-filename", str(e.exception))
+
+def testEncryptedInvalidIvfile(self):
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('284_encrypted_invalid_iv_file.dts')
+self.assertIn("Filename 'invalid-iv-file' not found in input path",
+  str(e.exception))
+
+def testEncryptedMissingKey(self):
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('285_encrypted_missing_key.dts')
+self.assertIn("Node '/binman/fit/images/u-boot/encrypted': Provide 
either 'key-filename' or 'key-source'",
+  str(e.exception))
+
+def testEncryptedKeySource(self):
+data = self._DoReadFileDtb('286_encrypted_key_source.dts')[0]
+
+dtb = fdt.Fdt.FromData(data)
+dtb.Scan()
+
+node = dtb.GetNode('/images/u-boot/cipher')
+self.assertEqual('algo-name', node.props['algo'].value)
+self.assertEqual('key-source-value', node.props['key-source'].value)
+self.assertEqual(ENCRYPTED_IV_DATA, 
tools.to_bytes(''.join(node.props['iv'].value)))
+self.assertNotIn('key', node.props)
+
+def testEncryptedKeyFile(self):
+data = self._DoReadFileDtb('287_encrypted_key_file.dts')[0]
+
+dtb = fdt.Fdt.FromData(data)
+dtb.Scan()
+
+node = dtb.GetNode('/images/u-boot/cipher')
+self.assertEqual('algo-name', node.props['algo'].value)
+self.assertEqual(ENCRYPTED_IV_DATA, 
tools.to_bytes(''.join(node.props['iv'].value)))
+self.assertEqual(ENCRYPTED_KEY_DATA, b''.join(node.props['key'].value))
+self.assertNotIn('key-source', node.props)
+
 
 if __name__ == "__main__":
 unittest.main()
diff --git a/tools/binman/test/282_encrypted_no_content.dts 
b/tools/binman/test/282_encrypted_no_content.dts
new file mode 100644
index 00..03f7ffee90
--- /dev/null
+++ b/tools/binman/test/282_encrypted_no_content.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+/ {
+   binman {
+   fit {
+   images {
+

[PATCH v2 2/3] binman: Allow cipher node as special section

2023-07-04 Thread christian . taedcke-oss
From: Christian Taedcke 

The new encrypted etype generates a cipher node in the device tree
that should not be evaluated by binman, but still be kept in the
output device tree.

Signed-off-by: Christian Taedcke 
---

(no changes since v1)

 tools/binman/etype/section.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index c36edd1350..56abfd5129 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -178,7 +178,7 @@ class Entry_section(Entry):
 Returns:
 bool: True if the node is a special one, else False
 """
-return node.name.startswith('hash') or 
node.name.startswith('signature')
+return node.name.startswith('hash') or 
node.name.startswith('signature') or node.name.startswith('cipher')
 
 def ReadNode(self):
 """Read properties from the section node"""
-- 
2.34.1



[PATCH v2 1/3] binman: Add support for externally encrypted blobs

2023-07-04 Thread christian . taedcke-oss
From: Christian Taedcke 

This adds a new etype encrypted that is derived from collection.

It creates a new cipher node in the related image similar to the
cipher node used by u-boot, see boot/image-cipher.c.

Signed-off-by: Christian Taedcke 
---

Changes in v2:
- remove global /cipher node
- replace key-name-hint with key-source property
- add entry documentation

 tools/binman/etype/encrypted.py | 149 
 1 file changed, 149 insertions(+)
 create mode 100644 tools/binman/etype/encrypted.py

diff --git a/tools/binman/etype/encrypted.py b/tools/binman/etype/encrypted.py
new file mode 100644
index 00..feb2b4f1de
--- /dev/null
+++ b/tools/binman/etype/encrypted.py
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Weidmüller Interface GmbH & Co. KG
+# Written by Christian Taedcke 
+#
+# Entry-type module for cipher information of encrypted blobs/binaries
+#
+
+from binman.etype.collection import Entry_collection
+from dtoc import fdt_util
+from u_boot_pylib import tools
+
+# This is imported if needed
+state = None
+
+
+class Entry_encrypted(Entry_collection):
+"""Externally built encrypted binary blob
+
+This entry provides the functionality to include information about how to
+decrypt an encrypted binary. This information is added to the
+resulting device tree by adding a new cipher node in the entry's parent
+node (i.e. the binary).
+
+The key that must be used to decrypt the binary is either directly embedded
+in the device tree or indirectly by specifying a key source. The key source
+can be used as an id of a key that is stored in an external device.
+
+Using an embedded key
+~
+
+This is an example using an embedded key::
+
+encrypted_blob: blob-ext {
+filename = "encrypted-blob.bin";
+};
+
+encrypted {
+content = <_blob>;
+algo = "aes256-gcm";
+iv-filename = "encrypted-blob.bin.iv";
+key-filename = "encrypted-blob.bin.key";
+};
+
+This entry generates the following device tree structure form the example
+above::
+
+data = [...]
+cipher {
+algo = "aes256-gcm";
+key = <0x...>;
+iv = <0x...>;
+};
+
+The data property is generated by the blob-ext etype, the cipher node and
+its content is generated by this etype.
+
+Using an external key
+~
+
+Instead of embedding the key itself into the device tree, it is also
+possible to address an externally stored key by specifying a 'key-source'
+instead of the 'key'::
+
+encrypted_blob: blob-ext {
+filename = "encrypted-blob.bin";
+};
+
+encrypted {
+content = <_blob>;
+algo = "aes256-gcm";
+iv-filename = "encrypted-blob.bin.iv";
+key-source = "external-key-id";
+};
+
+This entry generates the following device tree structure form the example
+above::
+
+data = [...]
+cipher {
+algo = "aes256-gcm";
+key-source = "external-key-id";
+iv = <0x...>;
+};
+
+Properties
+~~
+
+In addition to the inherited 'collection' for Properties / Entry arguments:
+- algo: The encryption algorithm. Currently no algorithm is supported
+out-of-the-box. Certain algorithms will be added in future
+patches.
+- iv-filename: The name of the file containing the initialization
+   vector (in short iv). See
+   https://en.wikipedia.org/wiki/Initialization_vector
+- key-filename: The name of the file containing the key. Either
+key-filename or key-source must be provided.
+- key-source: The key that should be used. Either key-filename or
+  key-source must be provided.
+"""
+
+def __init__(self, section, etype, node):
+# Put this here to allow entry-docs and help to work without libfdt
+global state
+from binman import state
+
+super().__init__(section, etype, node)
+self.required_props = ['algo', 'iv-filename']
+self._algo = None
+self._iv_filename = None
+self._key_name_hint = None
+self._key_filename = None
+
+def ReadNode(self):
+super().ReadNode()
+
+self._algo = fdt_util.GetString(self._node, 'algo')
+self._iv_filename = fdt_util.GetString(self._node, 'iv-filename')
+self._key_filename = fdt_util.GetString(self._node, 'key-filename')
+self._key_source = fdt_util.GetString(self._node, 'key-source')
+
+if self._key_filename is None and self._key_source is None:
+self.Raise("Provide either 'key-filename' or 'key-source'")
+
+def gen_entries(self):
+super().gen_entries()
+
+

[PATCH v2 0/3] binman: Add support for externally encrypted blobs

2023-07-04 Thread christian . taedcke-oss
From: Christian Taedcke 

This series adds the functionality to handle externally encrypted
blobs to binman. It includes the functionality itself and the
corresponding unit tests.

The following block shows an example on how to use this functionality.
In the device tree that is parsed by binman a new node encrypted is
used:

/ {
binman {
filename = "u-boot.itb";
fit {
...
images {
some-bitstream {
...
image_bitstream: blob-ext {
filename = "bitstream.bin";
};
encrypted {
content = <_bitstream>;
algo = "aes256-gcm";
iv-filename = 
"bitstream.bin.iv";
key-filename = 
"bitstream.bin.key";
};
...

This results in an generated fit image containing the following
information:

\ {
images {
   ...
   some-bitstream {
...
data = [...]
cipher {
algo = "aes256-gcm";
key = <0x...>;
iv = <0x...>;
};
};
...

Changes in v2:
- remove global /cipher node
- replace key-name-hint with key-source property
- add entry documentation
- adapt tests for changed entry implementation

Christian Taedcke (3):
  binman: Add support for externally encrypted blobs
  binman: Allow cipher node as special section
  binman: Add tests for etype encrypted

 tools/binman/etype/encrypted.py   | 149 ++
 tools/binman/etype/section.py |   2 +-
 tools/binman/ftest.py |  52 ++
 .../binman/test/282_encrypted_no_content.dts  |  15 ++
 tools/binman/test/283_encrypted_no_algo.dts   |  19 +++
 .../test/284_encrypted_invalid_iv_file.dts|  23 +++
 .../binman/test/285_encrypted_missing_key.dts |  28 
 .../binman/test/286_encrypted_key_source.dts  |  29 
 tools/binman/test/287_encrypted_key_file.dts  |  29 
 9 files changed, 345 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/etype/encrypted.py
 create mode 100644 tools/binman/test/282_encrypted_no_content.dts
 create mode 100644 tools/binman/test/283_encrypted_no_algo.dts
 create mode 100644 tools/binman/test/284_encrypted_invalid_iv_file.dts
 create mode 100644 tools/binman/test/285_encrypted_missing_key.dts
 create mode 100644 tools/binman/test/286_encrypted_key_source.dts
 create mode 100644 tools/binman/test/287_encrypted_key_file.dts

-- 
2.34.1



Re: [PATCH 1/3] binman: Add support for externally encrypted blobs

2023-07-04 Thread Taedcke, Christian

Hello Simon,

Am 30.06.2023 um 16:58 schrieb Simon Glass:

Hi Christian,

On Fri, 30 Jun 2023 at 11:28, Taedcke, Christian
 wrote:


Hello Simon,

Am 30.06.2023 um 10:57 schrieb Simon Glass:

Hi Christian,

On Fri, 30 Jun 2023 at 09:20, Taedcke, Christian
 wrote:


Hello Simon,

thank you for the initial review. Replies are below.

Am 29.06.2023 um 21:09 schrieb Simon Glass:

Hi Christian,

On Tue, 27 Jun 2023 at 08:39,  wrote:


From: Christian Taedcke 

This adds a new etype encrypted that is derived from collection.

It creates a new cipher node in the related image similar to the
cipher node used by u-boot, see boot/image-cipher.c.
Optionally it creates a global /cipher node containing a key and iv
using the same nameing convention as used in boot/image-cipher.c.

Signed-off-by: Christian Taedcke 
---

tools/binman/etype/encrypted.py | 98 +
1 file changed, 98 insertions(+)
create mode 100644 tools/binman/etype/encrypted.py

diff --git a/tools/binman/etype/encrypted.py b/tools/binman/etype/encrypted.py
new file mode 100644
index 00..005ae56acf
--- /dev/null
+++ b/tools/binman/etype/encrypted.py
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Weidmüller Interface GmbH & Co. KG
+# Written by Christian Taedcke 
+#
+# Entry-type module for cipher information of encrypted blobs/images
+#
+
+from binman.etype.collection import Entry_collection
+from dtoc import fdt_util
+from u_boot_pylib import tools
+
+# This is imported if needed
+state = None
+
+
+class Entry_encrypted(Entry_collection):
+"""Externally built encrypted binary blob
+
+If the file providing this blob is missing, binman can optionally ignore it
+and produce a broken image with a warning.
+
+In addition to the inherited 'collection' for Properties / Entry arguments:
+- algo: The encryption algorithm


What possible values are available? Please list them


Currently the evaluation of the generated cipher nodes is not
implemented in c code in upstream U-Boot. I use aes256-gcm and decrypt
the relevant blobs/images in board-specific code. We plan to also
upstream the c code for decryption later.

I expect we will support at least aes[128/192/256]-cbc in the future,
since these are already implemented in software in U-Boot and in
addition aes256-gcm via a crypto driver.

Since decryption is not implemented yet, i didn't want to restrict the
possible algos for now, since board-specific code could implement
decryption for any algorithm here that uses a key and iv (initialization
vector).

Should i list aes[128/192/256]-cbc and aes256-gcm here or should i state
that the supported algorithms (for now) are board specific?


Perhaps the correct answer is to say that nothing is supported yet,
but future patches will add certain algorithms TBD?


So something like this would be ok?

- algo: The encryption algorithm. Currently no algorithm is supported
out-of-the-box. Certain algorithms will be added in future patches.


Yes that seems OK to me.










+- iv-name-hint: The name hint for the iv


what is the iv?


Initialization Vector. Should i use the full name here?


Yes, plus explain what it is or where it is documented.






+- key-name-hint: The name hint for the key
+- iv-filename: The name of the file containing the iv
+- key-filename: The name of the file containing the key
+
+This entry creates a cipher node in the entries' parent node (i.e. the


entry's


+image). Optionally it also creates a cipher node in the root of the device
+tree containg key and iv information.


containing

Overall I think this documentation needs to be expanded.


Ok. I tried to explain the motivation in the cover letter, see
https://lists.denx.de/pipermail/u-boot/2023-June/521160.html

Is the cover letter the wrong place for this (should i move the
motivation into the first commit message)?

I will also try to improve the code documentation here.


I mean in the docs for the entry itself (which ends up in
entries.rst), since this is what people read.

Yes it is good to comment the code as well, but it seems OK to me.





I wonder why this needs to be an entry type? Could the node be added
to the description by the user, instead of the entry adding it? It
feels a little strange to me, but perhaps I just need more info.


This new entry type basically reads the files containing the
initialization vector and the key and puts it into the device tree. The
initialization vector normally changes whenever the encrypted blob changes.

Having this as an entry type simplifies the build process of the
resulting image. Otherwise some external script would have to run during
the build process to patch the iv and key into the generated device tree.


OK, so the 'cipher' node ends up providing information on how to
decode the image. But why put it in the root node? Would it not be
better to put it in the node next to the one with the 

[PATCH v3] board: rockchip: add Radxa ROCK5A Rk3588 board

2023-07-04 Thread Eugen Hristev
ROCK 5A is a Rockchip RK3588S based SBC (Single Board Computer) by Radxa.

There are tree variants depending on the DRAM size : 4G, 8G and 16G.

Specifications:

 Rockchip Rk3588S SoC
 4x ARM Cortex-A76, 4x ARM Cortex-A55
 4/8/16GB memory LPDDR4x
 Mali G610MC4 GPU
 MIPI CSI 2 multiple lanes connector
 4-lane MIPI DSI connector
 Audio – 3.5mm earphone jack
 eMMC module connector
 uSD slot (up to 128GB)
 2x USB 2.0, 2x USB 3.0
 2x micro HDMI 2.1 ports, one up to 8Kp60, the other up to 4Kp60
 Gigabit Ethernet RJ45 with optional PoE support
 40-pin IO header including UART, SPI, I2C and 5V DC power in
 USB PD over USB Type-C
 Size: 85mm x 56mm (Raspberry Pi 4 form factor)

Kernel commits:
d1824cf95799 ("arm64: dts: rockchip: Add rock-5a board")
991f136c9f8d ("arm64: dts: rockchip: Update sdhci alias for rock-5a")
304c8a759953 ("arm64: dts: rockchip: Remove empty line from rock-5a")
cda0c2ea65a0 ("arm64: dts: rockchip: Fix RX delay for ethernet phy on 
rk3588s-rock5a")

Signed-off-by: Eugen Hristev 
---
Changes in v3:
- forgot to add defconfig and include file, added now, sorry
Changes in v2:
-fixed wrong Kconfig text (rk3588s instead of rk3588)
-changed doc name (rk3588s instead of rk3588)


 arch/arm/dts/Makefile   |  1 +
 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi| 90 +
 arch/arm/dts/rk3588s-rock-5a.dts| 73 +
 arch/arm/mach-rockchip/rk3588/Kconfig   | 28 +++
 board/radxa/rock5a-rk3588s/Kconfig  | 15 
 board/radxa/rock5a-rk3588s/MAINTAINERS  |  6 ++
 board/radxa/rock5a-rk3588s/Makefile |  6 ++
 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c | 39 +
 configs/rock5a-rk3588s_defconfig| 71 
 doc/board/rockchip/rockchip.rst |  1 +
 include/configs/rock5a-rk3588s.h| 15 
 11 files changed, 345 insertions(+)
 create mode 100644 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588s-rock-5a.dts
 create mode 100644 board/radxa/rock5a-rk3588s/Kconfig
 create mode 100644 board/radxa/rock5a-rk3588s/MAINTAINERS
 create mode 100644 board/radxa/rock5a-rk3588s/Makefile
 create mode 100644 board/radxa/rock5a-rk3588s/rock5a-rk3588s.c
 create mode 100644 configs/rock5a-rk3588s_defconfig
 create mode 100644 include/configs/rock5a-rk3588s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..cd9b96c5ba7c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -174,6 +174,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
 dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-evb1-v10.dtb \
+   rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RV1108) += \
diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi 
b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
new file mode 100644
index ..a546f9e4dcc2
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   aliases {
+   mmc1 = 
+   };
+
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+_bus8 {
+   bootph-all;
+};
+
+_clk {
+   bootph-all;
+};
+
+_cmd {
+   bootph-all;
+};
+
+_data_strobe {
+   bootph-all;
+};
+
+_rstnout {
+   bootph-all;
+};
+
+ {
+   bootph-all;
+};
+
+_pull_none {
+   bootph-all;
+};
+
+_pull_up_drv_level_2 {
+   bootph-all;
+};
+
+_pull_up {
+   bootph-all;
+};
+
+ {
+   bus-width = <4>;
+   status = "okay";
+};
+
+_bus4 {
+   bootph-all;
+};
+
+_clk {
+   bootph-all;
+};
+
+_cmd {
+   bootph-all;
+};
+
+_det {
+   bootph-all;
+};
+
+ {
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus8 _clk _cmd _data_strobe 
_rstnout>;
+};
+
+_xfer {
+   bootph-all;
+};
+
diff --git a/arch/arm/dts/rk3588s-rock-5a.dts b/arch/arm/dts/rk3588s-rock-5a.dts
new file mode 100644
index ..901825514f9d
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a.dts
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include "rk3588s.dtsi"
+
+/ {
+   model = "Radxa ROCK 5 Model A";
+   compatible = "radxa,rock-5a", "rockchip,rk3588s";
+
+   aliases {
+   mmc0 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+};
+
+ {
+   clock_in_out = "output";
+   phy-handle = <_phy1>;
+   phy-mode = "rgmii";
+   pinctrl-0 = <_miim
+_tx_bus2
+_rx_bus2
+_rgmii_clk
+_rgmii_bus>;
+   pinctrl-names = "default";
+ 

Re: [PATCH 2/2] mxs: Don't enable 4P2 reg if MXS is powered only from DCDC_BATT

2023-07-04 Thread Lukasz Majewski
Hi Marek, Cody,

> On 7/3/23 18:33, Cody Green wrote:
> > 'mxs_power_enable_4p2()' function call was added to
> > 'mxs_batt_boot()' in 'commit a0f97610757d' to enable DCDC converter
> > when board is powered from 5V and has detected sufficient battery
> > voltage. This involves enabling 4P2 regulator and there is a code
> > in 'mxs_power_enable_4p2()' that disables VDDIO, VDDA, VDDD outputs
> > of the DCDC converter and enables BO for each power rail:
> > 
> >setbits_le32(_regs->hw_power_vddioctrl,
> >  POWER_VDDIOCTRL_DISABLE_FET | POWER_VDDIOCTRL_PWDN_BRNOUT);
> > 
> > There is no issue if the MXS is powered from the 5V source and
> > linear regulators are supplying power to the VDDIO, VDDA, VDDD
> > rails. However, if the MXS is powered only from the DCDC_BATT
> > without 5V, disabling the DCDC converter outputs causes VDDIO,
> > VDDA, VDDD rails to lose power.

I think that I've also hit the same issue with the XEA board
(upstreamed).

I've prepared a set of patches:
https://patchwork.ozlabs.org/project/uboot/patch/20230509143243.1523791-5-lu...@denx.de/

to fix this problem.

Those patches are now for some time on the mailing list for review - and
I do hope that Stefano will pull them with next PR for u-boot-imx
repository.

> > 
> > The proposed solution is not to call the 'mxs_power_enable_4p2()'
> > function if the MXS is powered only by the DCDC_BATT, because there
> > is no reason to enable 4P2 regulator in this case.

I think this patch:
https://patchwork.ozlabs.org/project/uboot/patch/20230509143243.1523791-3-lu...@denx.de/

address exactly this issue.

> > Also 5V brownout
> > should not be enabled in 'mxs_power_init()' and linear regulator
> > checks should be disabled in 'mxs_power_set_vddx()'.
> > 

I've also added some code to limit the VDD5V current when we intend to
use DCDC_BATT input as the _primary_ source of power (AN4199 advises
this one for industrial applications as the most reliable).


> > Signed-off-by: Cody Green 
> > Cc: Stefano Babic 
> > Cc: Marek Vasut 
> > Cc: Fabio Estevam 
> > ---
> >   arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 7 +++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
> > b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index
> > 33b76533e4..72172705f2 100644 ---
> > a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++
> > b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -752,7 +752,9 @@
> > static void mxs_batt_boot(void) POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK,
> > 0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
> >   
> > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > mxs_power_enable_4p2();
> > +#endif
> >   }
> >   
> >   /**
> > @@ -1137,8 +1139,11 @@ static void mxs_power_set_vddx(const struct
> > mxs_vddx_cfg *cfg, cur_target += cfg->lowest_mV;
> >   
> > adjust_up = new_target > cur_target;
> > +
> > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > if (cfg->powered_by_linreg)
> > powered_by_linreg = cfg->powered_by_linreg();
> > +#endif
> >   
> > if (adjust_up && cfg->bo_irq) {
> > if (powered_by_linreg) {
> > @@ -1269,7 +1274,9 @@ void mxs_power_init(void)
> > POWER_CTRL_VBUS_VALID_IRQ |
> > POWER_CTRL_BATT_BO_IRQ | POWER_CTRL_DCDC4P2_BO_IRQ,
> > _regs->hw_power_ctrl_clr); 
> > +#ifndef CFG_SPL_MXS_NO_VDD5V_SOURCE
> > writel(POWER_5VCTRL_PWDN_5VBRNOUT,
> > _regs->hw_power_5vctrl_set); +#endif
> >   
> > early_delay(1000);
> >   }  
> 
> +CC Lukasz




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpYvMAwzuEpt.pgp
Description: OpenPGP digital signature


Re: [PATCH] board: stm32mp1: add splash screen on dk2

2023-07-04 Thread Grzegorz Szymaszek
Hi,

On Mon, Jul 03, 2023 at 06:27:54PM +0200, Dario Binacchi wrote:
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> -%<-
>  #include 
> +#include 
> +#include 
>  #include 

These two should be put above syscon.h if you want to keep the includes
sorted alphabetically.

> + ulong logo =
> + (ulong)stmicroelectronics_uboot_logo_8bit_rle;
> + bmp_display(logo, BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);

Technically logo is const.


All the best

-- 
Grzegorz


signature.asc
Description: PGP signature


[PATCH v1] spi: npcm_pspi: use ACTIVE_LOW flag for cs gpio and set default max_hz

2023-07-04 Thread Jim Liu
If cs gpio is requested with ACTIVE_HIGH flag, it will
be pulled low(i.e. active). This is not what we expected.

Signed-off-by: Jim Liu 
---
 drivers/spi/npcm_pspi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/npcm_pspi.c b/drivers/spi/npcm_pspi.c
index bd9ac65411..37bab70967 100644
--- a/drivers/spi/npcm_pspi.c
+++ b/drivers/spi/npcm_pspi.c
@@ -40,7 +40,7 @@ static inline void spi_cs_activate(struct udevice *dev)
struct udevice *bus = dev->parent;
struct npcm_pspi_priv *priv = dev_get_priv(bus);
 
-   dm_gpio_set_value(>cs_gpio, 0);
+   dm_gpio_set_value(>cs_gpio, 1);
 }
 
 static inline void spi_cs_deactivate(struct udevice *dev)
@@ -48,7 +48,7 @@ static inline void spi_cs_deactivate(struct udevice *dev)
struct udevice *bus = dev->parent;
struct npcm_pspi_priv *priv = dev_get_priv(bus);
 
-   dm_gpio_set_value(>cs_gpio, 1);
+   dm_gpio_set_value(>cs_gpio, 0);
 }
 
 static inline void npcm_pspi_enable(struct npcm_pspi_priv *priv)
@@ -122,6 +122,9 @@ static int npcm_pspi_xfer(struct udevice *dev, unsigned int 
bitlen,
if (flags & SPI_XFER_END)
spi_cs_deactivate(dev);
 
+   debug("npcm_pspi_xfer: slave %s:%s dout %08X din %08X bitlen %u\n",
+ dev->parent->name, dev->name, *(uint *)tx, *(uint *)rx, bitlen);
+
npcm_pspi_disable(priv);
 
return ret;
@@ -183,6 +186,7 @@ static int npcm_pspi_set_mode(struct udevice *bus, uint 
mode)
val |= pspi_mode;
writew(val, priv->base + PSPI_CTL1);
 
+   debug("%s: mode=%u\n", __func__, mode);
return 0;
 }
 
@@ -197,9 +201,9 @@ static int npcm_pspi_probe(struct udevice *bus)
return ret;
 
priv->base = dev_read_addr_ptr(bus);
-   priv->max_hz = dev_read_u32_default(bus, "spi-max-frequency", 0);
+   priv->max_hz = dev_read_u32_default(bus, "spi-max-frequency", 100);
gpio_request_by_name_nodev(offset_to_ofnode(node), "cs-gpios", 0,
-  >cs_gpio, GPIOD_IS_OUT);
+  >cs_gpio, GPIOD_IS_OUT| 
GPIOD_ACTIVE_LOW);
 
return 0;
 }
-- 
2.17.1



[PATCH v1 4/4] arch: arm: npcm8xx: add cpu version and 4G ram support

2023-07-04 Thread Jim Liu
Add npcm8xx A2 cpu version check
and add 4G RAM support

Signed-off-by: Jim Liu 
---
 arch/arm/include/asm/arch-npcm8xx/gcr.h |  1 +
 arch/arm/mach-npcm/npcm8xx/cpu.c| 12 -
 board/nuvoton/arbel_evb/arbel_evb.c | 70 +++--
 3 files changed, 79 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-npcm8xx/gcr.h 
b/arch/arm/include/asm/arch-npcm8xx/gcr.h
index ee6677a0e5..20230d64e6 100644
--- a/arch/arm/include/asm/arch-npcm8xx/gcr.h
+++ b/arch/arm/include/asm/arch-npcm8xx/gcr.h
@@ -12,6 +12,7 @@
 /* On-Chip ARBEL NPCM8XX VERSIONS */
 #define ARBEL_Z1   0x00A35850
 #define ARBEL_A1   0x04a35850
+#define ARBEL_A2   0x08a35850
 #define ARBEL_NPCM845  0x
 #define ARBEL_NPCM830  0x00300395
 #define ARBEL_NPCM810  0x0220
diff --git a/arch/arm/mach-npcm/npcm8xx/cpu.c b/arch/arm/mach-npcm/npcm8xx/cpu.c
index 2d839cfae9..af59452609 100644
--- a/arch/arm/mach-npcm/npcm8xx/cpu.c
+++ b/arch/arm/mach-npcm/npcm8xx/cpu.c
@@ -68,6 +68,9 @@ int print_cpuinfo(void)
case ARBEL_A1:
printf("A1 @ ");
break;
+   case ARBEL_A2:
+   printf("A2 @ ");
+   break;
default:
printf("Unknown\n");
break;
@@ -92,7 +95,7 @@ int arch_cpu_init(void)
return 0;
 }
 
-static struct mm_region npcm_mem_map[1 + CONFIG_NR_DRAM_BANKS + 1] = {
+static struct mm_region npcm_mem_map[] = {
{
/* DRAM */
.phys = 0x0UL,
@@ -109,6 +112,13 @@ static struct mm_region npcm_mem_map[1 + 
CONFIG_NR_DRAM_BANKS + 1] = {
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
},
+   {
+   .phys = 0x1UL,
+   .virt = 0x1UL,
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   },
{
/* List terminator */
0,
diff --git a/board/nuvoton/arbel_evb/arbel_evb.c 
b/board/nuvoton/arbel_evb/arbel_evb.c
index cd12ce3834..e52e0a59ab 100644
--- a/board/nuvoton/arbel_evb/arbel_evb.c
+++ b/board/nuvoton/arbel_evb/arbel_evb.c
@@ -8,6 +8,17 @@
 #include 
 #include 
 
+#define SR_MII_CTRL_SWR_BIT15  15
+
+#define DRAM_512MB_ECC_SIZE0x1C00ULL
+#define DRAM_512MB_SIZE0x2000ULL
+#define DRAM_1GB_ECC_SIZE  0x3800ULL
+#define DRAM_1GB_SIZE  0x4000ULL
+#define DRAM_2GB_ECC_SIZE  0x7000ULL
+#define DRAM_2GB_SIZE  0x8000ULL
+#define DRAM_4GB_ECC_SIZE  0xEULL
+#define DRAM_4GB_SIZE  0x1ULL
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
@@ -18,12 +29,65 @@ int board_init(void)
 int dram_init(void)
 {
struct npcm_gcr *gcr = (struct npcm_gcr *)NPCM_GCR_BA;
+   uint64_t delta = 0ULL;
 
/*
-* Get dram size from bootblock.
-* The value is stored in scrpad_02 register.
+* get dram active size value from bootblock.
+* Value sent using scrpad_03 register.
+* feature available in bootblock 0.0.6 and above.
 */
-   gd->ram_size = readl(>scrpad_b);
+
+   gd->ram_size = readl(>scrpad_c);
+   debug("%s: scrpad_c: %llx ", __func__, gd->ram_size);
+
+   if (gd->ram_size == 0) {
+   gd->ram_size = readl(>scrpad_b);
+   debug("%s: scrpad_b: %llx ", __func__, gd->ram_size);
+   } else {
+   gd->ram_size *= 0x10ULL;
+   }
+
+   gd->bd->bi_dram[0].start = 0;
+   debug("ram_size: %llx ", gd->ram_size);
+
+   switch (gd->ram_size) {
+   case DRAM_512MB_ECC_SIZE:
+   case DRAM_512MB_SIZE:
+   case DRAM_1GB_ECC_SIZE:
+   case DRAM_1GB_SIZE:
+   case DRAM_2GB_ECC_SIZE:
+   case DRAM_2GB_SIZE:
+   gd->bd->bi_dram[0].size = gd->ram_size;
+   gd->bd->bi_dram[1].start = 0;
+   gd->bd->bi_dram[1].size = 0;
+   break;
+   case DRAM_4GB_ECC_SIZE:
+   gd->bd->bi_dram[0].size = DRAM_2GB_ECC_SIZE;
+   gd->bd->bi_dram[1].start = DRAM_4GB_SIZE;
+   gd->bd->bi_dram[1].size = DRAM_2GB_SIZE;
+   delta = DRAM_4GB_SIZE - DRAM_2GB_ECC_SIZE;
+   break;
+   case DRAM_4GB_SIZE:
+   gd->bd->bi_dram[0].size = DRAM_2GB_SIZE;
+   gd->bd->bi_dram[1].start = DRAM_4GB_SIZE;
+   gd->bd->bi_dram[1].size = DRAM_2GB_SIZE;
+   delta = DRAM_4GB_SIZE - DRAM_2GB_SIZE;
+   break;
+   default:
+   gd->bd->bi_dram[0].size = DRAM_1GB_SIZE;
+   gd->bd->bi_dram[1].start = 0;
+   gd->bd->bi_dram[1].size = 0;
+   break;
+   }
+
+   gd->ram_size -= delta;
+
+   return 0;
+}
+
+int dram_init_banksize(void)
+{
+   

[PATCH v1 3/4] misc: npcm_host_intf: change initialization sequence

2023-07-04 Thread Jim Liu
configuration should be done before release host wait

Signed-off-by: Jim Liu 
---
 drivers/misc/npcm_host_intf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/npcm_host_intf.c b/drivers/misc/npcm_host_intf.c
index 0244e40457..79f57f57d8 100644
--- a/drivers/misc/npcm_host_intf.c
+++ b/drivers/misc/npcm_host_intf.c
@@ -50,9 +50,6 @@ static int npcm_host_intf_bind(struct udevice *dev)
const char *type;
int ret;
 
-   /* Release host wait */
-   setbits_8(SMC_CTL_REG_ADDR, SMC_CTL_HOSTWAIT);
-
syscon = syscon_regmap_lookup_by_phandle(dev, "syscon");
if (IS_ERR(syscon)) {
dev_err(dev, "%s: unable to get syscon, dev %s\n", __func__, 
dev->name);
@@ -93,6 +90,9 @@ static int npcm_host_intf_bind(struct udevice *dev)
regmap_update_bits(syscon, MFSEL1, MFSEL1_LPCSEL, 
MFSEL1_LPCSEL);
}
 
+   /* Release host wait */
+   setbits_8(SMC_CTL_REG_ADDR, SMC_CTL_HOSTWAIT);
+
return 0;
 }
 
-- 
2.17.1



[PATCH v1 2/4] pinctrl: nuvoton: fix reset reason error for poweron

2023-07-04 Thread Jim Liu
In non tip mode, BMC first power on with PORST+CORST.
the gpio status will error.

Signed-off-by: Jim Liu 
---
 drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c 
b/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
index 0ec47e9577..4549cb061e 100644
--- a/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
+++ b/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
@@ -808,6 +808,9 @@ static bool is_gpio_persist(struct udevice *dev, uint bank)
status = npcm_get_reset_status();
dev_dbg(dev, "reset status: 0x%x\n", status);
 
+   if (status & PORST)
+   return false;
+
if (status & CORST)
regmap_read(priv->rst_regmap, CORSTC, );
else if (status & WD0RST)
-- 
2.17.1



[PATCH v1 1/4] board: nuvoton: arbel: change uboot load address

2023-07-04 Thread Jim Liu
use new memory layout and change uboot load address.
open tpm, tee and more config feature

No need to reserve top memory because the reserved space
is moved to the bottom area of memory.

Signed-off-by: Jim Liu 
---
 board/nuvoton/arbel_evb/Kconfig |  4 ++--
 configs/arbel_evb_defconfig | 15 ++-
 include/configs/arbel.h |  5 +++--
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/board/nuvoton/arbel_evb/Kconfig b/board/nuvoton/arbel_evb/Kconfig
index efe85974a2..33c589f1fb 100644
--- a/board/nuvoton/arbel_evb/Kconfig
+++ b/board/nuvoton/arbel_evb/Kconfig
@@ -11,8 +11,8 @@ config SYS_CONFIG_NAME
 
 config SYS_MEM_TOP_HIDE
hex "Reserved TOP memory"
-   default 0xB00
+   default 0x0
help
- Reserve memory for ECC/GFX/VCD/ECE.
+ Reserve memory for ECC/GFX/OPTEE/TIP/CP.
 
 endif
diff --git a/configs/arbel_evb_defconfig b/configs/arbel_evb_defconfig
index 29c4c187b5..c27a7cdd3a 100644
--- a/configs/arbel_evb_defconfig
+++ b/configs/arbel_evb_defconfig
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_ARCH_NPCM=y
 CONFIG_SYS_MALLOC_LEN=0x24
 CONFIG_SYS_MALLOC_F_LEN=0x1000
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_TEXT_BASE=0x06208000
+CONFIG_NR_DRAM_BANKS=2
 CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0x3C
 CONFIG_ENV_SECT_SIZE=0x1000
@@ -22,6 +23,8 @@ CONFIG_BOOTCOMMAND="run common_bootargs; run romboot"
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_MAXARGS=32
 CONFIG_SYS_BOOTM_LEN=0x140
+CONFIG_SYS_LOAD_ADDR=0x06208000
+CONFIG_SYS_INIT_SP_ADDR=0x06208000
 CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -86,3 +89,13 @@ CONFIG_USB_STORAGE=y
 CONFIG_LIB_HW_RAND=y
 CONFIG_SHA_HW_ACCEL=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_TEE=y
+CONFIG_OPTEE=y
+CONFIG_TPM=y
+CONFIG_TPM_V2=y
+CONFIG_TPM2_FTPM_TEE=y
+CONFIG_CMD_TPM=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PART=y
diff --git a/include/configs/arbel.h b/include/configs/arbel.h
index 8e27fb52a1..891257bc93 100644
--- a/include/configs/arbel.h
+++ b/include/configs/arbel.h
@@ -7,12 +7,13 @@
 #define __CONFIG_ARBEL_H
 
 #define CFG_SYS_SDRAM_BASE 0x0
-#define CFG_SYS_BOOTMAPSZ  (20 << 20)
+#define CFG_SYS_BOOTMAPSZ  (30 << 20)
+#define CFG_SYS_BOOTM_LEN  (20 << 20)
 #define CFG_SYS_INIT_RAM_ADDR  CFG_SYS_SDRAM_BASE
 #define CFG_SYS_INIT_RAM_SIZE  0x8000
 
 /* Default environemnt variables */
-#define CFG_EXTRA_ENV_SETTINGS   "uimage_flash_addr=8020\0"   \
+#define CFG_EXTRA_ENV_SETTINGS   "uimage_flash_addr=8040\0"   \
"stdin=serial\0"   \
"stdout=serial\0"   \
"stderr=serial\0"\
-- 
2.17.1



[PATCH v1 0/4] Add NPCM8xx more feature support

2023-07-04 Thread Jim Liu
1. support 4g ram and new memory layout
2. A2 cpu support
3. fix pinctrl, misc driver error

Jim Liu (4):
  board: nuvoton: arbel: change uboot load address
  pinctrl: nuvoton: fix reset reason error for poweron
  misc: npcm_host_intf: change initialization sequence
  arch: arm: npcm8xx: add cpu version and 4G ram support

 arch/arm/include/asm/arch-npcm8xx/gcr.h   |  1 +
 arch/arm/mach-npcm/npcm8xx/cpu.c  | 12 +++-
 board/nuvoton/arbel_evb/Kconfig   |  4 +-
 board/nuvoton/arbel_evb/arbel_evb.c   | 70 ++-
 configs/arbel_evb_defconfig   | 15 -
 drivers/misc/npcm_host_intf.c |  6 +-
 drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c |  3 +
 include/configs/arbel.h   |  5 +-
 8 files changed, 104 insertions(+), 12 deletions(-)

-- 
2.17.1



[GIT PULL] Please pull u-boot-pmic next

2023-07-04 Thread Jaehoon Chung
Dear Tom,

Please pull u-boot-pmic next into u-boot next branch.
If there is a problem, let me know, plz.

Best Regards,
Jaehoon Chung

CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/16767

The following changes since commit 67d8b46e6efa306403e45f4c76f24b86a5e63b75:

  Merge tag 'u-boot-amlogic-next-20230628' of 
https://source.denx.de/u-boot/custodians/u-boot-amlogic into next (2023-06-28 
10:10:03 -0400)

are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-pmic.git next

for you to fetch changes up to 8202bc29454cfdd5839058e4b79c36a3fbb221cf:

  regulator: handle different error codes in regulator_set_enable_if_allowed 
(2023-07-04 11:21:12 +0900)


Eugen Hristev (3):
  regulator: implement basic reference counter
  regulator: rename dev_pdata to plat
  regulator: handle different error codes in regulator_set_enable_if_allowed

 drivers/power/regulator/fan53555.c | 10 ++---
 drivers/power/regulator/fixed.c| 16 
 drivers/power/regulator/gpio-regulator.c   | 46 +++---
 drivers/power/regulator/regulator-uclass.c |  6 +++
 drivers/power/regulator/regulator_common.c | 61 --
 drivers/power/regulator/regulator_common.h | 27 +++--
 6 files changed, 107 insertions(+), 59 deletions(-)


[PATCH] env: Fix default environment saving issue

2023-07-04 Thread Ashok Reddy Soma
When CONFIG_SYS_REDUNDAND_ENVIRONMENT is enabled, by default env is
getting saved to redundant environment irrespective of primary env is
present or not.

It means even if primary and redundant environment are not present, by
default, env is getting stored to redundant environment. Even if primary
env is present, it is choosing to store in redudndant env.

Ideally it should look for primary env and choose to store in primary env
if it is present. If both primary and redundant env are not present then
it should save in to primary env area.

Fix the issue by making env_valid = ENV_INVALID when both the
environments are not present.

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

 env/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/env/common.c b/env/common.c
index 8beb8e6aa4..0ecdb248a0 100644
--- a/env/common.c
+++ b/env/common.c
@@ -353,6 +353,7 @@ int env_check_redund(const char *buf1, int buf1_read_fail,
tmp_env2->crc;
 
if (!crc1_ok && !crc2_ok) {
+   gd->env_valid = ENV_INVALID;
return -ENOMSG; /* needed for env_load() */
} else if (crc1_ok && !crc2_ok) {
gd->env_valid = ENV_VALID;
-- 
2.17.1



Re: [PATCH 07/12] binman: Provide a way to specific the fdt-list directly

2023-07-04 Thread Jan Kiszka
On 28.06.23 13:41, Simon Glass wrote:
> Sometimes multiple boards are built with binman and it is useful to
> specify a different FDT list for each. At present this is not possible
> without providing multiple values of the of-list entryarg (which is not
> supported in the U-Boot build system).
> 
> Allow a fit,fdt-list-val string-list property to be used instead.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  tools/binman/entries.rst   |  6 +++
>  tools/binman/etype/fit.py  |  9 
>  tools/binman/ftest.py  | 14 ++-
>  tools/binman/test/284_fit_fdt_list.dts | 58 ++
>  4 files changed, 86 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/test/284_fit_fdt_list.dts
> 
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index b71af801fdad..b55f424620a3 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -615,6 +615,12 @@ The top-level 'fit' node supports the following special 
> properties:
>  `of-list` meaning that `-a of-list="dtb1 dtb2..."` should be passed
>  to binman.
>  
> +fit,fdt-list-val
> +As an alternative to fit,fdt-list the list of device tree files
> +can be provided in this property as a string list, e.g.::
> +
> +fit,fdt-list-val = "dtb1", "dtb2";
> +
>  Substitutions
>  ~
>  
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index c395706ece5f..ef4d0667578d 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -81,6 +81,12 @@ class Entry_fit(Entry_section):
>  `of-list` meaning that `-a of-list="dtb1 dtb2..."` should be 
> passed
>  to binman.
>  
> +fit,fdt-list-val
> +As an alternative to fit,fdt-list the list of device tree files
> +can be provided in this property as a string list, e.g.::
> +
> +fit,fdt-list-val = "dtb1", "dtb2";
> +
>  Substitutions
>  ~
>  
> @@ -361,6 +367,9 @@ class Entry_fit(Entry_section):
>  [EntryArg(self._fit_list_prop.value, str)])
>  if fdts is not None:
>  self._fdts = fdts.split()
> +else:
> +self._fdts = fdt_util.GetStringList(self._node, 
> 'fit,fdt-list-val')
> +
>  self._fit_default_dt = 
> self.GetEntryArgsOrProps([EntryArg('default-dt',
>str)])[0]
>  
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 6d0ffda2f432..54691c420733 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6739,6 +6739,18 @@ fdt fdtmapExtract the 
> devicetree blob from the fdtmap
>  # Just check that the data appears in the file somewhere
>  self.assertIn(U_BOOT_DATA, data)
>  
> +def testFitFdtList(self):
> +"""Test an image with an FIT with the fit,fdt-list-val option"""
> +entry_args = {
> +'default-dt': 'test-fdt2',
> +}
> +data = self._DoReadFileDtb(
> +'284_fit_fdt_list.dts',
> +entry_args=entry_args,
> +extra_indirs=[os.path.join(self._indir, TEST_FDT_SUBDIR)])[0]
> +self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
> +fit_data = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)]
> +
>  
> -if __name__ == "_s_main__":
> +if __name__ == "__main__":
>  unittest.main()
> diff --git a/tools/binman/test/284_fit_fdt_list.dts 
> b/tools/binman/test/284_fit_fdt_list.dts
> new file mode 100644
> index ..8885313f5b88
> --- /dev/null
> +++ b/tools/binman/test/284_fit_fdt_list.dts
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + u-boot {
> + };
> + fit {
> + description = "test-desc";
> + #address-cells = <1>;
> + fit,fdt-list-val = "test-fdt1", "test-fdt2";
> +
> + images {
> + kernel {
> + description = "Vanilla Linux kernel";
> + type = "kernel";
> + arch = "ppc";
> + os = "linux";
> + compression = "gzip";
> + load = <>;
> + entry = <>;
> + hash-1 {
> + algo = "crc32";
> + };
> + hash-2 {
> + algo = "sha1";
> + };
> + u-boot {
> +