Re: [PATCH 02/16] xilinx_mbv: Remove empty config header

2024-01-22 Thread Michal Simek




On 1/22/24 23:39, Tom Rini wrote:

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the xilinx_mbv platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Michal Simek 
---
  board/xilinx/mbv/Kconfig | 3 ---
  board/xilinx/mbv/MAINTAINERS | 1 -
  include/configs/xilinx_mbv.h | 6 --
  3 files changed, 10 deletions(-)
  delete mode 100644 include/configs/xilinx_mbv.h

diff --git a/board/xilinx/mbv/Kconfig b/board/xilinx/mbv/Kconfig
index 4bc9f72c541b..d2dec397ed6f 100644
--- a/board/xilinx/mbv/Kconfig
+++ b/board/xilinx/mbv/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
  config SYS_CPU
default "generic"
  
-config SYS_CONFIG_NAME

-   default "xilinx_mbv"
-
  config TEXT_BASE
default 0x8000 if !RISCV_SMODE
default 0x8040 if RISCV_SMODE && ARCH_RV32I
diff --git a/board/xilinx/mbv/MAINTAINERS b/board/xilinx/mbv/MAINTAINERS
index 445654fe740e..db9f03388df9 100644
--- a/board/xilinx/mbv/MAINTAINERS
+++ b/board/xilinx/mbv/MAINTAINERS
@@ -4,4 +4,3 @@ S:  Maintained
  F:arch/riscv/dts/xilinx-mbv*
  F:board/xilinx/mbv/
  F:configs/xilinx_mbv*
-F: include/configs/xilinx_mbv.h
diff --git a/include/configs/xilinx_mbv.h b/include/configs/xilinx_mbv.h
deleted file mode 100644
index dba398aeec49..
--- a/include/configs/xilinx_mbv.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * (C) Copyright 2023, Advanced Micro Devices, Inc.
- *
- * Michal Simek 
- */


Acked-by: Michal Simek 

But maybe in future we need to revert this patch to add more options there.
Or do you plan to remove all of these configs?
I can imagine distro boot wiring but that can be done via vars file only but it 
is not practical.


Thanks,
Michal



Re: [PATCH] toradex: tdx-cfg-block: Add new apalis and colibri pid

2024-01-22 Thread Marcel Ziswiler
On Mon, 2024-01-22 at 17:09 -0300, Joao Paulo Goncalves wrote:
> From: Joao Paulo Goncalves 
> 
> Add new apalis imx6 and colibri imx6/imx7 products IDs.
> 
> Signed-off-by: Joao Paulo Goncalves 

Acked-by: Marcel Ziswiler 

> ---
>  board/toradex/common/tdx-cfg-block.c | 9 +
>  board/toradex/common/tdx-cfg-block.h | 9 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/board/toradex/common/tdx-cfg-block.c 
> b/board/toradex/common/tdx-cfg-block.c
> index 7187e1ba377..7affc290395 100644
> --- a/board/toradex/common/tdx-cfg-block.c
> +++ b/board/toradex/common/tdx-cfg-block.c
> @@ -147,6 +147,15 @@ const struct toradex_som toradex_modules[] = {
>   [74] = { "Verdin AM62 Dual 1GB IT",  
> TARGET_IS_ENABLED(VERDIN_AM62_A53) },
>   [75] = { "Verdin AM62 Dual 1GB WB IT",   
> TARGET_IS_ENABLED(VERDIN_AM62_A53) },
>   [76] = { "Verdin AM62 Quad 2GB WB IT",   
> TARGET_IS_ENABLED(VERDIN_AM62_A53) },
> + [77] = { "Colibri iMX6S 256MB",  
> TARGET_IS_ENABLED(COLIBRI_IMX6)    },
> + [78] = { "Colibri iMX6S 256MB IT",   
> TARGET_IS_ENABLED(COLIBRI_IMX6)    },
> + [79] = { "Colibri iMX6DL 512MB", 
> TARGET_IS_ENABLED(COLIBRI_IMX6)    },  
> + [80] = { "Colibri iMX6DL 512MB IT",  
> TARGET_IS_ENABLED(COLIBRI_IMX6)    },
> + [81] = { "Colibri iMX7D 512MB",  
> TARGET_IS_ENABLED(COLIBRI_IMX7)    },
> + [82] = { "Apalis iMX6D 512MB",   
> TARGET_IS_ENABLED(APALIS_IMX6) },
> + [83] = { "Apalis iMX6Q 1GB", 
> TARGET_IS_ENABLED(APALIS_IMX6) },
> + [84] = { "Apalis iMX6D 1GB IT",  
> TARGET_IS_ENABLED(APALIS_IMX6) },
> + [85] = { "Apalis iMX6Q 2GB IT",  
> TARGET_IS_ENABLED(APALIS_IMX6) },
>  };
>  
>  struct pid4list {
> diff --git a/board/toradex/common/tdx-cfg-block.h 
> b/board/toradex/common/tdx-cfg-block.h
> index ea58bd43b17..b783537ce76 100644
> --- a/board/toradex/common/tdx-cfg-block.h
> +++ b/board/toradex/common/tdx-cfg-block.h
> @@ -102,6 +102,15 @@ enum {
>   VERDIN_AM62D_1G_IT,
>   VERDIN_AM62D_1G_WIFI_BT_IT, /* 75 */
>   VERDIN_AM62Q_2G_WIFI_BT_IT,
> + COLIBRI_IMX6S_NOWINCE,
> + COLIBRI_IMX6S_IT_NOWINCE,
> + COLIBRI_IMX6DL_NOWINCE,
> + COLIBRI_IMX6DL_IT_NOWINCE, /* 80 */
> + COLIBRI_IMX7D_NOWINCE,
> + APALIS_IMX6D_NOWINCE,
> + APALIS_IMX6Q_NOWINCE,
> + APALIS_IMX6D_IT_NOWINCE,
> + APALIS_IMX6Q_IT_NOWINCE, /* 85 */
>  };
>  
>  enum {


Re: Proposal: FIT support for extension boards / overlays

2024-01-22 Thread Chen-Yu Tsai
On Thu, Dec 28, 2023 at 1:49 AM Simon Glass  wrote:
>
> Hi Heinrich,
>
> On Tue, Dec 12, 2023 at 3:43 PM Heinrich Schuchardt  
> wrote:
> >
> > On 12.12.23 15:05, Simon Glass wrote:
> > > Hi,
> > >
> > > The devicetree files for a board can be quite large, perhaps around
> > > 60KB. To boot on any supported board, many of them need to be
> > > provided, typically hundreds.
> > >
> > > All boards for a particular SoC share common parts.  It would be
> > > helpful to use overlays for common pieces, to reduce the overall size.
> > >
> > > Some boards have extension add-ons which have their own devicetree
> > > overlays. It would be helpful to know which ones should be applied for
> > > a particular extension.
> > >
> > > I propose implementing extensions in FIT. This has a new '/extensions'
> > > node, so you can specify what extensions are available for each FIT
> > > configuration.
> > >
> > > For example:
> > >
> > > / {
> > >images {
> > >  kernel {
> > >// common kernel
> > >  };
> > >
> > >  fdt-1 {
> > >// FDT for board1
> > >  };
> > >
> > >  fdto-1 {
> > >// FDT overlay
> > >  };
> > >
> > >  fdto-2 {
> > >// FDT overlay
> > >  };
> > >
> > >  fdto-3 {
> > >// FDT overlay
> > >  };
> > >};
> > >
> > >configurations {
> > >  conf-1 {
> > >  compatible = ...
> > >  fdt = "fdt-1";
> > >  extensions = "ext1", "ext-2";
> >
> > Shouldn't there be braces around the item list?
>
> I don't think so.
>
> >
> > How do you specify optional and required but otherwise unrelated
> > extensions for a configuration?
>
> Do we actually need to know which extensions are required or optional?
> Do you have an example?

If an extension is required for a device, then it wouldn't be an extension
per se. The referenced DT overlay should be directly tied to the device
compatible through the configuration node.

If say "ext-3" depends on "ext-1" (assuming that is one definition of
"required"), then based on the syntax I believe "ext-3" should only
be listed in the "extensions" property under "ext-1", and not the
base configuration?

> > >  };
> > >};
> > >
> > >extensions {
> > >  ext-1 {
> > >  fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
> > >  kernel = "kernel-1";
> > >  compatible = "vendor,combined-device1";
> > >  extensions = "ext-3";
> > >  };
> > >
> > >  ext-2 {
> > >  fdto = "fdto-2";   // fdt overlay for this 'cape'
> > >  compatible = "vendor,device2";
> > >  };
> > >
> > >  ext-3 {
> > >  fdto = "fdto-3";
> > >  compatible = "vendor,device3";
> > >  };
> > >};
> > > };
> > >
> > > So FIT configurations have a list of supported extensions. The
> > > extensions are hierarchical so that you can have ext-1 which can
> > > optionally have ext-2 as well. This allows boards to share a common
> >
> > ext2 seems not to be related to ext-3. Do you mean ext-3 optionally
> > extending ext-1? How would you specify that ext-n is required for ext-m
> > to work?
>
> Yes, I mean "optionally extending ext2". Again, I don't consider
> required extensions here.

See above for my take on extension dependencies.

ChenYu

> > The sequence of applying overlays may make a difference. I cannot see
> > that your current suggestion defines a sequence in which the overlays
> > are applied.
> >
> > > SoC to add in overlays as needed by their board. It also allows common
> > > 'capes' or 'hats' to be specified only once and used by a group of
> > > boards which share the same interface.
> > >
> > > Within U-Boot, extensions actually present are declared by a sysinfo
> > > driver for the board, with new methods:
> > >
> > > get_compat() - determine the compatible strings for the current platform
> > > get_ext() - get a list of compatible strings for extensions which are
> > > actually present
> >
> > Do you expect U-Boot to have code that injects device-tree fragments
> > with a compatible string into the control FDT after discovering add-ons?
>
> Yes, that's right, by applying overlays.
>
> >
> > Why can't we simply write the compatible constraint into the overlay
> > definition (fdto-#) and enumerate the overlays in the configuration?
>
> Yes, that is the example quoted below.
>
> >
> > On some busses detection is problematic. Two alternative add-ons may use
> > the same SPI address but need different FDT overlays.
>
> If there is no way to detect the extension, then it cannot work anyway, right?
>
> BTW I am not suggesting that the bus is used for detection, although I
> suppose this is possible. More likely there are GPIOs which can be
> decoded to indicate the extension, or perhaps an I2C EEPROM.
>
>
> >
> > Best regards
> >
> > Heinrich
> >
> >
> > >
> > > The extension compatible-strings are used to select the correct things
> > > from the FIT, apply the overlays and produce the final DT.
> > >
> > > To

[PATCH] soc: zynqmp: Add the IDcode for dr_SE and eg_SE variants

2024-01-22 Thread Venkatesh Yadav Abbarapu
ID code is added for zu67dr_SE, zu11eg_SE, zu19eg_SE and zu47dr_SE
variants. SE is the select edition of restricted devices with the
capabilities.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
 drivers/soc/soc_xilinx_zynqmp.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/soc_xilinx_zynqmp.c b/drivers/soc/soc_xilinx_zynqmp.c
index d9a5944965..786825d920 100644
--- a/drivers/soc/soc_xilinx_zynqmp.c
+++ b/drivers/soc/soc_xilinx_zynqmp.c
@@ -35,13 +35,15 @@ static const char zynqmp_family[] = "ZynqMP";
 #define IDCODE2_PL_INIT_SHIFT  9
 #define IDCODE2_PL_INIT_MASK   BIT(IDCODE2_PL_INIT_SHIFT)
 
-#define ZYNQMP_VERSION_SIZE7
+#define ZYNQMP_VERSION_SIZE10
 
 enum {
ZYNQMP_VARIANT_EG = BIT(0),
ZYNQMP_VARIANT_EV = BIT(1),
ZYNQMP_VARIANT_CG = BIT(2),
ZYNQMP_VARIANT_DR = BIT(3),
+   ZYNQMP_VARIANT_DR_SE = BIT(4),
+   ZYNQMP_VARIANT_EG_SE = BIT(5),
 };
 
 struct zynqmp_device {
@@ -105,6 +107,11 @@ static const struct zynqmp_device zynqmp_devices[] = {
.device = 11,
.variants = ZYNQMP_VARIANT_EG,
},
+   {
+   .id = 0x04741093,
+   .device = 11,
+   .variants = ZYNQMP_VARIANT_EG_SE,
+   },
{
.id = 0x04750093,
.device = 15,
@@ -120,6 +127,11 @@ static const struct zynqmp_device zynqmp_devices[] = {
.device = 19,
.variants = ZYNQMP_VARIANT_EG,
},
+   {
+   .id = 0x0475C093,
+   .device = 19,
+   .variants = ZYNQMP_VARIANT_EG_SE,
+   },
{
.id = 0x047E1093,
.device = 21,
@@ -170,6 +182,11 @@ static const struct zynqmp_device zynqmp_devices[] = {
.device = 47,
.variants = ZYNQMP_VARIANT_DR,
},
+   {
+   .id = 0x047FA093,
+   .device = 47,
+   .variants = ZYNQMP_VARIANT_DR_SE,
+   },
{
.id = 0x047FB093,
.device = 48,
@@ -185,6 +202,11 @@ static const struct zynqmp_device zynqmp_devices[] = {
.device = 67,
.variants = ZYNQMP_VARIANT_DR,
},
+   {
+   .id = 0x046d7093,
+   .device = 67,
+   .variants = ZYNQMP_VARIANT_DR_SE,
+   },
{
.id = 0x04712093,
.device = 24,
@@ -271,8 +293,12 @@ static int soc_xilinx_zynqmp_detect_machine(struct udevice 
*dev, u32 idcode,
"cg" : "eg", sizeof(priv->machine));
} else if (device->variants & ZYNQMP_VARIANT_EG) {
strlcat(priv->machine, "eg", sizeof(priv->machine));
+   } else if (device->variants & ZYNQMP_VARIANT_EG_SE) {
+   strlcat(priv->machine, "eg_SE", sizeof(priv->machine));
} else if (device->variants & ZYNQMP_VARIANT_DR) {
strlcat(priv->machine, "dr", sizeof(priv->machine));
+   } else if (device->variants & ZYNQMP_VARIANT_DR_SE) {
+   strlcat(priv->machine, "dr_SE", sizeof(priv->machine));
}
 
return 0;
-- 
2.25.1



Re: Proposal: FIT support for extension boards / overlays

2024-01-22 Thread Chen-Yu Tsai
On Tue, Dec 12, 2023 at 10:06 PM Simon Glass  wrote:
>
> Hi,
>
> The devicetree files for a board can be quite large, perhaps around
> 60KB. To boot on any supported board, many of them need to be
> provided, typically hundreds.
>
> All boards for a particular SoC share common parts.  It would be
> helpful to use overlays for common pieces, to reduce the overall size.
>
> Some boards have extension add-ons which have their own devicetree
> overlays. It would be helpful to know which ones should be applied for
> a particular extension.
>
> I propose implementing extensions in FIT. This has a new '/extensions'
> node, so you can specify what extensions are available for each FIT
> configuration.
>
> For example:
>
> / {
>   images {
> kernel {
>   // common kernel
> };
>
> fdt-1 {
>   // FDT for board1
> };
>
> fdto-1 {
>   // FDT overlay
> };
>
> fdto-2 {
>   // FDT overlay
> };
>
> fdto-3 {
>   // FDT overlay
> };
>   };
>
>   configurations {
> conf-1 {
> compatible = ...
> fdt = "fdt-1";
> extensions = "ext1", "ext-2";
> };
>   };
>
>   extensions {
> ext-1 {
> fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
> kernel = "kernel-1";
> compatible = "vendor,combined-device1";

I think the example would be a bit better if the extension compatibles
were something like "vendor,device-X-feature-Y", so as not to be confused
with device-specific compatibles for the configurations.

> extensions = "ext-3";

I assume this means "existence of ext-1 makes ext-3 a valid option"?

I think a valid example would come in the form of:
- ext-1 as a M.2 E-key hat, and
- ext-3 as a WiFi/BT combo adapter for the M.2 slot, with BT UART and/or
  GPIOs described

> };
>
> ext-2 {
> fdto = "fdto-2";   // fdt overlay for this 'cape'
> compatible = "vendor,device2";
> };
>
> ext-3 {
> fdto = "fdto-3";
> compatible = "vendor,device3";
> };
>   };
> };
>
> So FIT configurations have a list of supported extensions. The
> extensions are hierarchical so that you can have ext-1 which can
> optionally have ext-2 as well. This allows boards to share a common
> SoC to add in overlays as needed by their board. It also allows common
> 'capes' or 'hats' to be specified only once and used by a group of
> boards which share the same interface.
>
> Within U-Boot, extensions actually present are declared by a sysinfo
> driver for the board, with new methods:
>
> get_compat() - determine the compatible strings for the current platform
> get_ext() - get a list of compatible strings for extensions which are
> actually present
>
> The extension compatible-strings are used to select the correct things
> from the FIT, apply the overlays and produce the final DT.
>
> To make this simpler for the common case (without extensions), we can
> allow multiple FDT images for a configuration, with the first one
> being the base SoC .dtb and the others being the .dtbo overlay(s) for
> the board:
>
> confi-1 {
> compatible = ...
> fdt = "fdt-1", "fdto-1";
> };

I thought this was already supported? At least that is what the FIT image
spec says:

Unit name of the corresponding fdt blob (component image node of a
"fdt type"). Additional fdt overlay nodes can be supplied which
signify that the resulting device tree blob is generated by the
first base fdt blob with all subsequent overlays applied.

> Comments welcome.

Very happy to see this. This could help cut down the DT duplication for
some of the ARM Chromebooks.


Thanks
ChenYu


RE: Pull request: SoCFPGA changes for commit 3c9bb8fbdc77f

2024-01-22 Thread Chee, Tien Fong
Hi Tom,

> -Original Message-
> From: Tom Rini 
> Sent: Monday, January 22, 2024 10:47 PM
> To: Chee, Tien Fong 
> Cc: u-boot@lists.denx.de; Vasut, Marek ; Maniyam,
> Dinesh ; Hea, Kok Kiang
> 
> Subject: Re: Pull request: SoCFPGA changes for commit 3c9bb8fbdc77f
> 
> On Mon, Jan 22, 2024 at 09:30:40AM +, Chee, Tien Fong wrote:
> 
> > Hi Tom,
> >
> > Please pull the SoCFPGA changes as shown in below.
> >
> > Best regards,
> > Tien Fong
> >
> > The following changes since commit
> 3c04fcf3137d5f694d52b8f355373e4baabe5f78:
> >
> >   Merge patch series "k3-j721e: beagleboneai: Fix USB" (2024-01-20
> > 11:39:13 -0500)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/tienfong/uboot_mainline.git
> > 3c9bb8fbdc77f6bd56e97597d875d8965db3b96c
> 
> Lets talk off-list about getting things moved to https://source.denx.de/u-
> boot/custodians/u-boot-socfpga/ please.

Sure.

> 
> >
> > for you to fetch changes up to
> 3c9bb8fbdc77f6bd56e97597d875d8965db3b96c:
> >
> >   arm: dts: agilex: Increase reserved memory size to 32MB (2024-01-22
> > 16:51:29 +0800)
> 
> There's a few more patches showing under:
> https://patchwork.ozlabs.org/project/uboot/list/?q=socfpga are they ready
> or need changes?

Thanks for pointing.
- Changes are needed for first item.
- Second item is already part of this pull request
- I will submit request for third item.

Best regards,
Tien Fong.


Could you please help me in resolving the " /reset.c:42:(.text.do_reset+0x20): undefined reference to `reset_cpu'?"

2024-01-22 Thread Liu Wang
Hi Fabio,

Could you please help me in resolving the " /reset.c:42:(.text.do_reset+0x20): 
undefined reference to `reset_cpu'?" from: u-boot$make all:

Sincerely,
Liu Wang
--
...$make all
  UPD include/generated/timestamp_autogenerated.h
  HOSTCC  tools/mkenvimage.o
  HOSTLD  tools/mkenvimage
  HOSTCC  tools/dumpimage.o
  HOSTLD  tools/dumpimage
  HOSTCC  tools/mkimage.o
  HOSTLD  tools/mkimage
  CC  cmd/version.o
  LD  cmd/built-in.o
  CC  common/main.o
  LD  common/built-in.o
  CC  lib/display_options.o
  LD  lib/built-in.o
  LD  u-boot
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 warning: u-boot has a LOAD segment with RWX permissions
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 arch/arm/lib/built-in.o: in function `do_reset':
/home/liuw/Downloads/u-boot/arch/arm/lib/reset.c:42:(.text.do_reset+0x20): 
undefined reference to `reset_cpu'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 arch/arm/mach-aspeed/built-in.o: in function `dram_init':
/home/liuw/Downloads/u-boot/arch/arm/mach-aspeed/ast2500/board_common.c:50:(.text.dram_init+0x24):
 undefined reference to `ram_get_info'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 arch/arm/mach-aspeed/built-in.o: in function 
`ast2500_sdrammc_ofdata_to_platdata':
/home/liuw/Downloads/u-boot/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c:395:(.text.ast2500_sdrammc_ofdata_to_platdata+0x18):
 undefined reference to `regmap_init_mem'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 
/home/liuw/Downloads/u-boot/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c:399:(.text.ast2500_sdrammc_ofdata_to_platdata+0x2c):
 undefined reference to `regmap_get_range'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 
/home/liuw/Downloads/u-boot/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c:400:(.text.ast2500_sdrammc_ofdata_to_platdata+0x3c):
 undefined reference to `regmap_get_range'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_imls_nor':
/home/liuw/Downloads/u-boot/cmd/bootm.c:390:(.text.do_imls+0x9c): undefined 
reference to `flash_info'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_reset':
/home/liuw/Downloads/u-boot/cmd/i2c.c:1960:(.text.do_i2c_reset+0xc): undefined 
reference to `i2c_init'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_probe':
/home/liuw/Downloads/u-boot/cmd/i2c.c:999:(.text.do_i2c_probe+0x5c): undefined 
reference to `i2c_probe'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_md':
/home/liuw/Downloads/u-boot/cmd/i2c.c:592:(.text.do_i2c_md+0xd0): undefined 
reference to `i2c_read'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_read':
/home/liuw/Downloads/u-boot/cmd/i2c.c:342:(.text.do_i2c_read+0x90): undefined 
reference to `i2c_read'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_mw':
/home/liuw/Downloads/u-boot/cmd/i2c.c:691:(.text.do_i2c_mw+0xc8): undefined 
reference to `i2c_write'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_write':
/home/liuw/Downloads/u-boot/cmd/i2c.c:426:(.text.do_i2c_write+0xc8): undefined 
reference to `i2c_write'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 /home/liuw/Downloads/u-boot/cmd/i2c.c:412:(.text.do_i2c_write+0x110): 
undefined reference to `i2c_write'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `do_i2c_crc':
/home/liuw/Downloads/u-boot/cmd/i2c.c:779:(.text.do_i2c_crc+0xd4): undefined 
reference to `i2c_read'
/home/liuw/armgnutoolchain132rel1x8664armnoneeabi/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-ld.bfd:
 cmd/built-in.o: in function `mod_i2c_mem':
/home/liuw/Downloa

[PATCH v2] rockchip: sdram: fix LPDDR5 bank info for sys_reg version 3

2024-01-22 Thread Kever Yang
From: YouMin Chen 

This patch add support for additional bank info used by LPDDR5.

Signed-off-by: YouMin Chen 
Signed-off-by: Kever Yang 
---

(no changes since v1)

 arch/arm/mach-rockchip/sdram.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 99ecbdc3412..0d9a0aef6f5 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -109,7 +109,14 @@ size_t rockchip_sdram_size(phys_addr_t reg)
cs0_col = 9 + (sys_reg2 >> SYS_REG_COL_SHIFT(ch) &
  SYS_REG_COL_MASK);
cs1_col = cs0_col;
-   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
+   if (dram_type == LPDDR5)
+   /* LPDDR5: 0:8bank(bk=3), 1:16bank(bk=4) */
+   bk = 3 + ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) &
+   SYS_REG_BK_MASK);
+   else
+   /* Other: 0:8bank(bk=3), 1:4bank(bk=2) */
+   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) &
+   SYS_REG_BK_MASK);
if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
  SYS_REG_CS1_COL_MASK);
-- 
2.25.1



Re: [PATCH] rockchip: sdram: fix LPDDR5 bank info for sys_reg version 3

2024-01-22 Thread Kever Yang

Hi Jonas,

On 2024/1/23 01:55, Jonas Karlman wrote:

Hi,

On 2024-01-22 08:46, Kever Yang wrote:

From: YouMin Chen 

This patch add support for additional bank info used by LPDDR5.

Signed-off-by: YouMin Chen 
Signed-off-by: Kever Yang 
---

  arch/arm/mach-rockchip/sdram.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 99ecbdc3412..d65c48bf515 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -110,6 +110,13 @@ size_t rockchip_sdram_size(phys_addr_t reg)
  SYS_REG_COL_MASK);
cs1_col = cs0_col;
bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
+   /*
+* SYS_REG_BK(Version 3):
+* 1) Except LPDDR5 0:8bank(bk=3), 1:4bank(bk=2)
+* 2) LPDDR5 0:8bank(bk=3), 1:16bank(bk=4)
+*/
+   if (version == 3 && dram_type == LPDDR5 && bk == 2)
+   bk = 4;

The version == 3 test is not really needed because dram_type cannot be
assigned to LPDDR5 (9) since the dram_type high bits is only read for
version >= 3.

Also not sure I fully like the if bk==2 then bk=4 override code style
here because the code comment do not fully match the code flow. I had to
stop and think twice on why the test was for bk==2 when it is bk bit = 1
that should result in bk=4.

Maybe we can make the code closer match the comment with something like
the following:


@@ -109,7 +109,14 @@ size_t rockchip_sdram_size(phys_addr_t reg)
cs0_col = 9 + (sys_reg2 >> SYS_REG_COL_SHIFT(ch) &
  SYS_REG_COL_MASK);
cs1_col = cs0_col;
-   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
+   if (dram_type == LPDDR5)
+   /* LPDDR5: 0:8bank(bk=3), 1:16bank(bk=4) */
+   bk = 3 + ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) &
+ SYS_REG_BK_MASK);
+   else
+   /* Other: 0:8bank(bk=3), 1:4bank(bk=2) */
+   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) &
+ SYS_REG_BK_MASK);


This is better to understand, LPDDR5 has different bank definition with 
other type dram.


Thanks,

- Kever


if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
  SYS_REG_CS1_COL_MASK);


or possible use of a conditional operator:


@@ -109,7 +109,13 @@ size_t rockchip_sdram_size(phys_addr_t reg)
cs0_col = 9 + (sys_reg2 >> SYS_REG_COL_SHIFT(ch) &
  SYS_REG_COL_MASK);
cs1_col = cs0_col;
-   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
+   /*
+* SYS_REG_BK:
+* LPDDR5: 0:8bank(bk=3), 1:16bank(bk=4)
+* Other: 0:8bank(bk=3), 1:4bank(bk=2)
+*/
+   bk = (sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK;
+   bk = (dram_type == LPDDR5) ? 3 + bk : 3 - bk;
if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
  SYS_REG_CS1_COL_MASK);


Not sure any of the above suggestions makes the code any easier to
understand.

Regards,
Jonas


if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
  SYS_REG_CS1_COL_MASK);


Re: Could you please help me in resolving the " /reset.c:42:(.text.do_reset+0x20): undefined reference to `reset_cpu'?"

2024-01-22 Thread Fabio Estevam
Hi Liu Wang,

On Mon, Jan 22, 2024 at 10:55 PM Liu Wang  wrote:
>
> Hi Fabio,
>
> Could you please help me in resolving the " 
> /reset.c:42:(.text.do_reset+0x20): undefined reference to `reset_cpu'?" from: 
> u-boot$make all:

Looking at the errors below, there are several errors besides the reset_cpu one.

As you are using an out-of-tree U-Boot, there is not much the U-Boot
community can do to help you, sorry.

You need to get assistance from the U-Boot provider that you are using.


Re: [PATCH v2] rockchip: spl: Enable caches to speed up checksum validation

2024-01-22 Thread Kever Yang

Hi Jonas,

On 2024/1/23 02:16, Jonas Karlman wrote:

FIT checksum validation is very slow in SPL due to D-cache not being
enabled.

Enable caches in SPL to speed up FIT checksum validation, from seconds
to milliseconds.

This change enables caches in SPL on all Rockchip boards, the Kconfig
options SPL_SYS_ICACHE_OFF and SPL_SYS_DCACHE_OFF can be enabled to
disable caches for a specific board or SoC if needed.
It should invalidate cache before go to next stage, but the U-Boot 
proper and SPL
are using different memory area and U-Boot calls cleanup_before_linux() 
at last,

this patch should be safe in current code structure.

Reviewed-by: Kever Yang 

Thanks,
- Kever



Signed-off-by: Jonas Karlman 
---
Changes in v2:
- None

This has been tested on multiple RK3288, RK3328, RK3399, RK356x and
RK3588 boards without any issues, vendor U-Boot also enables caches in
SPL for all SoCs.

Link to RFC: https://patchwork.ozlabs.org/patch/1802303/
---
  arch/arm/mach-rockchip/spl.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 87280e2ba7cc..e29c841100c8 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -136,6 +136,10 @@ void board_init_f(ulong dummy)
}
gd->ram_top = gd->ram_base + get_effective_memsize();
gd->ram_top = board_get_usable_ram_top(gd->ram_size);
+   gd->relocaddr = gd->ram_top;
+
+   arch_reserve_mmu();
+   enable_caches();
  #endif
preloader_console_init();
  }


Re: [PATCH 3/5] board: rockchip: Add Sonoff iHost board

2024-01-22 Thread Tim Lunn

Hi Tom,

On 1/23/24 02:36, Tom Rini wrote:

On Mon, Jan 22, 2024 at 11:46:01PM +1100, Tim Lunn wrote:


Sonoff iHost is gateway device designed to provide a Smart Home Hub,
it is based on Rockchip RV1126. There is also a version with 2GB RAM
based off the RV1109 dual core SoC however this works with the same
config as the RV1126 for uboot purposes.

[snip]

diff --git a/include/configs/sonoff-ihost.h b/include/configs/sonoff-ihost.h
new file mode 100644
index 00..8ed5d78687
--- /dev/null
+++ b/include/configs/sonoff-ihost.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef __SONOFF_IHOST_H
+#define __SONOFF_IHOST_H
+
+#define ROCKCHIP_DEVICE_SETTINGS \
+   "stdout=serial\0" \
+   "stderr=serial\0"
+
+#include 
+
+#undef BOOT_TARGET_DEVICES
+
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1)
+
+#endif /*  __SONOFF_IHOST_H */

We should be using standard boot, which removes most of this, thanks.

Thanks for the tip, I will check this out and fix for v2.

Regards
   Tim




[PATCH] sunxi: dram: h6: fix the unreliability related to the DDR3 sequence

2024-01-22 Thread patrick9876
From: Patrick Lerda 

Indeed, the DDR3 has a non-zero probability to not be properly
initialized. This could be the PLL that is not locked or anything else.
When this happens and the code tests the correct board configuration,
the proper board configuration is not set. The board could end with
half the expected memory size, or u-boot could stall.

This change adds a loop to execute the DDR3 sequence again until the
stable state is reached.

My H6 TX6 board was prone to this issue. Once fixed with this change,
the same board can now handle 1+ consecutive reboots properly.

Fixes: ec9cdaaa13d ("sunxi: dram: h6: Improve DDR3 config detection")
Signed-off-by: Patrick Lerda 
---
 arch/arm/mach-sunxi/dram_sun50i_h6.c | 207 ++-
 1 file changed, 111 insertions(+), 96 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index 62bc2a0231..462adb1c9e 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -420,116 +420,131 @@ static bool mctl_channel_init(struct dram_para *para)
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
struct sunxi_mctl_phy_reg * const mctl_phy =
(struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
-   int i;
+   int i, j = 0;
u32 val;
 
-   setbits_le32(&mctl_ctl->dfiupd[0], BIT(31) | BIT(30));
-   setbits_le32(&mctl_ctl->zqctl[0], BIT(31) | BIT(30));
-   writel(0x2f05, &mctl_ctl->sched[0]);
-   setbits_le32(&mctl_ctl->rfshctl3, BIT(0));
-   setbits_le32(&mctl_ctl->dfimisc, BIT(0));
-   setbits_le32(&mctl_ctl->unk_0x00c, BIT(8));
-   clrsetbits_le32(&mctl_phy->pgcr[1], 0x180, 0xc0);
-   /* TODO: non-LPDDR3 types */
-   clrsetbits_le32(&mctl_phy->pgcr[2], GENMASK(17, 0), ns_to_t(7800));
-   clrbits_le32(&mctl_phy->pgcr[6], BIT(0));
-   clrsetbits_le32(&mctl_phy->dxccr, 0xee0, 0x220);
-   /* TODO: VT compensation */
-   clrsetbits_le32(&mctl_phy->dsgcr, BIT(0), 0x440060);
-   clrbits_le32(&mctl_phy->vtcr[1], BIT(1));
-
-   for (i = 0; i < 4; i++)
-   clrsetbits_le32(&mctl_phy->dx[i].gcr[0], 0xe00, 0x800);
-   for (i = 0; i < 4; i++)
-   clrsetbits_le32(&mctl_phy->dx[i].gcr[2], 0x, 0x);
-   for (i = 0; i < 4; i++)
-   clrsetbits_le32(&mctl_phy->dx[i].gcr[3], 0x3030, 0x1010);
-
-   udelay(100);
+   do {
+   setbits_le32(&mctl_ctl->dfiupd[0], BIT(31) | BIT(30));
+   setbits_le32(&mctl_ctl->zqctl[0], BIT(31) | BIT(30));
+   writel(0x2f05, &mctl_ctl->sched[0]);
+   setbits_le32(&mctl_ctl->rfshctl3, BIT(0));
+   setbits_le32(&mctl_ctl->dfimisc, BIT(0));
+   setbits_le32(&mctl_ctl->unk_0x00c, BIT(8));
+   clrsetbits_le32(&mctl_phy->pgcr[1], 0x180, 0xc0);
+   /* TODO: non-LPDDR3 types */
+   clrsetbits_le32(&mctl_phy->pgcr[2], GENMASK(17, 0),
+   ns_to_t(7800));
+   clrbits_le32(&mctl_phy->pgcr[6], BIT(0));
+   clrsetbits_le32(&mctl_phy->dxccr, 0xee0, 0x220);
+   /* TODO: VT compensation */
+   clrsetbits_le32(&mctl_phy->dsgcr, BIT(0), 0x440060);
+   clrbits_le32(&mctl_phy->vtcr[1], BIT(1));
 
-   if (para->ranks == 2)
-   setbits_le32(&mctl_phy->dtcr[1], 0x3);
-   else
-   clrsetbits_le32(&mctl_phy->dtcr[1], 0x3, 0x1);
+   for (i = 0; i < 4; i++)
+   clrsetbits_le32(&mctl_phy->dx[i].gcr[0], 0xe00, 0x800);
+   for (i = 0; i < 4; i++)
+   clrsetbits_le32(&mctl_phy->dx[i].gcr[2], 0x,
+   0x);
+   for (i = 0; i < 4; i++)
+   clrsetbits_le32(&mctl_phy->dx[i].gcr[3], 0x3030,
+   0x1010);
 
-   if (sunxi_dram_is_lpddr(para->type))
-   clrbits_le32(&mctl_phy->dtcr[1], BIT(1));
-   if (para->ranks == 2) {
-   writel(0x00010001, &mctl_phy->rankidr);
-   writel(0x2, &mctl_phy->odtcr);
-   } else {
-   writel(0x0, &mctl_phy->rankidr);
-   writel(0x1, &mctl_phy->odtcr);
-   }
+   udelay(100);
 
-   /* set bits [3:0] to 1? 0 not valid in ZynqMP d/s */
-   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
-   clrsetbits_le32(&mctl_phy->dtcr[0], 0xF000, 0x1040);
-   else
-   clrsetbits_le32(&mctl_phy->dtcr[0], 0xF000, 0x1000);
-   if (para->clk <= 792) {
-   if (para->clk <= 672) {
-   if (para->clk <= 600)
-   val = 0x300;
-   else
-   val = 0x400;
+   if (para->ranks == 2)
+   setbits_le32(&mctl_phy->dtcr[1], 0x3);
+  

Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot

2024-01-22 Thread Andre Przywara
On Mon, 22 Jan 2024 11:49:59 -0500
Tom Rini  wrote:

Hi Tom,

> On Mon, Jan 22, 2024 at 11:45:15AM +, Andre Przywara wrote:
> > On Wed, 10 Jan 2024 16:05:36 +0530
> > Sumit Garg  wrote:
> > 
> > Hi,
> > 
> > I certainly welcome this more automatic synchronisation of the DTs,
> > however have one comment about the upcoming sync process:
> >   
> > > ...
> > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather
> > > use devicetree-rebasing repo [3] which is a forked copy from Linux
> > > kernel for DT source files as well as bindings. It is tagged at every
> > > Linux kernel major release or intermideate release candidates. So here I
> > > have tried to reuse that to bring DT bingings compliance as well as a
> > > standard way to maintain a regular sync of DT source files with Linux
> > > kernel.
> > > 
> > > In order to maintain devicetree files sync, U-Boot will maintains a Git
> > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory.
> > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next 
> > > window
> > > opens with the next available kernel major release.  
> > 
> > I hope this doesn't need to stay that restricted? Can we either sync more
> > often, or at least on the kernel's -rc1, and not only on a "full" release?
> > 
> > The reason I ask is that we have a chicken-egg problem here: without a DT
> > merged into the kernel tree, no U-Boot board support can be merged. And
> > without U-Boot support, we cannot boot a kernel, at least not in the
> > canonical way.
> > 
> > Since the U-Boot and kernel merge windows are not in phase, for sunxi I try
> > to sync the kernel DTs either as early as possible (-rc1, sometimes even
> > before, when the maintainers have merged them into their tree), or
> > sometimes "out of season", if a board defconfig patch is coming up.
> > 
> > Otherwise new board support, which typically has a very low regression risk
> > for the rest of the code base, would need to be delayed until the next
> > release. In the worst case the U-Boot merge windows opens one week before
> > a kernel release, then new boards need to wait three months?  
> 
> Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot
> release, and then with the next one switch to OF_UPSTREAM=y (and delete
> the dts from arch/) for the next release, when we would have gotten back
> in sync?

Ah, I didn't look into the actual patches, but if this provision is
there, that sounds surely acceptable. It might still be good to sync
earlier than the .0 kernel release: if it appears in Linus' tree, it
had already seen a good share of review and testing. And with the
U-Boot releases being always further away than the next kernel release,
we could pull fixes still in time. So we could pick the latest -rc (or
.0 release, whichever is more recent) when the U-Boot merge window
opens?

Cheers,
Andre


Fwd: New Defects reported by Coverity Scan for Das U-Boot

2024-01-22 Thread Tom Rini
I've now updated to the latest Coverity scan tool and that eliminated
some previous defects and found two new ones:

-- Forwarded message -
From: 
Date: Mon, Jan 22, 2024 at 6:42 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To: 


Hi,

Please find the latest report on new defect(s) introduced to Das
U-Boot found with Coverity Scan.

2 new defect(s) introduced to Das U-Boot found with Coverity Scan.
8 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)


** CID 478862:  Memory - corruptions  (OVERRUN)



*** CID 478862:  Memory - corruptions  (OVERRUN)
/lib/initcall.c: 82 in initcall_run_list()
76  if (ret) {
77  if (CONFIG_IS_ENABLED(EVENT)) {
78  char buf[60];
79
80  /* don't worry about buf size as we are dying here */
81  if (type) {
>>> CID 478862:  Memory - corruptions  (OVERRUN)
>>> Overrunning callee's array of size 15 by passing argument "type" (which 
>>> evaluates to 255) in call to "event_type_name".
82  sprintf(buf, "event %d/%s", type,
83  event_type_name(type));
84  } else {
85  sprintf(buf, "call %p", func);
86  }
87

** CID 478861:  Memory - corruptions  (OVERRUN)



*** CID 478861:  Memory - corruptions  (OVERRUN)
/cmd/nvedit.c: 356 in print_static_flags()
350 static int print_static_flags(const char *var_name, const char *flags,
351   void *priv)
352 {
353 enum env_flags_vartype type = env_flags_parse_vartype(flags);
354 enum env_flags_varaccess access =
env_flags_parse_varaccess(flags);
355
>>> CID 478861:  Memory - corruptions  (OVERRUN)
>>> Overrunning callee's array of size 4 by passing argument "access" 
>>> (which evaluates to 4) in call to "env_flags_get_varaccess_name".
356 printf("\t%-20s %-20s %-20s\n", var_name,
357 env_flags_get_vartype_name(type),
358 env_flags_get_varaccess_name(access));
359
360 return 0;
361 }

-- 
Tom


signature.asc
Description: PGP signature


Fwd: New Defects reported by Coverity Scan for Das U-Boot

2024-01-22 Thread Tom Rini
Hey all,

Here's the latest Coverity scan report.

-- Forwarded message -
From: 
Date: Mon, Jan 22, 2024 at 6:26 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To: 


Hi,

Please find the latest report on new defect(s) introduced to Das
U-Boot found with Coverity Scan.

1 new defect(s) introduced to Das U-Boot found with Coverity Scan.
7 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 478860:  Code maintainability issues  (UNUSED_VALUE)
/tools/image-host.c: 359 in fit_image_read_key_iv_data()



*** CID 478860:  Code maintainability issues  (UNUSED_VALUE)
/tools/image-host.c: 359 in fit_image_read_key_iv_data()
353 if (ret >= sizeof(filename)) {
354 printf("Can't format the key or IV filename
when setting up the cipher: insufficient buffer space\n");
355 ret = -1;
356 }
357 if (ret < 0) {
358 printf("Can't format the key or IV filename
when setting up the cipher: snprintf error\n");
>>> CID 478860:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value "-1" to "ret" here, but that stored value is 
>>> overwritten before it can be used.
359 ret = -1;
360 }
361
362 ret = fit_image_read_data(filename, key_iv_data, expected_size);
363
364 return ret;


- End forwarded message -

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 16/16] Kconfig: Centralize prompting for SYS_CONFIG_NAME

2024-01-22 Thread Tom Rini
Generally speaking, we do not prompt for this value and define it in the
board specific Kconfig file. There are some valid use cases however
today where we do prompt for this value, so instead of having this be
done in a number of locations, do this at the top-level location only.

This removes the question from a number of other locations and makes it
consistent that when we do set the value directly, we always do it the
same way. We don't need to specify the type, it's always string.

Signed-off-by: Tom Rini 
---
 arch/Kconfig| 11 ++-
 arch/arm/mach-mediatek/Kconfig  |  6 --
 arch/arm/mach-meson/Kconfig |  8 
 arch/arm/mach-versal-net/Kconfig|  8 
 arch/arm/mach-versal/Kconfig|  8 
 arch/arm/mach-zynq/Kconfig  |  8 
 arch/arm/mach-zynqmp-r5/Kconfig |  8 
 arch/arm/mach-zynqmp/Kconfig|  8 
 arch/mips/mach-mtmips/mt7620/Kconfig|  1 -
 arch/mips/mach-mtmips/mt7621/Kconfig|  1 -
 arch/mips/mach-mtmips/mt7628/Kconfig|  1 -
 arch/nios2/Kconfig  |  7 ---
 board/Marvell/octeon_ebb7304/Kconfig|  1 -
 board/Marvell/octeon_nic23/Kconfig  |  1 -
 board/cadence/xtfpga/Kconfig|  1 -
 board/cavium/thunderx/Kconfig   |  1 -
 board/freescale/imxrt1020-evk/Kconfig   |  1 -
 board/freescale/imxrt1050-evk/Kconfig   |  1 -
 board/freescale/imxrt1170-evk/Kconfig   |  1 -
 board/kontron/sl-mx6ul/Kconfig  |  1 -
 board/kontron/sl-mx8mm/Kconfig  |  1 -
 board/samsung/starqltechn/Kconfig   |  8 
 board/st/stih410-b2260/Kconfig  |  1 -
 board/st/stm32f429-discovery/Kconfig|  1 -
 board/st/stm32f429-evaluation/Kconfig   |  1 -
 board/st/stm32f469-discovery/Kconfig|  1 -
 board/st/stm32f746-disco/Kconfig|  1 -
 board/st/stm32h743-disco/Kconfig|  1 -
 board/st/stm32h743-eval/Kconfig |  1 -
 board/st/stm32h750-art-pi/Kconfig   |  1 -
 board/sysam/amcore/Kconfig  |  1 -
 board/xilinx/microblaze-generic/Kconfig |  8 
 32 files changed, 10 insertions(+), 99 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index b6fb9e927337..0d3cce919f8f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -361,7 +361,16 @@ config SYS_BOARD
  leave this option empty.
 
 config SYS_CONFIG_NAME
-   string
+   string "Board header file" if ARCH_MESON || ARCH_VERSAL || \
+   ARCH_VERSAL_NET || ARCH_ZYNQ || ARCH_ZYNQMP || \
+   ARCH_ZYNQMP_R5 || MICROBLAZE || NIOS2
+   default "meson64" if ARCH_MESON
+   default "microblaze-generic" if MICROBLAZE
+   default "xilinx_versal" if ARCH_VERSAL
+   default "xilinx_versal_net" if ARCH_VERSAL_NET
+   default "xilinx_zynqmp" if ARCH_ZYNQMP
+   default "xilinx_zynqmp_r5" if ARCH_ZYNQMP_R5
+   default "zynq-common" if ARCH_ZYNQ
help
  This option should contain the base name of board header file.
  The header file include/configs/.h
diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index c3872f428697..82018bd9d3e3 100644
--- a/arch/arm/mach-mediatek/Kconfig
+++ b/arch/arm/mach-mediatek/Kconfig
@@ -133,7 +133,6 @@ config SYS_BOARD
  be used.
 
 config SYS_CONFIG_NAME
-   string "Board configuration name"
default "mt7622" if TARGET_MT7622
default "mt7623" if TARGET_MT7623
default "mt7629" if TARGET_MT7629
@@ -145,11 +144,6 @@ config SYS_CONFIG_NAME
default "mt8512" if TARGET_MT8512
default "mt8516" if TARGET_MT8516
default "mt8518" if TARGET_MT8518
-   default ""
-   help
- This option contains information about board configuration name.
- Based on this option include/configs/.h header
- will be used for board configuration.
 
 config MTK_BROM_HEADER_INFO
string
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index d6c890580617..6e6f9c13f17d 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -88,12 +88,4 @@ config SYS_BOARD
  Based on this option board// will
  be used.
 
-config SYS_CONFIG_NAME
-   string "Board configuration name"
-   default "meson64"
-   help
- This option contains information about board configuration name.
- Based on this option include/configs/.h header
- will be used for board configuration.
-
 endif
diff --git a/arch/arm/mach-versal-net/Kconfig b/arch/arm/mach-versal-net/Kconfig
index edff5b039e91..1b5339993f83 100644
--- a/arch/arm/mach-versal-net/Kconfig
+++ b/arch/arm/mach-versal-net/Kconfig
@@ -13,14 +13,6 @@ config SYS_VENDOR
 config SYS_SOC
default "versal-net"
 
-config SYS_CONFIG_NAME
-   string "Board configuration name"
-   default "xilinx_versal_net"
-   help
- This option contains information about board configuration name.
-  

[PATCH 15/16] hc2910-2aghd05: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the hc2910-2aghd05 platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Yang Xiwen 
---
 board/skyworth/hc2910-2aghd05/Kconfig | 3 ---
 board/skyworth/hc2910-2aghd05/MAINTAINERS | 1 -
 include/configs/hc2910-2aghd05.h  | 6 --
 3 files changed, 10 deletions(-)
 delete mode 100644 include/configs/hc2910-2aghd05.h

diff --git a/board/skyworth/hc2910-2aghd05/Kconfig 
b/board/skyworth/hc2910-2aghd05/Kconfig
index f85f1f2631de..620a3177f488 100644
--- a/board/skyworth/hc2910-2aghd05/Kconfig
+++ b/board/skyworth/hc2910-2aghd05/Kconfig
@@ -9,7 +9,4 @@ config SYS_VENDOR
 config SYS_SOC
default "hi3798mv200"
 
-config SYS_CONFIG_NAME
-   default "hc2910-2aghd05"
-
 endif
diff --git a/board/skyworth/hc2910-2aghd05/MAINTAINERS 
b/board/skyworth/hc2910-2aghd05/MAINTAINERS
index 2c1e750018e1..13915556bc5e 100644
--- a/board/skyworth/hc2910-2aghd05/MAINTAINERS
+++ b/board/skyworth/hc2910-2aghd05/MAINTAINERS
@@ -2,5 +2,4 @@ HC2910 2AGHD05 BOARD
 M: Yang Xiwen 
 S: Maintained
 F: board/skyworth/hc2910-2aghd05
-F: include/configs/hc2910-2aghd05.h
 F: configs/hc2910_2aghd05_defconfig
diff --git a/include/configs/hc2910-2aghd05.h b/include/configs/hc2910-2aghd05.h
deleted file mode 100644
index 3db9a474ec7f..
--- a/include/configs/hc2910-2aghd05.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-
-#ifndef __HC2910_2AGHD05_CONFIG_H__
-#define __HC2910_2AGHD05_CONFIG_H__
-
-#endif
-- 
2.34.1



[PATCH 14/16] slimbootloader: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the slimbootloader platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Aiden Park 
---
 board/intel/slimbootloader/Kconfig | 3 ---
 board/intel/slimbootloader/MAINTAINERS | 1 -
 include/configs/slimbootloader.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/slimbootloader.h

diff --git a/board/intel/slimbootloader/Kconfig 
b/board/intel/slimbootloader/Kconfig
index 015ed51dc89c..11e6cb37bd85 100644
--- a/board/intel/slimbootloader/Kconfig
+++ b/board/intel/slimbootloader/Kconfig
@@ -13,9 +13,6 @@ config SYS_VENDOR
 config SYS_SOC
default "slimbootloader"
 
-config SYS_CONFIG_NAME
-   default "slimbootloader"
-
 config TEXT_BASE
default 0x0010
 
diff --git a/board/intel/slimbootloader/MAINTAINERS 
b/board/intel/slimbootloader/MAINTAINERS
index e6935517e01a..0208a382ac6b 100644
--- a/board/intel/slimbootloader/MAINTAINERS
+++ b/board/intel/slimbootloader/MAINTAINERS
@@ -2,5 +2,4 @@ Intel Slim Bootloader Payload
 M: Aiden Park 
 S: Maintained
 F: board/intel/slimbootloader
-F: include/configs/slimbootloader.h
 F: configs/slimbootloader_defconfig
diff --git a/include/configs/slimbootloader.h b/include/configs/slimbootloader.h
deleted file mode 100644
index 85f6a968e040..
--- a/include/configs/slimbootloader.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2019 Intel Corporation 
- */
-- 
2.34.1



[PATCH 13/16] qemu-x86*: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the qemu-x86* platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/emulation/qemu-x86/Kconfig | 3 ---
 board/emulation/qemu-x86/MAINTAINERS | 2 --
 include/configs/qemu-x86.h   | 4 
 3 files changed, 9 deletions(-)
 delete mode 100644 include/configs/qemu-x86.h

diff --git a/board/emulation/qemu-x86/Kconfig b/board/emulation/qemu-x86/Kconfig
index 01dc1d497aec..9a0611820ce1 100644
--- a/board/emulation/qemu-x86/Kconfig
+++ b/board/emulation/qemu-x86/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "qemu"
 
-config SYS_CONFIG_NAME
-   default "qemu-x86"
-
 config TEXT_BASE
default 0xfff0 if !SUPPORT_SPL
default 0x0111 if SUPPORT_SPL
diff --git a/board/emulation/qemu-x86/MAINTAINERS 
b/board/emulation/qemu-x86/MAINTAINERS
index e62585a65d7d..efb8b46daaf4 100644
--- a/board/emulation/qemu-x86/MAINTAINERS
+++ b/board/emulation/qemu-x86/MAINTAINERS
@@ -3,7 +3,6 @@ M:  Bin Meng 
 S: Maintained
 F: board/emulation/qemu-x86/
 F: board/emulation/common/
-F: include/configs/qemu-x86.h
 F: configs/qemu-x86_defconfig
 
 QEMU X86 64-bit BOARD
@@ -11,5 +10,4 @@ M:Bin Meng 
 S: Maintained
 F: board/emulation/qemu-x86/
 F: board/emulation/common/
-F: include/configs/qemu-x86.h
 F: configs/qemu-x86_64_defconfig
diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
deleted file mode 100644
index 9b0f5cedcd79..
--- a/include/configs/qemu-x86.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2015, Bin Meng 
- */
-- 
2.34.1



[PATCH 12/16] minnowmax: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the minnowmax platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Simon Glass 
---
 board/intel/minnowmax/Kconfig | 3 ---
 board/intel/minnowmax/MAINTAINERS | 1 -
 include/configs/minnowmax.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/minnowmax.h

diff --git a/board/intel/minnowmax/Kconfig b/board/intel/minnowmax/Kconfig
index a03ef8678014..abb1d45ff614 100644
--- a/board/intel/minnowmax/Kconfig
+++ b/board/intel/minnowmax/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "baytrail"
 
-config SYS_CONFIG_NAME
-   default "minnowmax"
-
 config TEXT_BASE
default 0xfff0
 
diff --git a/board/intel/minnowmax/MAINTAINERS 
b/board/intel/minnowmax/MAINTAINERS
index d655761d5783..5cb94b0f36c6 100644
--- a/board/intel/minnowmax/MAINTAINERS
+++ b/board/intel/minnowmax/MAINTAINERS
@@ -2,5 +2,4 @@ CircuitCo Minnowboard Max
 M: Simon Glass 
 S: Maintained
 F: board/intel/minnowmax
-F: include/configs/minnowmax.h
 F: configs/minnowmax_defconfig
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
deleted file mode 100644
index 068a2af2c1fc..
--- a/include/configs/minnowmax.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2015 Google, Inc
- */
-- 
2.34.1



[PATCH 11/16] galileo: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the galileo platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/intel/galileo/Kconfig | 3 ---
 board/intel/galileo/MAINTAINERS | 1 -
 include/configs/galileo.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/galileo.h

diff --git a/board/intel/galileo/Kconfig b/board/intel/galileo/Kconfig
index 4c0451da48da..15c8d1254089 100644
--- a/board/intel/galileo/Kconfig
+++ b/board/intel/galileo/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "quark"
 
-config SYS_CONFIG_NAME
-   default "galileo"
-
 config TEXT_BASE
default 0xfff1
 
diff --git a/board/intel/galileo/MAINTAINERS b/board/intel/galileo/MAINTAINERS
index dbbc82e8a1db..a5dcde7ad09d 100644
--- a/board/intel/galileo/MAINTAINERS
+++ b/board/intel/galileo/MAINTAINERS
@@ -2,5 +2,4 @@ INTEL GALILEO BOARD
 M: Bin Meng 
 S: Maintained
 F: board/intel/galileo/
-F: include/configs/galileo.h
 F: configs/galileo_defconfig
diff --git a/include/configs/galileo.h b/include/configs/galileo.h
deleted file mode 100644
index 9b0f5cedcd79..
--- a/include/configs/galileo.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2015, Bin Meng 
- */
-- 
2.34.1



[PATCH 10/16] efi-x86_payload: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the efi-x86_payload* platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Simon Glass 
Cc: Heinrich Schuchardt 
---
 board/efi/efi-x86_payload/Kconfig | 3 ---
 board/efi/efi-x86_payload/MAINTAINERS | 1 -
 include/configs/efi-x86_payload.h | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/efi-x86_payload.h

diff --git a/board/efi/efi-x86_payload/Kconfig 
b/board/efi/efi-x86_payload/Kconfig
index 6d062499346d..c500ca02ebf5 100644
--- a/board/efi/efi-x86_payload/Kconfig
+++ b/board/efi/efi-x86_payload/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "efi"
 
-config SYS_CONFIG_NAME
-   default "efi-x86_payload"
-
 config TEXT_BASE
default 0x0020
 
diff --git a/board/efi/efi-x86_payload/MAINTAINERS 
b/board/efi/efi-x86_payload/MAINTAINERS
index d795d60e09e4..3c5d48aa84cc 100644
--- a/board/efi/efi-x86_payload/MAINTAINERS
+++ b/board/efi/efi-x86_payload/MAINTAINERS
@@ -3,6 +3,5 @@ M:  Bin Meng 
 S: Maintained
 F: board/efi/Kconfig
 F: board/efi/efi-x86_payload/
-F: include/configs/efi-x86_payload.h
 F: configs/efi-x86_payload32_defconfig
 F: configs/efi-x86_payload64_defconfig
diff --git a/include/configs/efi-x86_payload.h 
b/include/configs/efi-x86_payload.h
deleted file mode 100644
index e00c408f29a5..
--- a/include/configs/efi-x86_payload.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2018, Bin Meng 
- */
-- 
2.34.1



[PATCH 09/16] efi-x86_app: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the efi-x86_app* platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Simon Glass 
Cc: Heinrich Schuchardt 
---
 board/efi/efi-x86_app/Kconfig | 3 ---
 board/efi/efi-x86_app/MAINTAINERS | 2 --
 include/configs/efi-x86_app.h | 4 
 3 files changed, 9 deletions(-)
 delete mode 100644 include/configs/efi-x86_app.h

diff --git a/board/efi/efi-x86_app/Kconfig b/board/efi/efi-x86_app/Kconfig
index ecd08d73146a..f9cbef0a864c 100644
--- a/board/efi/efi-x86_app/Kconfig
+++ b/board/efi/efi-x86_app/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "efi"
 
-config SYS_CONFIG_NAME
-   default "efi-x86_app"
-
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
imply VIDEO_EFI
diff --git a/board/efi/efi-x86_app/MAINTAINERS 
b/board/efi/efi-x86_app/MAINTAINERS
index 584619c51dff..693f367311bc 100644
--- a/board/efi/efi-x86_app/MAINTAINERS
+++ b/board/efi/efi-x86_app/MAINTAINERS
@@ -3,7 +3,6 @@ M:  Simon Glass 
 S: Maintained
 F: board/efi/Kconfig
 F: board/efi/efi-x86_app/
-F: include/configs/efi-x86_app.h
 F: configs/efi-x86_app32_defconfig
 
 EFI-X86_APP64 BOARD
@@ -11,5 +10,4 @@ M:Simon Glass 
 S: Maintained
 F: board/efi/Kconfig
 F: board/efi/efi-x86_app/
-F: include/configs/efi-x86_app.h
 F: configs/efi-x86_app64_defconfig
diff --git a/include/configs/efi-x86_app.h b/include/configs/efi-x86_app.h
deleted file mode 100644
index d5824049d697..
--- a/include/configs/efi-x86_app.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (c) 2015 Google, Inc
- */
-- 
2.34.1



[PATCH 08/16] edison: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the edison platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Andy Shevchenko 
---
 board/intel/edison/Kconfig | 3 ---
 board/intel/edison/MAINTAINERS | 1 -
 include/configs/edison.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/edison.h

diff --git a/board/intel/edison/Kconfig b/board/intel/edison/Kconfig
index 5efda4b3a554..daa8d2035cd5 100644
--- a/board/intel/edison/Kconfig
+++ b/board/intel/edison/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "tangier"
 
-config SYS_CONFIG_NAME
-   default "edison"
-
 config SYS_MALLOC_LEN
default 0x0800
 
diff --git a/board/intel/edison/MAINTAINERS b/board/intel/edison/MAINTAINERS
index 4bc4a00c8ad8..26b27c5dfe15 100644
--- a/board/intel/edison/MAINTAINERS
+++ b/board/intel/edison/MAINTAINERS
@@ -2,5 +2,4 @@ Intel Edison Board
 M: Andy Shevchenko 
 S: Maintained
 F: board/intel/edison
-F: include/configs/edison.h
 F: configs/edison_defconfig
diff --git a/include/configs/edison.h b/include/configs/edison.h
deleted file mode 100644
index 127c2c4546e0..
--- a/include/configs/edison.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (c) 2017 Intel Corp.
- */
-- 
2.34.1



[PATCH 07/16] crownbay: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the crownbay platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/intel/crownbay/Kconfig | 3 ---
 board/intel/crownbay/MAINTAINERS | 1 -
 include/configs/crownbay.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/crownbay.h

diff --git a/board/intel/crownbay/Kconfig b/board/intel/crownbay/Kconfig
index eb2290cfafbe..09614ab8d155 100644
--- a/board/intel/crownbay/Kconfig
+++ b/board/intel/crownbay/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "queensbay"
 
-config SYS_CONFIG_NAME
-   default "crownbay"
-
 config TEXT_BASE
default 0xfff0
 
diff --git a/board/intel/crownbay/MAINTAINERS b/board/intel/crownbay/MAINTAINERS
index 1eb68693df3e..e2d8e6bc1d0d 100644
--- a/board/intel/crownbay/MAINTAINERS
+++ b/board/intel/crownbay/MAINTAINERS
@@ -2,5 +2,4 @@ INTEL CROWNBAY BOARD
 M: Bin Meng 
 S: Maintained
 F: board/intel/crownbay/
-F: include/configs/crownbay.h
 F: configs/crownbay_defconfig
diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
deleted file mode 100644
index 0c842dd01ebe..
--- a/include/configs/crownbay.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2014, Bin Meng 
- */
-- 
2.34.1



[PATCH 06/16] cougarcanyon2: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the cougarcanyon2 platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/intel/cougarcanyon2/Kconfig | 3 ---
 board/intel/cougarcanyon2/MAINTAINERS | 1 -
 include/configs/cougarcanyon2.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/cougarcanyon2.h

diff --git a/board/intel/cougarcanyon2/Kconfig 
b/board/intel/cougarcanyon2/Kconfig
index 32407025bc16..841e041167e8 100644
--- a/board/intel/cougarcanyon2/Kconfig
+++ b/board/intel/cougarcanyon2/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "ivybridge"
 
-config SYS_CONFIG_NAME
-   default "cougarcanyon2"
-
 config TEXT_BASE
default 0xffe0
 
diff --git a/board/intel/cougarcanyon2/MAINTAINERS 
b/board/intel/cougarcanyon2/MAINTAINERS
index a486739b5eea..a4f465cf5df3 100644
--- a/board/intel/cougarcanyon2/MAINTAINERS
+++ b/board/intel/cougarcanyon2/MAINTAINERS
@@ -2,5 +2,4 @@ INTEL COUGAR CANYON 2 BOARD
 M: Bin Meng 
 S: Maintained
 F: board/intel/cougarcanyon2/
-F: include/configs/cougarcanyon2.h
 F: configs/cougarcanyon2_defconfig
diff --git a/include/configs/cougarcanyon2.h b/include/configs/cougarcanyon2.h
deleted file mode 100644
index 0406786f7c66..
--- a/include/configs/cougarcanyon2.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2016, Bin Meng 
- */
-- 
2.34.1



[PATCH 05/16] cherryhill: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the cherryhill platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/intel/cherryhill/Kconfig | 3 ---
 board/intel/cherryhill/MAINTAINERS | 1 -
 include/configs/cherryhill.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/cherryhill.h

diff --git a/board/intel/cherryhill/Kconfig b/board/intel/cherryhill/Kconfig
index 009cd93b6d44..28e4735e4d65 100644
--- a/board/intel/cherryhill/Kconfig
+++ b/board/intel/cherryhill/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "braswell"
 
-config SYS_CONFIG_NAME
-   default "cherryhill"
-
 config TEXT_BASE
default 0xffe0
 
diff --git a/board/intel/cherryhill/MAINTAINERS 
b/board/intel/cherryhill/MAINTAINERS
index 6e90f642125e..7c1b311990c4 100644
--- a/board/intel/cherryhill/MAINTAINERS
+++ b/board/intel/cherryhill/MAINTAINERS
@@ -2,5 +2,4 @@ INTEL CHERRYHILL BOARD
 M: Bin Meng 
 S: Maintained
 F: board/intel/cherryhill/
-F: include/configs/cherryhill.h
 F: configs/cherryhill_defconfig
diff --git a/include/configs/cherryhill.h b/include/configs/cherryhill.h
deleted file mode 100644
index a3009571de98..
--- a/include/configs/cherryhill.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2017, Bin Meng 
- */
-- 
2.34.1



[PATCH 04/16] bayleybay: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the bayleybay platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/intel/bayleybay/Kconfig | 3 ---
 board/intel/bayleybay/MAINTAINERS | 1 -
 include/configs/bayleybay.h   | 4 
 3 files changed, 8 deletions(-)
 delete mode 100644 include/configs/bayleybay.h

diff --git a/board/intel/bayleybay/Kconfig b/board/intel/bayleybay/Kconfig
index 97228d630878..af08566014dc 100644
--- a/board/intel/bayleybay/Kconfig
+++ b/board/intel/bayleybay/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_SOC
default "baytrail"
 
-config SYS_CONFIG_NAME
-   default "bayleybay"
-
 config TEXT_BASE
default 0xfff0
 
diff --git a/board/intel/bayleybay/MAINTAINERS 
b/board/intel/bayleybay/MAINTAINERS
index 85fa51626af7..5ab5d73f59e5 100644
--- a/board/intel/bayleybay/MAINTAINERS
+++ b/board/intel/bayleybay/MAINTAINERS
@@ -2,5 +2,4 @@ Intel Bayley Bay
 M: Bin Meng 
 S: Maintained
 F: board/intel/bayleybay
-F: include/configs/bayleybay.h
 F: configs/bayleybay_defconfig
diff --git a/include/configs/bayleybay.h b/include/configs/bayleybay.h
deleted file mode 100644
index 9b0f5cedcd79..
--- a/include/configs/bayleybay.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2015, Bin Meng 
- */
-- 
2.34.1



[PATCH 03/16] coreboot: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the coreboot platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Bin Meng 
---
 board/coreboot/coreboot/Kconfig | 7 ---
 board/coreboot/coreboot/MAINTAINERS | 1 -
 include/configs/coreboot.h  | 4 
 3 files changed, 12 deletions(-)
 delete mode 100644 include/configs/coreboot.h

diff --git a/board/coreboot/coreboot/Kconfig b/board/coreboot/coreboot/Kconfig
index 4f41ce1abf10..abbf08ac695e 100644
--- a/board/coreboot/coreboot/Kconfig
+++ b/board/coreboot/coreboot/Kconfig
@@ -29,10 +29,3 @@ config SYS_CAR_SIZE
  This option specifies the board specific Cache-As-RAM (CAR) size.
 
 endif  # CONFIG_VENDOR_COREBOOT
-
-if TARGET_COREBOOT
-
-config SYS_CONFIG_NAME
-   default "coreboot"
-
-endif
diff --git a/board/coreboot/coreboot/MAINTAINERS 
b/board/coreboot/coreboot/MAINTAINERS
index f77736580006..d97383c030cd 100644
--- a/board/coreboot/coreboot/MAINTAINERS
+++ b/board/coreboot/coreboot/MAINTAINERS
@@ -2,7 +2,6 @@ COREBOOT BOARD
 M: Simon Glass 
 S: Maintained
 F: board/coreboot/
-F: include/configs/coreboot.h
 F: configs/coreboot_defconfig
 
 COREBOOT64 BOARD
diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
deleted file mode 100644
index e00c408f29a5..
--- a/include/configs/coreboot.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2018, Bin Meng 
- */
-- 
2.34.1



[PATCH 02/16] xilinx_mbv: Remove empty config header

2024-01-22 Thread Tom Rini
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the xilinx_mbv platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini 
---
Cc: Michal Simek 
---
 board/xilinx/mbv/Kconfig | 3 ---
 board/xilinx/mbv/MAINTAINERS | 1 -
 include/configs/xilinx_mbv.h | 6 --
 3 files changed, 10 deletions(-)
 delete mode 100644 include/configs/xilinx_mbv.h

diff --git a/board/xilinx/mbv/Kconfig b/board/xilinx/mbv/Kconfig
index 4bc9f72c541b..d2dec397ed6f 100644
--- a/board/xilinx/mbv/Kconfig
+++ b/board/xilinx/mbv/Kconfig
@@ -9,9 +9,6 @@ config SYS_VENDOR
 config SYS_CPU
default "generic"
 
-config SYS_CONFIG_NAME
-   default "xilinx_mbv"
-
 config TEXT_BASE
default 0x8000 if !RISCV_SMODE
default 0x8040 if RISCV_SMODE && ARCH_RV32I
diff --git a/board/xilinx/mbv/MAINTAINERS b/board/xilinx/mbv/MAINTAINERS
index 445654fe740e..db9f03388df9 100644
--- a/board/xilinx/mbv/MAINTAINERS
+++ b/board/xilinx/mbv/MAINTAINERS
@@ -4,4 +4,3 @@ S:  Maintained
 F: arch/riscv/dts/xilinx-mbv*
 F: board/xilinx/mbv/
 F: configs/xilinx_mbv*
-F: include/configs/xilinx_mbv.h
diff --git a/include/configs/xilinx_mbv.h b/include/configs/xilinx_mbv.h
deleted file mode 100644
index dba398aeec49..
--- a/include/configs/xilinx_mbv.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * (C) Copyright 2023, Advanced Micro Devices, Inc.
- *
- * Michal Simek 
- */
-- 
2.34.1



[PATCH 01/16] kbuild: Allow for CONFIG_SYS_CONFIG_NAME to be unset

2024-01-22 Thread Tom Rini
It is possible to have a platform which does not require a board.h file
to build, but today we need an empty one for our generated config.h file
to be valid. Allow for omitting this file if CONFIG_SYS_CONFIG_NAME is
not set.

Signed-off-by: Tom Rini 
---
 scripts/Makefile.autoconf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
index 0ade91642ae3..8208ffe22744 100644
--- a/scripts/Makefile.autoconf
+++ b/scripts/Makefile.autoconf
@@ -113,7 +113,7 @@ vpl/include/autoconf.mk: vpl/u-boot.cfg
 define filechk_config_h
(echo "/* Automatically generated - do not edit */";\
echo \#define CFG_BOARDDIR board/$(if $(VENDOR),$(VENDOR)/)$(BOARD);\
-   echo \#include \; \
+   $(if $(CONFIG_SYS_CONFIG_NAME),echo \#include 
\ ;) \
echo \#include \;\
echo \#include \; \
echo \#include \;)
-- 
2.34.1



Re: [PATCH v2 2/2] tools: binman: ti_board_cfg: Check for linting problems

2024-01-22 Thread Ryan Eatmon




On 1/22/2024 6:59 AM, Max Krummenacher wrote:

Hi

On Fri, Jan 05, 2024 at 05:09:17PM +0530, Neha Malcom Francis wrote:

Use yamllint for checking whether YAML configuration files are adhering
to default yamllint rules.


If I understand this correctly this patch now runs checks to verify
that yaml files which are part of the U-Boot source tree are correct.

Shouldn't this be done when one commits a yaml file, i.e. in U-Boot CI
rather than repeating the process on every build and thus having an
additional dependency to build U-Boot and additional build time?

Note that in openembedded there is currently no python yamllint
recipe providing the used python module in the regularly used layers.
How do you plan to integrate the change in the OE U-Boot recipe?
At least our OE CI of latest master now fails (for a TI AM62 based SoM)
as the python module is missing.


I have submitted a patch to oe-core for this missing recipe.

https://lists.openembedded.org/g/openembedded-core/message/194192

Hopefully they accept it.  Otherwise, we are going to "temporarily" 
carrying the same recipe in meta-ti-extras until they accept it in oe-core.




Regards
Max



Signed-off-by: Neha Malcom Francis 
Suggested-by: Nishanth Menon 
---
Changes since v1:
- add yamllint to requirements.txt (Nishanth)

  tools/binman/etype/ti_board_config.py|  5 +
  tools/binman/ftest.py|  6 ++
  tools/binman/test/323_ti_board_cfg_phony.dts | 14 ++
  tools/binman/test/yaml/config.yaml   |  4 ++--
  tools/binman/test/yaml/config_phony.yaml | 18 ++
  tools/buildman/requirements.txt  |  1 +
  6 files changed, 46 insertions(+), 2 deletions(-)
  create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts
  create mode 100644 tools/binman/test/yaml/config_phony.yaml

diff --git a/tools/binman/etype/ti_board_config.py 
b/tools/binman/etype/ti_board_config.py
index 94f894c281..2c3bb8f7b5 100644
--- a/tools/binman/etype/ti_board_config.py
+++ b/tools/binman/etype/ti_board_config.py
@@ -9,6 +9,7 @@
  import os
  import struct
  import yaml
+import yamllint
  
  from collections import OrderedDict

  from jsonschema import validate
@@ -18,6 +19,7 @@ from binman.entry import Entry
  from binman.etype.section import Entry_section
  from dtoc import fdt_util
  from u_boot_pylib import tools
+from yamllint import config
  
  BOARDCFG = 0xB

  BOARDCFG_SEC = 0xD
@@ -244,6 +246,9 @@ class Entry_ti_board_config(Entry_section):
  with open(self._schema_file, 'r') as sch:
  self.schema_yaml = yaml.safe_load(sch)
  
+yaml_config = config.YamlLintConfig("extends: default")

+for p in yamllint.linter.run(open(self._config_file, "r"), 
yaml_config):
+self.Raise(f"Yamllint error: {p.line}: {p.rule}")
  try:
  validate(self.file_yaml, self.schema_yaml)
  except Exception as e:
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index a4ac520cbb..1fbb0fef1a 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -7030,6 +7030,12 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
  data = self._DoReadFile('293_ti_board_cfg.dts')
  self.assertEqual(TI_BOARD_CONFIG_DATA, data)
  
+def testTIBoardConfigLint(self):

+"""Test that an incorrectly linted config file would generate error"""
+with self.assertRaises(ValueError) as e:
+data = self._DoReadFile('323_ti_board_cfg_phony.dts')
+self.assertIn("Yamllint error", str(e.exception))
+
  def testTIBoardConfigCombined(self):
  """Test that a schema validated combined board config file can be 
generated"""
  data = self._DoReadFile('294_ti_board_cfg_combined.dts')
diff --git a/tools/binman/test/323_ti_board_cfg_phony.dts 
b/tools/binman/test/323_ti_board_cfg_phony.dts
new file mode 100644
index 00..441296de4f
--- /dev/null
+++ b/tools/binman/test/323_ti_board_cfg_phony.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   ti-board-config {
+   config = "yaml/config_phony.yaml";
+   schema = "yaml/schema.yaml";
+   };
+   };
+};
diff --git a/tools/binman/test/yaml/config.yaml 
b/tools/binman/test/yaml/config.yaml
index 5f799a6e3a..c2be32128b 100644
--- a/tools/binman/test/yaml/config.yaml
+++ b/tools/binman/test/yaml/config.yaml
@@ -10,9 +10,9 @@ main-branch:
  b: 0
arr: [0, 0, 0, 0]
another-arr:
-- #1
+-  # 1
c: 0
d: 0
-- #2
+-  # 2
c: 0
d: 0
diff --git a/tools/binman/test/yaml/config_phony.yaml 
b/tools/binman/test/yaml/config_phony.yaml
new file mode 100644
index 00..d76fcb3b82
--- /dev/null
+++ b/tools/binman/test/yaml/config_phony.yaml
@@ -0,0 +1,18 @@

Re: [PATCH] board: starfive: handle compatible property in dynamic DT configuration

2024-01-22 Thread Aurelien Jarno
Gentle ping. Note that the maintainer address bounces, I am not sure it
is still valid. Thanks

On 2024-01-10 21:17, Aurelien Jarno wrote:
> The difference between the StarFive VisionFive 2 1.2A and 1.3B boards is
> handled dynamically by looking at the PCB version in the EEPROM in order
> to have a single u-boot version for both versions of the board. While
> the "model" property is correctly handled, the "compatible" one is
> always the the one of version 1.3b.
> 
> This patch add support for dynamically configuring that property.
> 
> Fixes: 9b7060bd15e7 ("riscv: dts: jh7110: Combine the board device tree files 
> of 1.2A and 1.3B")
> 
> Signed-off-by: Aurelien Jarno 
> ---
>  board/starfive/visionfive2/spl.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/board/starfive/visionfive2/spl.c 
> b/board/starfive/visionfive2/spl.c
> index 336f0cdfc9..911add429d 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -61,11 +61,13 @@ static const struct starfive_vf2_pro starfive_verb[] = {
>  
>  void spl_fdt_fixup_version_a(void *fdt)
>  {
> + static const char compat[] = 
> "starfive,visionfive-2-v1.2a\0starfive,jh7110";
>   u32 phandle;
>   u8 i;
>   int offset;
>   int ret;
>  
> + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, 
> sizeof(compat));
>   fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",
>  "StarFive VisionFive 2 v1.2A");
>  
> @@ -106,11 +108,13 @@ void spl_fdt_fixup_version_a(void *fdt)
>  
>  void spl_fdt_fixup_version_b(void *fdt)
>  {
> + static const char compat[] = 
> "starfive,visionfive-2-v1.3b\0starfive,jh7110";
>   u32 phandle;
>   u8 i;
>   int offset;
>   int ret;
>  
> + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, 
> sizeof(compat));
>   fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",
>  "StarFive VisionFive 2 v1.3B");
>  
> -- 
> 2.42.0
> 
> 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


Re: [PATCH 1/5] omap3: Make SPL_OMAP3_ID_NAND depend on NAND_OMAP_GPMC

2024-01-22 Thread Tom Rini
On Wed, 10 Jan 2024 13:46:06 -0500, Tom Rini wrote:

> This specific bit logic is used to determine what NAND chip is present
> on a board in order to then know what revision of the board we have and
> so what DDR chips are present. We can only do this if we have a NAND
> chip, and so we will have NAND_OMAP_GPMC enabled.
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom




[PATCH] serial: pl01x: set baudrate when probing

2024-01-22 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

It is found that when DM is enabled, only generic init function is
called in .probe(). Baudrate is never honored. Add a function call
to .setbrg() when probing so that we can update the baudrate of the
serial device.

Signed-off-by: Yang Xiwen 
---
 drivers/serial/serial_pl01x.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 428a4d210d..57bbcaf3b6 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -290,6 +290,7 @@ int pl01x_serial_probe(struct udevice *dev)
 {
struct pl01x_serial_plat *plat = dev_get_plat(dev);
struct pl01x_priv *priv = dev_get_priv(dev);
+   int ret;
 
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct dtd_serial_pl01x *dtplat = &plat->dtplat;
@@ -301,10 +302,14 @@ int pl01x_serial_probe(struct udevice *dev)
 #endif
priv->type = plat->type;
 
-   if (!plat->skip_init)
-   return pl01x_generic_serial_init(priv->regs, priv->type);
-   else
+   if (!plat->skip_init) {
+   ret = pl01x_generic_serial_init(priv->regs, priv->type);
+   if (!ret)
+   return ret;
+   return pl01x_serial_setbrg(dev, gd->baudrate);
+   } else {
return 0;
+   }
 }
 
 int pl01x_serial_getc(struct udevice *dev)

---
base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3
change-id: 20240123-b4-pl011-ee9575ff2a38

Best regards,
-- 
Yang Xiwen 



[PATCH] toradex: tdx-cfg-block: Add new apalis and colibri pid

2024-01-22 Thread Joao Paulo Goncalves
From: Joao Paulo Goncalves 

Add new apalis imx6 and colibri imx6/imx7 products IDs.

Signed-off-by: Joao Paulo Goncalves 
---
 board/toradex/common/tdx-cfg-block.c | 9 +
 board/toradex/common/tdx-cfg-block.h | 9 +
 2 files changed, 18 insertions(+)

diff --git a/board/toradex/common/tdx-cfg-block.c 
b/board/toradex/common/tdx-cfg-block.c
index 7187e1ba377..7affc290395 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -147,6 +147,15 @@ const struct toradex_som toradex_modules[] = {
[74] = { "Verdin AM62 Dual 1GB IT",  
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
[75] = { "Verdin AM62 Dual 1GB WB IT",   
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
[76] = { "Verdin AM62 Quad 2GB WB IT",   
TARGET_IS_ENABLED(VERDIN_AM62_A53) },
+   [77] = { "Colibri iMX6S 256MB",  
TARGET_IS_ENABLED(COLIBRI_IMX6)},
+   [78] = { "Colibri iMX6S 256MB IT",   
TARGET_IS_ENABLED(COLIBRI_IMX6)},
+   [79] = { "Colibri iMX6DL 512MB", 
TARGET_IS_ENABLED(COLIBRI_IMX6)},  
+   [80] = { "Colibri iMX6DL 512MB IT",  
TARGET_IS_ENABLED(COLIBRI_IMX6)},
+   [81] = { "Colibri iMX7D 512MB",  
TARGET_IS_ENABLED(COLIBRI_IMX7)},
+   [82] = { "Apalis iMX6D 512MB",   
TARGET_IS_ENABLED(APALIS_IMX6) },
+   [83] = { "Apalis iMX6Q 1GB", 
TARGET_IS_ENABLED(APALIS_IMX6) },
+   [84] = { "Apalis iMX6D 1GB IT",  
TARGET_IS_ENABLED(APALIS_IMX6) },
+   [85] = { "Apalis iMX6Q 2GB IT",  
TARGET_IS_ENABLED(APALIS_IMX6) },
 };
 
 struct pid4list {
diff --git a/board/toradex/common/tdx-cfg-block.h 
b/board/toradex/common/tdx-cfg-block.h
index ea58bd43b17..b783537ce76 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -102,6 +102,15 @@ enum {
VERDIN_AM62D_1G_IT,
VERDIN_AM62D_1G_WIFI_BT_IT, /* 75 */
VERDIN_AM62Q_2G_WIFI_BT_IT,
+   COLIBRI_IMX6S_NOWINCE,
+   COLIBRI_IMX6S_IT_NOWINCE,
+   COLIBRI_IMX6DL_NOWINCE,
+   COLIBRI_IMX6DL_IT_NOWINCE, /* 80 */
+   COLIBRI_IMX7D_NOWINCE,
+   APALIS_IMX6D_NOWINCE,
+   APALIS_IMX6Q_NOWINCE,
+   APALIS_IMX6D_IT_NOWINCE,
+   APALIS_IMX6Q_IT_NOWINCE, /* 85 */
 };
 
 enum {
-- 
2.34.1


[PATCH] efi_loader : Suppress error print message

2024-01-22 Thread Tejas Bhumkar
Currently, on certain Xilinx platforms, an issue has been
identified, manifesting as follows:

Starting kernel ...

efi_free_pool: illegal free 0x77830040
efi_free_pool: illegal free 0x7782d040
efi_free_pool: illegal free 0x7782c040

The issue arises when the ramdisk image is relocated, placing
it within the previously allocated EFI memory region( as EFI 
is established quite early in U-Boot). Consequently, when 
attempting to release memory in the EFI memory region during 
the handover process to the kernel,we encounter memory violations.

Highlighting that EFI remains active primarily during the 
booting of an EFI application, and the lmb persists while 
configuring images for the boot process. Since we aren't 
utilizing the EFI memory region during the boot process, 
there is no adverse impact even in the event of a violation.

Currently, there is an ongoing discussion regarding the handling
strategies of three memory allocators: malloc, lmb, and EFI. This
discussion is documented in the email chain
titled "Proposal: U-Boot memory management."

Therefore, it is advisable to suppress the print message during
the boot process for now.

Signed-off-by: Tejas Bhumkar  
---
 lib/efi_loader/efi_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index edfad2d95a..821fe7616e 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
/* Check that this memory was allocated by efi_allocate_pool() */
if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
alloc->checksum != checksum(alloc)) {
-   printf("%s: illegal free 0x%p\n", __func__, buffer);
+   debug("%s: illegal free 0x%p\n", __func__, buffer);
return EFI_INVALID_PARAMETER;
}
/* Avoid double free */
-- 
2.27.0



Re: [PATCH v7] fdt: Allow the devicetree to come from a bloblist

2024-01-22 Thread Conor Dooley
On Mon, Jan 22, 2024 at 01:47:17PM -0500, Tom Rini wrote:
> On Mon, Jan 22, 2024 at 06:36:31PM +, Conor Dooley wrote:
> > Hey,
> > 
> > On Tue, Jan 16, 2024 at 01:48:06PM +, Conor Dooley wrote:
> > > Yo,
> > > 
> > > On Wed, Jan 03, 2024 at 06:49:19PM -0700, Simon Glass wrote:
> > > > Standard passage provides for a bloblist to be passed from one firmware
> > > > phase to the next. That can be used to pass the devicetree along as 
> > > > well.
> > > > Add an option to support this.
> > > > 
> > > > Tests for this will be added as part of the Universal Payload work.
> > > > 
> > > > Signed-off-by: Simon Glass 
> > > 
> > > Since this was merged into master, U-Boot is no longer booting on my
> > > icicle kit (At least that's what my bisection tells me). This is a
> > > RISC-V board and U-Boot for it is built from
> > > microchip_mpfs_icicle_defconfig.
> > > 
> > > There's zero output on the console from U-Boot at all, the last thing
> > > that I see is OpenSBI before things grind to a halt.
> > 
> > Just wondering if there's anything I can do to help this one along?
> > Got a red CI complaining at me every morning about it :|
> 
> Well, can you please look in to what part of this is causing the
> failure? I don't really see what would have changed on
> microchip_mpfs_icicle_defconfig from this as BLOBLIST isn't set before
> nor after this change.

Sure. I'll try to look into it more tomorrow.


signature.asc
Description: PGP signature


Re: [PATCH v7] fdt: Allow the devicetree to come from a bloblist

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 06:36:31PM +, Conor Dooley wrote:
> Hey,
> 
> On Tue, Jan 16, 2024 at 01:48:06PM +, Conor Dooley wrote:
> > Yo,
> > 
> > On Wed, Jan 03, 2024 at 06:49:19PM -0700, Simon Glass wrote:
> > > Standard passage provides for a bloblist to be passed from one firmware
> > > phase to the next. That can be used to pass the devicetree along as well.
> > > Add an option to support this.
> > > 
> > > Tests for this will be added as part of the Universal Payload work.
> > > 
> > > Signed-off-by: Simon Glass 
> > 
> > Since this was merged into master, U-Boot is no longer booting on my
> > icicle kit (At least that's what my bisection tells me). This is a
> > RISC-V board and U-Boot for it is built from
> > microchip_mpfs_icicle_defconfig.
> > 
> > There's zero output on the console from U-Boot at all, the last thing
> > that I see is OpenSBI before things grind to a halt.
> 
> Just wondering if there's anything I can do to help this one along?
> Got a red CI complaining at me every morning about it :|

Well, can you please look in to what part of this is causing the
failure? I don't really see what would have changed on
microchip_mpfs_icicle_defconfig from this as BLOBLIST isn't set before
nor after this change.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] scripts/gen_compile_commands: update to Linux v6.7

2024-01-22 Thread Brandon Maier
Adds support for assembly files and updates the LINE_PATTERN so it
supports both "cmd" and "savedcmd", which allows reverting the U-Boot
modification in commit 97fbb2eb016b ("scripts/gen_compile_commands.py:
adapt _LINE_PATTERN").

Upstream commits:

- 880946158b011 gen_compile_commands.py: fix path resolve with symlinks in it
- 9e56d3be4bfd2 gen_compile_commands: Sort output compile commands by file name
- 52c15e7e79285 gen_compile_commands: Allow the line prefix to still be cmd_
- 1c67921444bf6 gen_compile_commands: add assembly files to compilation database

Signed-off-by: Brandon Maier 
Cc: Joao Marcos Costa 
---

 scripts/gen_compile_commands.py | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
index cdca85e6b07..fec513e5547 100755
--- a/scripts/gen_compile_commands.py
+++ b/scripts/gen_compile_commands.py
@@ -21,7 +21,7 @@ _DEFAULT_OUTPUT = 'compile_commands.json'
 _DEFAULT_LOG_LEVEL = 'WARNING'

 _FILENAME_PATTERN = r'^\..*\.cmd$'
-_LINE_PATTERN = r'^cmd_[^ ]*\.o := (.* )([^ ]*\.c) *(;|$)'
+_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P.* 
)(?P[^ ]*\.[cS]) *(;|$)'
 _VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
 # The tools/ directory adopts a different build system, and produces .cmd
 # files in a different format. Do not support it.
@@ -66,7 +66,7 @@ def parse_arguments():
 args = parser.parse_args()

 return (args.log_level,
-os.path.abspath(args.directory),
+os.path.realpath(args.directory),
 args.output,
 args.ar,
 args.paths if len(args.paths) > 0 else [args.directory])
@@ -174,8 +174,8 @@ def process_line(root_directory, command_prefix, file_path):
 # by Make, so this code replaces the escaped version with '#'.
 prefix = command_prefix.replace('\#', '#').replace('$(pound)', '#')

-# Use os.path.abspath() to normalize the path resolving '.' and '..' .
-abs_path = os.path.abspath(os.path.join(root_directory, file_path))
+# Return the canonical path, eliminating any symbolic links encountered in 
the path.
+abs_path = os.path.realpath(os.path.join(root_directory, file_path))
 if not os.path.exists(abs_path):
 raise ValueError('File %s not found' % abs_path)
 return {
@@ -215,15 +215,15 @@ def main():
 result = line_matcher.match(f.readline())
 if result:
 try:
-entry = process_line(directory, result.group(1),
- result.group(2))
+entry = process_line(directory, 
result.group('command_prefix'),
+ result.group('file_path'))
 compile_commands.append(entry)
 except ValueError as err:
 logging.info('Could not add line from %s: %s',
  cmdfile, err)

 with open(output, 'wt') as f:
-json.dump(compile_commands, f, indent=2, sort_keys=True)
+json.dump(sorted(compile_commands, key=lambda x: x["file"]), f, 
indent=2, sort_keys=True)


 if __name__ == '__main__':
--
2.43.0


Re: [PATCH v7] fdt: Allow the devicetree to come from a bloblist

2024-01-22 Thread Conor Dooley
Hey,

On Tue, Jan 16, 2024 at 01:48:06PM +, Conor Dooley wrote:
> Yo,
> 
> On Wed, Jan 03, 2024 at 06:49:19PM -0700, Simon Glass wrote:
> > Standard passage provides for a bloblist to be passed from one firmware
> > phase to the next. That can be used to pass the devicetree along as well.
> > Add an option to support this.
> > 
> > Tests for this will be added as part of the Universal Payload work.
> > 
> > Signed-off-by: Simon Glass 
> 
> Since this was merged into master, U-Boot is no longer booting on my
> icicle kit (At least that's what my bisection tells me). This is a
> RISC-V board and U-Boot for it is built from
> microchip_mpfs_icicle_defconfig.
> 
> There's zero output on the console from U-Boot at all, the last thing
> that I see is OpenSBI before things grind to a halt.

Just wondering if there's anything I can do to help this one along?
Got a red CI complaining at me every morning about it :|

> 
> Thanks,
> Conor.
> 
> 
> > ---
> > The discussion on this was not resolved and is now important due to the
> > bloblist series from Raymond. So I am sending it again since I believe
> > this is a better starting point than building on OF_BOARD
> > 
> > Changes in v7:
> > - Drop use of OF_BLOBLIST
> > 
> > Changes in v6:
> > - Don't allow bloblist with OF_EMBED
> > 
> > Changes in v5:
> > - Make OF_BLOBLIST default y
> > - Make OF_BLOBLIST optional at runtime
> > 
> > Changes in v4:
> > - Rebase to -next
> > 
> >  doc/develop/devicetree/control.rst |  3 ++
> >  include/fdtdec.h   |  6 ++--
> >  lib/fdtdec.c   | 44 +++---
> >  3 files changed, 41 insertions(+), 12 deletions(-)
> > 
> > diff --git a/doc/develop/devicetree/control.rst 
> > b/doc/develop/devicetree/control.rst
> > index cbb65c9b177..11c92d440f4 100644
> > --- a/doc/develop/devicetree/control.rst
> > +++ b/doc/develop/devicetree/control.rst
> > @@ -108,6 +108,9 @@ If CONFIG_OF_BOARD is defined, a board-specific routine 
> > will provide the
> >  devicetree at runtime, for example if an earlier bootloader stage creates
> >  it and passes it to U-Boot.
> >  
> > +If CONFIG_BLOBLIST is defined, the devicetree may come from a bloblist 
> > passed
> > +from a previous stage, if present.
> > +
> >  If CONFIG_SANDBOX is defined, then it will be read from a file on
> >  startup. Use the -d flag to U-Boot to specify the file to read, -D for the
> >  default and -T for the test devicetree, used to run sandbox unit tests.
> > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > index bd1149f46d0..e80de24076c 100644
> > --- a/include/fdtdec.h
> > +++ b/include/fdtdec.h
> > @@ -72,7 +72,7 @@ struct bd_info;
> >   * U-Boot is packaged as an ELF file, e.g. for debugging purposes
> >   * @FDTSRC_ENV: Provided by the fdtcontroladdr environment variable. This 
> > should
> >   * be used for debugging/development only
> > - * @FDTSRC_NONE: No devicetree at all
> > + * @FDTSRC_BLOBLIST: Provided by a bloblist from an earlier phase
> >   */
> >  enum fdt_source_t {
> > FDTSRC_SEPARATE,
> > @@ -80,6 +80,7 @@ enum fdt_source_t {
> > FDTSRC_BOARD,
> > FDTSRC_EMBED,
> > FDTSRC_ENV,
> > +   FDTSRC_BLOBLIST,
> >  };
> >  
> >  /*
> > @@ -1190,7 +1191,8 @@ int fdtdec_resetup(int *rescan);
> >   *
> >   * The existing devicetree is available at gd->fdt_blob
> >   *
> > - * @err internal error code if we fail to setup a DTB
> > + * @err: 0 on success, -EEXIST if the devicetree is already correct, or 
> > other
> > + * internal error code if we fail to setup a DTB
> >   * @returns new devicetree blob pointer
> >   */
> >  void *board_fdt_blob_setup(int *err);
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index 4016bf3c113..b2c59ab3818 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -7,6 +7,10 @@
> >   */
> >  
> >  #ifndef USE_HOSTCC
> > +
> > +#define LOG_CATEGORY   LOGC_DT
> > +
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -86,6 +90,7 @@ static const char *const fdt_src_name[] = {
> > [FDTSRC_BOARD] = "board",
> > [FDTSRC_EMBED] = "embed",
> > [FDTSRC_ENV] = "env",
> > +   [FDTSRC_BLOBLIST] = "bloblist",
> >  };
> >  
> >  const char *fdtdec_get_srcname(void)
> > @@ -1662,23 +1667,42 @@ static void setup_multi_dtb_fit(void)
> >  
> >  int fdtdec_setup(void)
> >  {
> > -   int ret;
> > +   int ret = -ENOENT;
> > +
> > +   /* If allowing a bloblist, check that first */
> > +   if (CONFIG_IS_ENABLED(BLOBLIST)) {
> > +   ret = bloblist_maybe_init();
> > +   if (!ret) {
> > +   gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
> > +   if (gd->fdt_blob) {
> > +   gd->fdt_src = FDTSRC_BLOBLIST;
> > +   log_debug("Devicetree is in bloblist at %p\n",
> > + gd->fdt_blob);
> > +   } else {
> > +   log_debug("No FDT found in bloblist\n");
> > +   re

Re: [PATCH v3] common: usb-hub: Reset hub port before scanning

2024-01-22 Thread Tom Rini
On Sat, 09 Dec 2023 18:10:56 +, Shantur Rathore wrote:

> Currently when a hub is turned on, all the ports are powered on.
> This works well for hubs which have individual power control.
> 
> For the hubs without individual power control this has no effect.
> Mostly in these scenarios the hub port is powered before the USB
> controller is enabled, this can lead to some devices in unexpected
> state.
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom




[PATCH v2] rockchip: spl: Enable caches to speed up checksum validation

2024-01-22 Thread Jonas Karlman
FIT checksum validation is very slow in SPL due to D-cache not being
enabled.

Enable caches in SPL to speed up FIT checksum validation, from seconds
to milliseconds.

This change enables caches in SPL on all Rockchip boards, the Kconfig
options SPL_SYS_ICACHE_OFF and SPL_SYS_DCACHE_OFF can be enabled to
disable caches for a specific board or SoC if needed.

Signed-off-by: Jonas Karlman 
---
Changes in v2:
- None

This has been tested on multiple RK3288, RK3328, RK3399, RK356x and
RK3588 boards without any issues, vendor U-Boot also enables caches in
SPL for all SoCs.

Link to RFC: https://patchwork.ozlabs.org/patch/1802303/
---
 arch/arm/mach-rockchip/spl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 87280e2ba7cc..e29c841100c8 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -136,6 +136,10 @@ void board_init_f(ulong dummy)
}
gd->ram_top = gd->ram_base + get_effective_memsize();
gd->ram_top = board_get_usable_ram_top(gd->ram_size);
+   gd->relocaddr = gd->ram_top;
+
+   arch_reserve_mmu();
+   enable_caches();
 #endif
preloader_console_init();
 }
-- 
2.43.0



Re: [PATCH v4 0/6] rpi5: initial support

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 03:30:00PM +0100, Mark Kettenis wrote:
> > Date: Mon, 22 Jan 2024 16:16:34 +0200
> > From: "Ivan T. Ivanov" 
> > 
> > Hi,
> > 
> > On 01-22 13:57, Ivan T. Ivanov wrote:
> > > > Am 20.01.24 um 10:48 schrieb Jens Maus:
> > > >> Hi,
> > > >> 
> > > >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren :
> > > >>> 
> > > >>> Am 19.01.24 um 22:26 schrieb Jens Maus:
> > >  I actually do have some good and bad news:
> > >  
> > >  1. Good news: I got u-boot finally showing up with my RaspberryPi5 
> > >  8GB both on the HDMI and on the serial debug UART like you reported.
> > >  
> > >  2. Bad news: I actually got it working by downgrading the rpi-eeprom 
> > >  to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
> > >  
> > > > 
> > > > One idea would be to enable early debug in U-Boot (no idea how to
> > > > achieve this). I assume U-Boot crashes before it's able to print the
> > > > first line, but it's hard to believe it crashes at the very first
> > > > instruction of U-Boot. So with some luck we should be able to narrow
> > > > done the cause.
> > > 
> > > I was able to enable early debug UART in U-Boot and I will try to
> > > find what is happening, once I get some free cycles.
> > 
> > Ok, this was relatively easy to find :-)
> > 
> > New versions of EEPROM firmware change “kernel”/U-Boot load address 
> > from 0x8 to 0x20. And because on RPi’s CONFIG_TEXT_BASE is
> > hardcoded to 0x8 code run through the fields. 
> > 
> > Hopefully simple patch like bellow make it work fine in older and
> > newer EEPROM firmware versions.
> > 
> > Regards,
> > Ivan  
> > 
> > diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> > index 11ede9435d..ce64f9554f 100644
> > --- a/configs/rpi_arm64_defconfig
> > +++ b/configs/rpi_arm64_defconfig
> > @@ -1,6 +1,7 @@
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_BCM283X=y
> >  CONFIG_TEXT_BASE=0x0008
> > +CONFIG_POSITION_INDEPENDENT=y
> 
> Not sure if it really matters, but for the Apple M1 config I set
> CONFIG_TEXT_BASE to 0x (zero).

It shouldn't matter. 0x0 is the default for TEXT_BASE in this case, but
also a number of platforms set it to something else seemingly valid,
but could I suspect still drop the setting as it should not matter at
run time.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] rockchip: sdram: fix LPDDR5 bank info for sys_reg version 3

2024-01-22 Thread Jonas Karlman
Hi,

On 2024-01-22 08:46, Kever Yang wrote:
> From: YouMin Chen 
> 
> This patch add support for additional bank info used by LPDDR5.
> 
> Signed-off-by: YouMin Chen 
> Signed-off-by: Kever Yang 
> ---
> 
>  arch/arm/mach-rockchip/sdram.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
> index 99ecbdc3412..d65c48bf515 100644
> --- a/arch/arm/mach-rockchip/sdram.c
> +++ b/arch/arm/mach-rockchip/sdram.c
> @@ -110,6 +110,13 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> SYS_REG_COL_MASK);
>   cs1_col = cs0_col;
>   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
> + /*
> +  * SYS_REG_BK(Version 3):
> +  * 1) Except LPDDR5 0:8bank(bk=3), 1:4bank(bk=2)
> +  * 2) LPDDR5 0:8bank(bk=3), 1:16bank(bk=4)
> +  */
> + if (version == 3 && dram_type == LPDDR5 && bk == 2)
> + bk = 4;

The version == 3 test is not really needed because dram_type cannot be
assigned to LPDDR5 (9) since the dram_type high bits is only read for
version >= 3.

Also not sure I fully like the if bk==2 then bk=4 override code style
here because the code comment do not fully match the code flow. I had to
stop and think twice on why the test was for bk==2 when it is bk bit = 1
that should result in bk=4.

Maybe we can make the code closer match the comment with something like
the following:


@@ -109,7 +109,14 @@ size_t rockchip_sdram_size(phys_addr_t reg)
cs0_col = 9 + (sys_reg2 >> SYS_REG_COL_SHIFT(ch) &
  SYS_REG_COL_MASK);
cs1_col = cs0_col;
-   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
+   if (dram_type == LPDDR5)
+   /* LPDDR5: 0:8bank(bk=3), 1:16bank(bk=4) */
+   bk = 3 + ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) &
+ SYS_REG_BK_MASK);
+   else
+   /* Other: 0:8bank(bk=3), 1:4bank(bk=2) */
+   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) &
+ SYS_REG_BK_MASK);
if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
  SYS_REG_CS1_COL_MASK);


or possible use of a conditional operator:


@@ -109,7 +109,13 @@ size_t rockchip_sdram_size(phys_addr_t reg)
cs0_col = 9 + (sys_reg2 >> SYS_REG_COL_SHIFT(ch) &
  SYS_REG_COL_MASK);
cs1_col = cs0_col;
-   bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
+   /*
+* SYS_REG_BK:
+* LPDDR5: 0:8bank(bk=3), 1:16bank(bk=4)
+* Other: 0:8bank(bk=3), 1:4bank(bk=2)
+*/
+   bk = (sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK;
+   bk = (dram_type == LPDDR5) ? 3 + bk : 3 - bk;
if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
  SYS_REG_CS1_COL_MASK);


Not sure any of the above suggestions makes the code any easier to
understand.

Regards,
Jonas

>   if (version >= 2) {
>   cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
> SYS_REG_CS1_COL_MASK);



Re: [PATCH v3 4/6] rockchip: find U-boot proper boot device by inverting the logic that sets it

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 11:49:23AM +0100, Quentin Schulz wrote:
> Hi Kever,
> 
> On 1/18/24 11:12, Kever Yang wrote:
> > Hi Quentin,
> > 
> > On 2024/1/18 01:22, Quentin Schulz wrote:
> > > From: Quentin Schulz 
> > > 
> > > BOOT_DEVICE_* is set by spl_node_to_boot_device() depending on the block
> > > device number associated with the MMC device the SPL used to load U-Boot
> > > proper from. It is NOT related to the mmc alias in the Device Tree.
> > > 
> > > For SPI flashes, all SPI flashes will return BOOT_DEVICE_SPI so there's
> > > currently no way to know from which one the SPL loaded U-Boot proper
> > > from. Therefore, let's just find the first valid candidate in
> > > /chosen/u-boot,spl-boot-order that is a SPI flash and return that path.
> > > This is a best effort.
> > > 
> > > While the original implementation may have worked, using the exact same
> > > mechanism but in inverted fashion makes it less likely to have
> > > surprising corner-cases or side-effects.
> > > 
> > > A nice side-effect is that all existing and future Rockchip SoCs now
> > > automatically have their /chosen/u-boot,spl-boot-device set.
> > 
> > Error happen in some 32bit SoC:
> > 
> > +arch/arm/mach-rockchip/spl-boot-order.c: In function 'spl_perform_fixups':
> > +arch/arm/mach-rockchip/spl-boot-order.c:242:31: error: 'struct
> > spl_image_info' has no member named 'fdt_addr'
> > +  242 | void *blob = spl_image->fdt_addr;
> > +  |   ^~
> > +make[3]: *** [scripts/Makefile.build:257:
> > spl/arch/arm/mach-rockchip/spl-boot-order.o] Error 1
> > 
> > 
> 
> It'd be nice to say **which** boards aren't working so that I can reproduce
> locally :)
> 
> I eventually figured we have GitLab CI/CD for your maintainer branch/repo
> here: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines.
> This also helped me figure out this wasn't the only build failure and I
> could send another patch before you had the opportunity to tell me I had
> broken something else :)
> 
> Giving the link of the failed pipeline would really help, please think about
> it for next time :) Thanks!
> 
> For people interested in build-testing all Rockchip platforms locally, I
> used the following script:

Please note that you can also build all of the rockchip platforms
locally with:
tools/buildman/buildman --allow-missing rk rv

It won't be bootable as it will fake all require blobs, but all
platforms will be built. And buildman can be told a number of things to
be built, but "rockchip" only catches the cases where the board vendor
is "rockhip" rather than ARCH_ROCKCHIP, but "rk" and "rv" catch all of
the rk and rv SoCs.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 11:45:15AM +, Andre Przywara wrote:
> On Wed, 10 Jan 2024 16:05:36 +0530
> Sumit Garg  wrote:
> 
> Hi,
> 
> I certainly welcome this more automatic synchronisation of the DTs,
> however have one comment about the upcoming sync process:
> 
> > ...
> > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather
> > use devicetree-rebasing repo [3] which is a forked copy from Linux
> > kernel for DT source files as well as bindings. It is tagged at every
> > Linux kernel major release or intermideate release candidates. So here I
> > have tried to reuse that to bring DT bingings compliance as well as a
> > standard way to maintain a regular sync of DT source files with Linux
> > kernel.
> > 
> > In order to maintain devicetree files sync, U-Boot will maintains a Git
> > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory.
> > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window
> > opens with the next available kernel major release.
> 
> I hope this doesn't need to stay that restricted? Can we either sync more
> often, or at least on the kernel's -rc1, and not only on a "full" release?
> 
> The reason I ask is that we have a chicken-egg problem here: without a DT
> merged into the kernel tree, no U-Boot board support can be merged. And
> without U-Boot support, we cannot boot a kernel, at least not in the
> canonical way.
> 
> Since the U-Boot and kernel merge windows are not in phase, for sunxi I try
> to sync the kernel DTs either as early as possible (-rc1, sometimes even
> before, when the maintainers have merged them into their tree), or
> sometimes "out of season", if a board defconfig patch is coming up.
> 
> Otherwise new board support, which typically has a very low regression risk
> for the rest of the code base, would need to be delayed until the next
> release. In the worst case the U-Boot merge windows opens one week before
> a kernel release, then new boards need to wait three months?

Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot
release, and then with the next one switch to OF_UPSTREAM=y (and delete
the dts from arch/) for the next release, when we would have gotten back
in sync?

-- 
Tom


signature.asc
Description: PGP signature


Re: Please pull u-boot-marvell/master

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 04:46:48PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull this next batch of Marvell related patches:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 01:39:06PM +0200, Roger Quadros wrote:
> 
> 
> On 20/01/2024 18:50, Tom Rini wrote:
> > On Mon, Jan 15, 2024 at 01:40:00PM +0200, Roger Quadros wrote:
> >>
> >>
> >> On 12/01/2024 15:21, Tom Rini wrote:
> >>> On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
>  On 15:06-20240112, Roger Quadros wrote:
> >
> >
> > On 12/01/2024 15:02, Nishanth Menon wrote:
> >> On 14:49-20240112, Roger Quadros wrote:
> >>> Without correct SERDES MUX and Lane control settings
> >>> USB0 will be broken. Set the MUX and Lane control devices
> >>> to be auto probed so they are configured correctly.
> >>>
> >>> Signed-off-by: Roger Quadros 
> >>> ---
> >>>  arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi 
> >>> b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >>> index f83caf7998..017a5a722e 100644
> >>> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >>> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >>> @@ -165,6 +165,7 @@
> >>>  
> >>>  &serdes_ln_ctrl {
> >>>   bootph-all;
> >>> + u-boot,mux-autoprobe;
> >>>  };
> >>>  
> >>>  &serdes2_usb_link {
> >>> @@ -173,6 +174,7 @@
> >>>  
> >>>  &usb_serdes_mux {
> >>>   bootph-all;
> >>> + u-boot,mux-autoprobe;
> >>>  };
> >>>  
> >>>  &serdes_wiz2 {
> >>>
> >>> OK, so both of these are compatible = "mmio-mux", is the problem they
> >>> aren't probed in time or something else?
> >>>
> >>
> >> That's correct. They aren't probed ever. But that is because there are no
> >> explicit consumers for them. Since this is a platform wide configuration,
> >> we have been relying on the "idle-states" property and that they are 
> >> auto-probed.
> > 
> > OK.  Could we borrow the "wrap" logic that drivers/led/led_gpio.c for
> > example does to get the probe to happen inside drivers/mux/mmio.c
> > instead? I feel like there might have been assumptions about grander
> > needs back when the framework for muxers was done that has not panned
> > out since.
> > 
> 
> We only need the MUX driver to probe if the MUX node contains the 
> "idle-states"
> property.
> 
> So maybe the MUX UCLASS code should be checking for that instead of/along with
> the custom u-boot,mux-autoprobe property?
> 
> How does this look?
> 
> diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
> index c98576ceb8..8833888ded 100644
> --- a/drivers/mux/mux-uclass.c
> +++ b/drivers/mux/mux-uclass.c
> @@ -318,7 +318,8 @@ int dm_mux_init(void)
>   return ret;
>   }
>   uclass_foreach_dev(dev, uc) {
> - if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
> + if (dev_read_bool(dev, "u-boot,mux-autoprobe") ||
> + dev_read_bool(dev, "idle-states")) {
>   ret = device_probe(dev);
>   if (ret)
>   log_debug("unable to probe device %s\n",

I would just drop "u-boot,mux-autoprobe" as TI platforms are the only
users of this uclass and mmio driver, iirc.

-- 
Tom


signature.asc
Description: PGP signature


Please pull u-boot-marvell/master

2024-01-22 Thread Stefan Roese

Hi Tom,

please pull this next batch of Marvell related patches:


- solidrun: clearfog gtr: add serdes configuration (Josua)


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=334&view=results

Thanks,
Stefan


The following changes since commit 3c04fcf3137d5f694d52b8f355373e4baabe5f78:

  Merge patch series "k3-j721e: beagleboneai: Fix USB" (2024-01-20 
11:39:13 -0500)


are available in the Git repository at:

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

for you to fetch changes up to bb6e89048ceaf26a4d775750715e3279dbd73d07:

  board: solidrun: clearfog: fix serdes 1 / eth2 speed for clearfog gtr 
(2024-01-22 12:47:45 +0100)



Josua Mayer (2):
  arm: mvebu: clearfog gtr: add config option to select serdes0 
interface

  board: solidrun: clearfog: fix serdes 1 / eth2 speed for clearfog gtr

 board/solidrun/clearfog/Kconfig| 19 +++
 board/solidrun/clearfog/clearfog.c | 19 ---
 2 files changed, 35 insertions(+), 3 deletions(-)



Re: [PATCH 3/5] board: rockchip: Add Sonoff iHost board

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 11:46:01PM +1100, Tim Lunn wrote:

> Sonoff iHost is gateway device designed to provide a Smart Home Hub,
> it is based on Rockchip RV1126. There is also a version with 2GB RAM
> based off the RV1109 dual core SoC however this works with the same
> config as the RV1126 for uboot purposes.
[snip]
> diff --git a/include/configs/sonoff-ihost.h b/include/configs/sonoff-ihost.h
> new file mode 100644
> index 00..8ed5d78687
> --- /dev/null
> +++ b/include/configs/sonoff-ihost.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#ifndef __SONOFF_IHOST_H
> +#define __SONOFF_IHOST_H
> +
> +#define ROCKCHIP_DEVICE_SETTINGS \
> + "stdout=serial\0" \
> + "stderr=serial\0"
> +
> +#include 
> +
> +#undef BOOT_TARGET_DEVICES
> +
> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 0) \
> + func(MMC, mmc, 1)
> +
> +#endif /*  __SONOFF_IHOST_H */

We should be using standard boot, which removes most of this, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 0/2] board: solidrun: clearfog gtr: add serdes configuration

2024-01-22 Thread Stefan Roese

On 1/12/24 14:35, Josua Mayer wrote:

Add missing configuration options for clearog gtr serdes:

1. select between sata and pci-e for serdes 0
2. configure serdes 2 for 2.5Gbps link with managed switch

Signed-off-by: Josua Mayer 
---
Changes in v2:
- change choice default logic to remove kconfig warning
- Link to v1: 
https://lore.kernel.org/r/20240106-clearfog-gtr-serdes-v1-0-66cbc350c...@solid-run.com

---
Josua Mayer (2):
   arm: mvebu: clearfog gtr: add config option to select serdes0 interface
   board: solidrun: clearfog: fix serdes 1 / eth2 speed for clearfog gtr

  board/solidrun/clearfog/Kconfig| 19 +++
  board/solidrun/clearfog/clearfog.c | 19 ---
  2 files changed, 35 insertions(+), 3 deletions(-)
---
base-commit: 2ee7a8ec6f1711abe9619fd8765edc16742be9de
change-id: 20240106-clearfog-gtr-serdes-8a927f496bda

Sincerely,


Applied to u-boot-mavell/master

Thanks,
Stefan


Re: Pull request: Please pull u-boot-imx-20240115

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 10:02:58AM -0300, Fabio Estevam wrote:

> Hi Tom,
> 
> Please pull from u-boot-imx, thanks.
> 
> The following changes since commit 3c04fcf3137d5f694d52b8f355373e4baabe5f78:
> 
>   Merge patch series "k3-j721e: beagleboneai: Fix USB" (2024-01-20 11:39:13 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
> tags/u-boot-imx-master-20240122
> 
> for you to fetch changes up to a80e0e7711a2b2890a583d88dcd9af978ddada32:
> 
>   ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM (2024-01-22 
> 08:40:02 -0300)
> 
> u-boot-imx-master-20240122

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 0/7] board: siemens: clean up subfolders

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 11:52:30AM +0100, Enrico Leto wrote:

> The common folder was initialially created for the common parts of
> the products based on draco-am355x board family. We have the
> product lines 'pxm2', 'rut' and the base line unfortunately named
> 'draco'! Adding the new capricorn-imx8 board family, the files
> were enhanced without cleanup.
> 
> Simplify first EEPROM probe and access that implements both i2c
> with & without driver model. Use abstraction functions for this.
> 
> Move all am355x specifics to a new file 'board_am335x'.
> 
> Clean-up includes, config checks, maintainer.

To be clear, the changes to common siemens code here break the siemens
imx8 platforms, so you need to at least build test them too, in v6.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 0/6] board: siemens: clean up subfolders

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 08:33:14AM +, Leto, Enrico wrote:
> 
> 
> > -Original Message-
> > From: Tom Rini 
> > Sent: Thursday, January 18, 2024 4:16 PM
> > To: Leto, Enrico (SI BP R&D ZG FW CCP) 
> > Cc: u-boot@lists.denx.de; Sverdlin, Alexander (SI BP R&D ZG FW CCP)
> > 
> > Subject: Re: [PATCH v4 0/6] board: siemens: clean up subfolders
> > 
> > On Wed, Jan 03, 2024 at 02:31:48PM +0100, Enrico Leto wrote:
> > 
> > > This serie depends on the serie:
> > > [PATCH 0/6] siemens,am335x: clean up the draco board family
> > 
> > Is this not applied already? If not, where is it? Can you please repost it?
> > 
> 
> Yes, it's applied. I'll remove these lines.

OK.

> > > The common folder was initialially created for the common parts of
> > > the products based on draco-am355x board family. We have the
> > > product lines 'pxm2', 'rut' and the base line unfortunately named
> > > 'draco'! Adding the new capricorn-imx8 board family, the files
> > > were enhanced without cleanup.
> > >
> > > Simplify first EEPROM probe and access that implements both i2c
> > > with & without driver model. Use abstraction functions for this.
> > >
> > > Move all am355x specifics to a new file 'board_am335x'.
> > >
> > > Clean-up includes, config checks, maintainer.
> > >
> > > Signed-off-by: Enrico Leto 
> > 
> > The problem is that I see:
> > 
> > 
> > > ---
> > >rm:  +   draco-etamin
> > +(draco-etamin) board/siemens/draco/../common/board.c: In function
> > 'board_init':
> > +(draco-etamin) board/siemens/draco/../common/board.c:88:9: error:
> > implicit declaration of function 'board_nand_cs_init' [-Werror=implicit-
> > function-declaration]
> > +(draco-etamin)88 | board_nand_cs_init();
> > +(draco-etamin)   | ^~
> > +(draco-etamin) cc1: all warnings being treated as errors
> > +(draco-etamin) make[2]: *** [scripts/Makefile.build:257:
> > +board/siemens/draco/../common/board.o] Error 1
> > +(draco-etamin) make[1]: *** [Makefile:1859: board/siemens/draco] Error
> > +2
> > +(draco-etamin) make: *** [Makefile:177: sub-make] Error 2
> 
> I'll check why I have not seen this problem by me and fix it.

Thanks.

> >aarch64:  +   Deneb
> > +(deneb) WARNING 'ahab-container.img' not found, resulting binary is
> > +not-functional
> > +(deneb) aarch64-linux-ld.bfd:
> > board/siemens/capricorn/../common/factoryset.o: in function
> > `factoryset_read_eeprom':
> > +(deneb)
> > board/siemens/capricorn/../common/factoryset.c:149:(.text.factoryset_read
> > _eeprom+0x2c): undefined reference to `siemens_ee_read_data'
> > +(deneb) aarch64-linux-ld.bfd:
> > board/siemens/capricorn/../common/factoryset.c:177:(.text.factoryset_read
> > _eeprom+0xb4): undefined reference to `siemens_ee_read_data'
> > +(deneb) aarch64-linux-ld.bfd:
> > board/siemens/capricorn/../common/factoryset.c:172:(.text.factoryset_read
> > _eeprom+0x264): undefined reference to `siemens_ee_read_data'
> > +(deneb) make[1]: *** [Makefile:1766: u-boot] Error 139
> > +(deneb) make[1]: *** Deleting file 'u-boot'
> > +(deneb) make: *** [Makefile:177: sub-make] Error 2
> >aarch64:  +   giedi
> > +(giedi) WARNING 'ahab-container.img' not found, resulting binary is
> > +not-functional
> > +(giedi) aarch64-linux-ld.bfd:
> > board/siemens/capricorn/../common/factoryset.o: in function
> > `factoryset_read_eeprom':
> > +(giedi)
> > board/siemens/capricorn/../common/factoryset.c:149:(.text.factoryset_read
> > _eeprom+0x2c): undefined reference to `siemens_ee_read_data'
> > +(giedi) aarch64-linux-ld.bfd:
> > board/siemens/capricorn/../common/factoryset.c:177:(.text.factoryset_read
> > _eeprom+0xb4): undefined reference to `siemens_ee_read_data'
> > +(giedi) aarch64-linux-ld.bfd:
> > board/siemens/capricorn/../common/factoryset.c:172:(.text.factoryset_read
> > _eeprom+0x264): undefined reference to `siemens_ee_read_data'
> > +(giedi) make[1]: *** [Makefile:1766: u-boot] Error 139
> > +(giedi) make[1]: *** Deleting file 'u-boot'
> > +(giedi) make: *** [Makefile:177: sub-make] Error 2
> 
> 'giedi' & 'deneb' are based on imx8x board. This is another family that are
> not affected from this patch serie.

Well, you're changing the common siemens code and that does change those
platforms as they use it too, which is why they fail now.

> This patch serie is not the cause of these warnings and will not resolve them.

The ahab messages are expected when we don't have all of the blobs, and
that's fine.

> Additional info.
> We also have everywhere this warning since u-boot version 2020 or 2021. This
> doesn't affect the u-boot/SPL outputs. The complete boot container incl.
> 'ahab-container.img' is built separately with the mkimage tool of NXP.
> On first appearing of this warning we asked NXP. They didn't improve any
> solution. Maybe there is now a setting to remove this warning.
> A patch serie is planned for our imx8x boards.

OK.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 00/13] arm: exynos: Add E850-96 board

2024-01-22 Thread Sam Protsenko
Hey Tom, Minkyu,

If there are no outstanding concerns about this series, can you please apply it?

Thanks!

On Wed, Jan 10, 2024 at 9:09 PM Sam Protsenko
 wrote:
>
> Add Exynos850 SoC and WinLink's E850-96 board support. A short overview
> of series additions and modifications:
>   * USI driver: configures UART block
>   * PMU driver: connects AP UART lines to uart1 pins)
>   * Exynos850 clock driver: generates UART clocks
>   * Exynos850 pinctrl driver: mux UART pins
>   * serial_s5p: UART driver
>   * Exynos850 SoC: dtsi files and MMU maps
>   * E850-96 board: dts files, defconfig, board file and doc
>
> Most of the code was borrowed from mainline Linux kernel (where this
> board is already enabled) and adapted for U-Boot. Preliminary
> preparation for this series includes next patches / series (already
> merged):
>
>   * commit 585a2aaac2ac ("arm: exynos: Include missing CPU header in
>   soc.c")
>   * commit c9ab9f30c8e4 ("arm: exynos: Include missing CPU header in
>   gpio.h")
>   * commit 11bd2787deff ("watchdog: s5p_wdt: Include missing CPU
>   header")
>   * commit 08cfa971a717 ("exynos: Avoid duplicate reset_cpu with
>   SYSRESET enabled")
>   * commit f655090901dc ("clk: exynos: Add header guard for clk-pll.h")
>   * commit 2227f4c0afed ("serial: s5p: Fix clk_get_by_index() error code
>   check")
>   * commit a0615ffc99a5 ("serial: s5p: Remove common.h inclusion")
>   * commit 5ad21de6bae0 ("serial: s5p: Use livetree API to get "id"
>   property")
>   * commit e79f630dbf67 ("serial: s5p: Use named constants for register
>   values")
>   * commit a627f2802a71 ("serial: s5p: Improve coding style")
>   * commit 33e7ca5a9b6a ("serial: s5p: Use dev_read_addr_ptr() to get
>   base address")
>   * commit 6219b47c4d91 ("board: samsung: Fix SYS_CONFIG_NAME configs in
>   axy17lte Kconfig")
>   * commit 470682ace1e0 ("configs: Remove unneeded SYS_CONFIG_NAME from
>   a*y17lte defconfigs")
>
> and series [1]. For more detailed description please see the board
> documentation (added in PATCH #12) and corresponding commit messages.
>
> Changes in v2:
>   - PATCH 4: Removed unnecessary mode param
>   - PATCH 4: Removed usi->dev and used priv data instead
>   - PATCH 4: Used .of_plat_data callback for dts parsing
>   - PATCH 7: Fixed Thomas Abraham e-mail
>   - PATCH 9: Fixed incorrect driver description (comment)
>   - Collected Reviewed-by tags
>   - Rebased on top of most recent U-Boot/master
>
> [1] https://lists.denx.de/pipermail/u-boot/2023-November/539033.html
>
> Sam Protsenko (13):
>   dt-bindings: soc: samsung: Add Exynos USI
>   dt-bindings: soc: samsung: Add Exynos PMU
>   dt-bindings: clock: Add Exynos850 clock controller
>   soc: samsung: Add Exynos USI driver
>   soc: samsung: Add Exynos PMU driver
>   clk: exynos: Move pll code into clk-exynos7420
>   clk: exynos: Add Samsung clock framework
>   clk: exynos: Add Exynos850 clock driver
>   pinctrl: exynos: Add pinctrl support for Exynos850
>   serial: s5p: Add Exynos850 compatible
>   arm: exynos: Add Exynos850 SoC support
>   board: samsung: Add support for E850-96 board
>   MAINTAINERS: Add new Samsung subsystems
>
>  MAINTAINERS   |   25 +
>  arch/arm/dts/Makefile |1 +
>  arch/arm/dts/exynos-pinctrl.h |   79 +
>  arch/arm/dts/exynos850-e850-96-u-boot.dtsi|   37 +
>  arch/arm/dts/exynos850-e850-96.dts|  273 
>  arch/arm/dts/exynos850-pinctrl.dtsi   |  663 +
>  arch/arm/dts/exynos850.dtsi   |  809 +++
>  arch/arm/mach-exynos/Kconfig  |   28 +-
>  arch/arm/mach-exynos/mmu-arm64.c  |   34 +
>  board/samsung/e850-96/Kconfig |   16 +
>  board/samsung/e850-96/MAINTAINERS |9 +
>  board/samsung/e850-96/Makefile|6 +
>  board/samsung/e850-96/e850-96.c   |   22 +
>  configs/e850-96_defconfig |   21 +
>  doc/board/samsung/e850-96.rst |   87 ++
>  .../img/exynos850-boot-architecture.svg   | 1283 +
>  doc/board/samsung/index.rst   |1 +
>  .../clock/samsung,exynos850-clock.yaml|  307 
>  .../soc/samsung/exynos-pmu.yaml   |   85 ++
>  .../soc/samsung/exynos-usi.yaml   |  162 +++
>  drivers/clk/exynos/Kconfig|7 +
>  drivers/clk/exynos/Makefile   |   11 +-
>  drivers/clk/exynos/clk-exynos7420.c   |   25 +-
>  drivers/clk/exynos/clk-exynos850.c|  189 +++
>  drivers/clk/exynos/clk-pll.c  |  167 ++-
>  drivers/clk/exynos/clk-pll.h  |   16 +-
>  drivers/clk/exynos/clk.c  |  121 ++
>  dr

[PATCH] ARM: imx: Enable kaslrseed command on Data Modul i.MX8M Mini/Plus eDM SBC

2024-01-22 Thread Marek Vasut
Linux 6.6.y with KASLR enabled would print the following message on boot:
"
KASLR disabled due to lack of seed
"
Enable the 'kaslrseed' command so a random number seed can be pulled
from CAAM and inserted into the /chosen node 'kaslr-seed' property of
Linux kernel DT before boot, thus letting KASLR work properly.

Signed-off-by: Marek Vasut 
---
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 configs/imx8mm_data_modul_edm_sbc_defconfig | 2 ++
 configs/imx8mp_data_modul_edm_sbc_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig 
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index f945aea82d7..bbd6ac053ba 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -115,6 +115,7 @@ CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_GETTIME=y
+CONFIG_CMD_KASLRSEED=y
 CONFIG_CMD_SYSBOOT=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
@@ -210,6 +211,7 @@ CONFIG_DM_REGULATOR_BD71837=y
 CONFIG_SPL_DM_REGULATOR_BD71837=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RNG=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
diff --git a/configs/imx8mp_data_modul_edm_sbc_defconfig 
b/configs/imx8mp_data_modul_edm_sbc_defconfig
index d29bc986267..a3e25ea22ab 100644
--- a/configs/imx8mp_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mp_data_modul_edm_sbc_defconfig
@@ -122,6 +122,7 @@ CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_GETTIME=y
+CONFIG_CMD_KASLRSEED=y
 CONFIG_CMD_SYSBOOT=y
 CONFIG_CMD_UUID=y
 CONFIG_CMD_PMIC=y
@@ -229,6 +230,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
 CONFIG_SPL_DM_REGULATOR_PCA9450=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RNG=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
-- 
2.43.0



Re: Pull request efi-2024-04-rc1-3

2024-01-22 Thread Tom Rini
On Sun, Jan 21, 2024 at 12:46:05PM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 3c04fcf3137d5f694d52b8f355373e4baabe5f78:
> 
>   Merge patch series "k3-j721e: beagleboneai: Fix USB" (2024-01-20
> 11:39:13 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2024-04-rc1-3
> 
> for you to fetch changes up to 2c98f7435cc5edb2a0b96e9f398c0b7f084e83cd:
> 
>   efi_loader: return immediately in UCLASS_EFI_LOADER removal
> (2024-01-21 11:24:24 +0100)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/19394
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request: SoCFPGA changes for commit 3c9bb8fbdc77f

2024-01-22 Thread Tom Rini
On Mon, Jan 22, 2024 at 09:30:40AM +, Chee, Tien Fong wrote:

> Hi Tom,
> 
> Please pull the SoCFPGA changes as shown in below.
> 
> Best regards,
> Tien Fong
> 
> The following changes since commit 3c04fcf3137d5f694d52b8f355373e4baabe5f78:
> 
>   Merge patch series "k3-j721e: beagleboneai: Fix USB" (2024-01-20 11:39:13 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://github.com/tienfong/uboot_mainline.git 
> 3c9bb8fbdc77f6bd56e97597d875d8965db3b96c

Lets talk off-list about getting things moved to
https://source.denx.de/u-boot/custodians/u-boot-socfpga/ please.

> 
> for you to fetch changes up to 3c9bb8fbdc77f6bd56e97597d875d8965db3b96c:
> 
>   arm: dts: agilex: Increase reserved memory size to 32MB (2024-01-22 
> 16:51:29 +0800)

There's a few more patches showing under:
https://patchwork.ozlabs.org/project/uboot/list/?q=socfpga are they
ready or need changes?

Otherwise, applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] x86: Make default_print_cpuinfo be a weak alias for print_cpuinfo

2024-01-22 Thread Tom Rini
While a few SoCs have a unique print_cpuinfo function, a number of them
just use default_print_cpuinfo. Make default_print_cpuinfo have a weak
alias to provie print_cpuinfo.

Signed-off-by: Tom Rini 
---
This will make re-using arch/x86/cpu/efi/ as a generic set of support
code for U-Boot as EFI payload/app a little bit easier.

Cc: Simon Glass 
Cc: Bin Meng 
---
 arch/x86/cpu/coreboot/coreboot.c | 5 -
 arch/x86/cpu/cpu.c   | 2 ++
 arch/x86/cpu/efi/app.c   | 5 -
 arch/x86/cpu/efi/payload.c   | 5 -
 arch/x86/cpu/slimbootloader/slimbootloader.c | 5 -
 arch/x86/cpu/tangier/tangier.c   | 5 -
 6 files changed, 2 insertions(+), 25 deletions(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 82fe4c71cd27..5c8d32ff6acd 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -44,11 +44,6 @@ int checkcpu(void)
return 0;
 }
 
-int print_cpuinfo(void)
-{
-   return default_print_cpuinfo();
-}
-
 static void board_final_init(void)
 {
/*
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index ce55efc454bf..5090f5cad746 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -165,6 +165,8 @@ char *cpu_get_name(char *name)
return ptr;
 }
 
+int print_cpuinfo(void) __attribute__((weak, alias("default_print_cpuinfo")));
+
 int default_print_cpuinfo(void)
 {
printf("CPU: %s, vendor %s, device %xh\n",
diff --git a/arch/x86/cpu/efi/app.c b/arch/x86/cpu/efi/app.c
index f754489784a7..0eea9e2b0975 100644
--- a/arch/x86/cpu/efi/app.c
+++ b/arch/x86/cpu/efi/app.c
@@ -19,11 +19,6 @@ int checkcpu(void)
return 0;
 }
 
-int print_cpuinfo(void)
-{
-   return default_print_cpuinfo();
-}
-
 void board_final_init(void)
 {
 }
diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
index 708bfbe7ee48..2bf4fefc19e6 100644
--- a/arch/x86/cpu/efi/payload.c
+++ b/arch/x86/cpu/efi/payload.c
@@ -144,11 +144,6 @@ int checkcpu(void)
return 0;
 }
 
-int print_cpuinfo(void)
-{
-   return default_print_cpuinfo();
-}
-
 /* Find any available tables and copy them to a safe place */
 int reserve_arch(void)
 {
diff --git a/arch/x86/cpu/slimbootloader/slimbootloader.c 
b/arch/x86/cpu/slimbootloader/slimbootloader.c
index ec5b87cfd63f..1f98db1f7c77 100644
--- a/arch/x86/cpu/slimbootloader/slimbootloader.c
+++ b/arch/x86/cpu/slimbootloader/slimbootloader.c
@@ -55,8 +55,3 @@ int checkcpu(void)
 {
return 0;
 }
-
-int print_cpuinfo(void)
-{
-   return default_print_cpuinfo();
-}
diff --git a/arch/x86/cpu/tangier/tangier.c b/arch/x86/cpu/tangier/tangier.c
index 1e2f6cc8b700..35bbecbf8479 100644
--- a/arch/x86/cpu/tangier/tangier.c
+++ b/arch/x86/cpu/tangier/tangier.c
@@ -20,8 +20,3 @@ int checkcpu(void)
 {
return 0;
 }
-
-int print_cpuinfo(void)
-{
-   return default_print_cpuinfo();
-}
-- 
2.34.1



[PATCH v3 4/5] net: hifemac: implement `net stats` needed ops

2024-01-22 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

3 operations needed by `net stats` are implemented. New `net stats`
output some useful info.

Signed-off-by: Yang Xiwen 
---
 drivers/net/hifemac.c | 87 +++
 1 file changed, 87 insertions(+)

diff --git a/drivers/net/hifemac.c b/drivers/net/hifemac.c
index 39c0233b62..d24023eefd 100644
--- a/drivers/net/hifemac.c
+++ b/drivers/net/hifemac.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -125,6 +127,57 @@ struct hisi_femac_priv {
u32 link_status;
 };
 
+struct hisi_femac_stat_entry {
+   const char *name;
+   u32 offset;
+   u32 mask;
+};
+
+/* please refer to the datasheet for the description of these entries */
+static const struct hisi_femac_stat_entry hisi_femac_stats_table[] = {
+   { "rxsof_cnt",  0x584,  GENMASK(31, 28) },
+   { "rxeof_cnt",  0x584,  GENMASK(27, 24) },
+   { "rxcrcok_cnt",0x584,  GENMASK(23, 20) },
+   { "rxcrcbad_cnt",   0x584,  GENMASK(19, 16) },
+   { "txsof_cnt",  0x584,  GENMASK(15, 12) },
+   { "txeof_cnt",  0x584,  GENMASK(11, 8) },
+   { "txcrcok_cnt",0x584,  GENMASK(7, 4) },
+   { "txcrcbad_cnt",   0x584,  GENMASK(3, 0) },
+   { "pkts_cpu",   0x5a0,  GENMASK(15, 0) },
+   { "addr_cpu",   0x5a4,  GENMASK(15, 0) },
+   { "pkts_port",  0x5a8,  GENMASK(15, 0) },
+   { "pkts_cpu2tx",0x5ac,  GENMASK(15, 0) },
+   { "rxdvrise",   0x600,  GENMASK(31, 0) },
+   { "ifinoctets", 0x604,  GENMASK(31, 0) },
+   { "octets_rx",  0x608,  GENMASK(31, 0) },
+   { "local_mac_match",0x60c,  GENMASK(31, 0) },
+   { "pkts",   0x610,  GENMASK(31, 0) },
+   { "broadcastpkts",  0x614,  GENMASK(31, 0) },
+   { "multicastpkts",  0x618,  GENMASK(31, 0) },
+   { "ifinucastpkts",  0x61c,  GENMASK(31, 0) },
+   { "ifinerrors", 0x620,  GENMASK(31, 0) },
+   { "crcerr", 0x624,  GENMASK(31, 0) },
+   { "abnormalsizepkts",   0x628,  GENMASK(31, 0) },
+   { "dot3alignmenterr",   0x62c,  GENMASK(31, 0) },
+   { "dot3pause",  0x630,  GENMASK(31, 0) },
+   { "dropevents", 0x634,  GENMASK(31, 0) },
+   { "flux_frame_cnt", 0x638,  GENMASK(31, 0) },
+   { "flux_drop_cnt",  0x63c,  GENMASK(31, 0) },
+   { "mac_not2cpu_pkts",   0x64c,  GENMASK(31, 0) },
+   { "pkts_tx",0x780,  GENMASK(31, 0) },
+   { "broadcastpkts_tx",   0x784,  GENMASK(31, 0) },
+   { "multicastpkts_tx",   0x788,  GENMASK(31, 0) },
+   { "ifoutucastpkts_tx",  0x78c,  GENMASK(31, 0) },
+   { "octets_tx",  0x790,  GENMASK(31, 0) },
+   { "dot3pause",  0x794,  GENMASK(31, 0) },
+   { "retry_times_tx", 0x798,  GENMASK(31, 0) },
+   { "collisions", 0x79c,  GENMASK(31, 0) },
+   { "dot3latecol",0x7a0,  GENMASK(31, 0) },
+   { "dot3colok",  0x7a4,  GENMASK(31, 0) },
+   { "dot3excessivecol",   0x7a8,  GENMASK(31, 0) },
+   { "dot3colcnt", 0x7ac,  GENMASK(31, 0) },
+};
+
 static void hisi_femac_irq_enable(struct hisi_femac_priv *priv, int irqs)
 {
u32 val;
@@ -334,6 +387,37 @@ static void hisi_femac_stop(struct udevice *dev)
writel(SOFT_RESET_ALL, priv->glb_base + GLB_SOFT_RESET);
 }
 
+static int hisi_femac_get_sset_count(struct udevice *dev)
+{
+   return ARRAY_SIZE(hisi_femac_stats_table);
+}
+
+static void hisi_femac_get_strings(struct udevice *dev, u8 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(hisi_femac_stats_table); i++)
+   strcpy(data + i * ETH_GSTRING_LEN, 
hisi_femac_stats_table[i].name);
+}
+
+/* Non-constant mask variant of FIELD_GET/FIELD_PREP */
+#define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
+
+static void hisi_femac_get_stats(struct udevice *dev, u64 *data)
+{
+   int i;
+   u32 mask, reg;
+   struct hisi_femac_priv *priv = dev_get_priv(dev);
+   void __iomem *port_base = priv->port_base;
+
+   for (i = 0; i < ARRAY_SIZE(hisi_femac_stats_table); i++) {
+   mask = hisi_femac_stats_table[i].mask;
+   reg = readl(port_base + hisi_femac_stats_table[i].offset);
+
+   data[i] = field_get(mask, reg);
+   }
+}
+
 int hisi_femac_of_to_plat(struct udevice *dev)
 {
int ret, i;
@@ -523,6 +607,9 @@ static const struct eth_ops hisi_femac_ops = {
.free_pkt   = hisi_femac_free_pkt,
.stop   = hisi_femac_stop,
.write_hwaddr   = hisi_femac_set_hw_mac_addr,
+   .get_sset_count = hisi_femac_get_sset_count,
+   .get_strings= hisi_femac_get_strings,
+   .get_stats  = hisi_femac_get_stats,
 };
 
 static const struct udevice_id hisi_femac_ids[] = {

-- 
2.43.0



[PATCH v3 1/5] net: hifemac_mdio: use log_msg_ret() correctly, report error by dev_err()

2024-01-22 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

The initial commit used log_msg_ret() wrongly. Fix that by moving error
report to a separate dev_err() call and shrink the first argument of
log_msg_ret() to no more than 4 chars.

Fixes: 6b5c8d98e204 ("net: add hifemac_mdio MDIO bus driver for HiSilicon 
platform")

Signed-off-by: Yang Xiwen 
---
 drivers/net/hifemac_mdio.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/hifemac_mdio.c b/drivers/net/hifemac_mdio.c
index 343c5f3a38..0b59d06091 100644
--- a/drivers/net/hifemac_mdio.c
+++ b/drivers/net/hifemac_mdio.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -74,7 +75,8 @@ static int hisi_femac_mdio_of_to_plat(struct udevice *dev)
data->membase = dev_remap_addr(dev);
if (IS_ERR(data->membase)) {
ret = PTR_ERR(data->membase);
-   return log_msg_ret("Failed to remap base addr", ret);
+   dev_err(dev, "Failed to remap base addr %d\n", ret);
+   return log_msg_ret("mdio", ret);
}
 
// clk is optional
@@ -89,8 +91,10 @@ static int hisi_femac_mdio_probe(struct udevice *dev)
int ret;
 
ret = clk_prepare_enable(data->clk);
-   if (ret)
-   return log_msg_ret("Failed to enable clk", ret);
+   if (ret) {
+   dev_err(dev, "Failed to enable clock: %d\n", ret);
+   return log_msg_ret("clk", ret);
+   }
 
return 0;
 }
@@ -112,5 +116,6 @@ U_BOOT_DRIVER(hisi_femac_mdio_driver) = {
.of_to_plat = hisi_femac_mdio_of_to_plat,
.probe = hisi_femac_mdio_probe,
.ops = &hisi_femac_mdio_ops,
+   .plat_auto = sizeof(struct mdio_perdev_priv),
.priv_auto = sizeof(struct hisi_femac_mdio_data),
 };

-- 
2.43.0



[PATCH v3 3/5] net: hifemac: register MDIO bus device for subnode

2024-01-22 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

register internal MDIO bus device if it is a subnode.

Signed-off-by: Yang Xiwen 
---
 drivers/net/hifemac.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/hifemac.c b/drivers/net/hifemac.c
index 1088f3eca3..39c0233b62 100644
--- a/drivers/net/hifemac.c
+++ b/drivers/net/hifemac.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -337,6 +338,8 @@ int hisi_femac_of_to_plat(struct udevice *dev)
 {
int ret, i;
struct hisi_femac_priv *priv = dev_get_priv(dev);
+   ofnode mdio_node;
+   bool mdio_registered = false;
static const char * const clk_strs[] = {
[CLK_MAC] = "mac",
[CLK_BUS] = "bus",
@@ -388,6 +391,31 @@ int hisi_femac_of_to_plat(struct udevice *dev)
 MAC_RESET_DELAY_PROPERTY,
 MAC_RESET_ASSERT_PERIOD);
 
+   /* Create MDIO bus */
+   ofnode_for_each_subnode(mdio_node, dev_ofnode(dev)) {
+   const char *subnode_name = ofnode_get_name(mdio_node);
+   struct udevice *mdiodev;
+
+   // Skip subnodes not starting with "mdio"
+   if (strncmp(subnode_name, "mdio", 4))
+   continue;
+
+   ret = device_bind_driver_to_node(dev, "hisi-femac-mdio",
+subnode_name, mdio_node, 
&mdiodev);
+   if (ret) {
+   dev_err(dev, "Failed to register MDIO bus device %d\n", 
ret);
+   return log_msg_ret("net", ret);
+   }
+
+   mdio_registered = true;
+   break;
+   }
+
+   if (!mdio_registered) {
+   dev_err(dev, "No MDIO subnode is found!\n");
+   return log_msg_ret("mdio", -ENODATA);
+   }
+
return 0;
 }
 

-- 
2.43.0



[PATCH v3 2/5] net: hifemac: fix log reporting

2024-01-22 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

shrink the first argument of log_msg_ret(), add dev_xxx() functions for
error reporting.

Fixes: 9d8f78a2a79f7 ("net: add hifemac Ethernet driver for HiSilicon platform")

Signed-off-by: Yang Xiwen 
---
 drivers/net/hifemac.c | 110 +-
 1 file changed, 73 insertions(+), 37 deletions(-)

diff --git a/drivers/net/hifemac.c b/drivers/net/hifemac.c
index b61a29e636..1088f3eca3 100644
--- a/drivers/net/hifemac.c
+++ b/drivers/net/hifemac.c
@@ -245,8 +245,10 @@ static int hisi_femac_start(struct udevice *dev)
hisi_femac_rx_refill(priv);
 
ret = phy_startup(priv->phy);
-   if (ret)
-   return log_msg_ret("Failed to startup phy", ret);
+   if (ret) {
+   dev_err(dev, "Failed to startup phy: %d\n", ret);
+   return log_msg_ret("phy", ret);
+   }
 
if (!priv->phy->link) {
debug("%s: link down\n", __func__);
@@ -281,8 +283,10 @@ static int hisi_femac_send(struct udevice *dev, void 
*packet, int length)
 
// wait until FIFO is empty
ret = wait_for_bit_le32(priv->glb_base + GLB_IRQ_RAW, 
IRQ_INT_TX_PER_PACKET, true, 50, false);
-   if (ret == -ETIMEDOUT)
-   return log_msg_ret("FIFO timeout", ret);
+   if (ret == -ETIMEDOUT) {
+   dev_err(dev, "FIFO timeout\n");
+   return log_msg_ret("net", ret);
+   }
 
return 0;
 }
@@ -340,35 +344,45 @@ int hisi_femac_of_to_plat(struct udevice *dev)
};
 
priv->port_base = dev_remap_addr_name(dev, "port");
-   if (IS_ERR(priv->port_base))
-   return log_msg_ret("Failed to remap port address space", 
PTR_ERR(priv->port_base));
+   if (!priv->port_base) {
+   dev_err(dev, "Failed to remap port address space\n");
+   return log_msg_ret("net", -EINVAL);
+   }
 
priv->glb_base = dev_remap_addr_name(dev, "glb");
-   if (IS_ERR(priv->glb_base))
-   return log_msg_ret("Failed to remap global address space", 
PTR_ERR(priv->glb_base));
+   if (IS_ERR(priv->glb_base)) {
+   dev_err(dev, "Failed to remap global address space\n");
+   return log_msg_ret("net", -EINVAL);
+   }
 
for (i = 0; i < ARRAY_SIZE(clk_strs); i++) {
priv->clks[i] = devm_clk_get(dev, clk_strs[i]);
if (IS_ERR(priv->clks[i])) {
dev_err(dev, "Error getting clock %s\n", clk_strs[i]);
-   return log_msg_ret("Failed to get clocks", 
PTR_ERR(priv->clks[i]));
+   return log_msg_ret("clk", PTR_ERR(priv->clks[i]));
}
}
 
priv->mac_rst = devm_reset_control_get(dev, "mac");
-   if (IS_ERR(priv->mac_rst))
-   return log_msg_ret("Failed to get MAC reset", 
PTR_ERR(priv->mac_rst));
+   if (IS_ERR(priv->mac_rst)) {
+   dev_err(dev, "Failed to get MAC reset %ld\n", 
PTR_ERR(priv->mac_rst));
+   return log_msg_ret("rst", PTR_ERR(priv->mac_rst));
+   }
 
priv->phy_rst = devm_reset_control_get(dev, "phy");
-   if (IS_ERR(priv->phy_rst))
-   return log_msg_ret("Failed to get PHY reset", 
PTR_ERR(priv->phy_rst));
+   if (IS_ERR(priv->phy_rst)) {
+   dev_err(dev, "Failed to get PHY reset %ld\n", 
PTR_ERR(priv->phy_rst));
+   return log_msg_ret("rst", PTR_ERR(priv->phy_rst));
+   }
 
ret = dev_read_u32_array(dev,
 PHY_RESET_DELAYS_PROPERTY,
 priv->phy_reset_delays,
 DELAYS_NUM);
-   if (ret < 0)
-   return log_msg_ret("Failed to get PHY reset delays", ret);
+   if (ret < 0) {
+   dev_err(dev, "Failed to get PHY reset delays %d\n", ret);
+   return log_msg_ret("rst", ret);
+   }
 
priv->mac_reset_delay = dev_read_u32_default(dev,
 MAC_RESET_DELAY_PROPERTY,
@@ -385,32 +399,44 @@ static int hisi_femac_phy_reset(struct hisi_femac_priv 
*priv)
 
// Disable MAC clk before phy reset
ret = clk_disable(priv->clks[CLK_MAC]);
-   if (ret < 0)
-   return log_msg_ret("Failed to disable MAC clock", ret);
+   if (ret < 0) {
+   pr_err("%s: Failed to disable MAC clock %d\n", __func__, ret);
+   return log_msg_ret("clk", ret);
+   }
ret = clk_disable(priv->clks[CLK_BUS]);
-   if (ret < 0)
-   return log_msg_ret("Failed to disable bus clock", ret);
+   if (ret < 0) {
+   pr_err("%s: Failed to disable bus clock %d\n", __func__, ret);
+   return log_msg_ret("clk", ret);
+   }
 
udelay(delays[PRE_DELAY]);
 
ret = reset_assert(rst);
-   if (ret < 0)
-   return log_msg_ret("Failed to assert reset", ret);
+   if (ret < 0) {
+   

[PATCH v3 0/5] net: hifemac: a few cleanups

2024-01-22 Thread Yang Xiwen via B4 Relay
- Fix the use of log_msg_ret() and add dev_xxx() for error reporting.
- Register mdio subnode as a mdio bus device for hifemac.
- Implement ops needed by `net stats`
- Make functions static.

Signed-off-by: Yang Xiwen 
---
Changes in v3:
- hisi-femac: add missing `static` to avoid polluting global namespace.
- Link to v2: 
https://lore.kernel.org/r/20240122-net-v2-0-78a368896...@outlook.com

Changes in v2:
- hisi-femac: add statistics related operations
- Link to v1: 
https://lore.kernel.org/r/20240119-net-v1-0-d1feb8e16...@outlook.com

---
Yang Xiwen (5):
  net: hifemac_mdio: use log_msg_ret() correctly, report error by dev_err()
  net: hifemac: fix log reporting
  net: hifemac: register MDIO bus device for subnode
  net: hifemac: implement `net stats` needed ops
  net: hifemac: make some functions static

 drivers/net/hifemac.c  | 229 +
 drivers/net/hifemac_mdio.c |  11 ++-
 2 files changed, 198 insertions(+), 42 deletions(-)
---
base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3
change-id: 20240119-net-72a32675eeb4

Best regards,
-- 
Yang Xiwen 



[PATCH v3 5/5] net: hifemac: make some functions static

2024-01-22 Thread Yang Xiwen via B4 Relay
From: Yang Xiwen 

They are not required to be global, make them static.

Signed-off-by: Yang Xiwen 
---
 drivers/net/hifemac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hifemac.c b/drivers/net/hifemac.c
index d24023eefd..90cc247b3b 100644
--- a/drivers/net/hifemac.c
+++ b/drivers/net/hifemac.c
@@ -418,7 +418,7 @@ static void hisi_femac_get_stats(struct udevice *dev, u64 
*data)
}
 }
 
-int hisi_femac_of_to_plat(struct udevice *dev)
+static int hisi_femac_of_to_plat(struct udevice *dev)
 {
int ret, i;
struct hisi_femac_priv *priv = dev_get_priv(dev);
@@ -553,7 +553,7 @@ static int hisi_femac_phy_reset(struct hisi_femac_priv 
*priv)
return 0;
 }
 
-int hisi_femac_probe(struct udevice *dev)
+static int hisi_femac_probe(struct udevice *dev)
 {
struct hisi_femac_priv *priv = dev_get_priv(dev);
int ret, i;

-- 
2.43.0



Re: [PATCH v4 0/6] rpi5: initial support

2024-01-22 Thread Mark Kettenis
> Date: Mon, 22 Jan 2024 16:16:34 +0200
> From: "Ivan T. Ivanov" 
> 
> Hi,
> 
> On 01-22 13:57, Ivan T. Ivanov wrote:
> > > Am 20.01.24 um 10:48 schrieb Jens Maus:
> > >> Hi,
> > >> 
> > >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren :
> > >>> 
> > >>> Am 19.01.24 um 22:26 schrieb Jens Maus:
> >  I actually do have some good and bad news:
> >  
> >  1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB 
> >  both on the HDMI and on the serial debug UART like you reported.
> >  
> >  2. Bad news: I actually got it working by downgrading the rpi-eeprom 
> >  to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
> >  
> > > 
> > > One idea would be to enable early debug in U-Boot (no idea how to
> > > achieve this). I assume U-Boot crashes before it's able to print the
> > > first line, but it's hard to believe it crashes at the very first
> > > instruction of U-Boot. So with some luck we should be able to narrow
> > > done the cause.
> > 
> > I was able to enable early debug UART in U-Boot and I will try to
> > find what is happening, once I get some free cycles.
> 
> Ok, this was relatively easy to find :-)
> 
> New versions of EEPROM firmware change “kernel”/U-Boot load address 
> from 0x8 to 0x20. And because on RPi’s CONFIG_TEXT_BASE is
> hardcoded to 0x8 code run through the fields. 
> 
> Hopefully simple patch like bellow make it work fine in older and
> newer EEPROM firmware versions.
> 
> Regards,
> Ivan  
> 
> diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> index 11ede9435d..ce64f9554f 100644
> --- a/configs/rpi_arm64_defconfig
> +++ b/configs/rpi_arm64_defconfig
> @@ -1,6 +1,7 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_BCM283X=y
>  CONFIG_TEXT_BASE=0x0008
> +CONFIG_POSITION_INDEPENDENT=y

Not sure if it really matters, but for the Apple M1 config I set
CONFIG_TEXT_BASE to 0x (zero).


Re: Re: [PATCH v4 0/6] rpi5: initial support

2024-01-22 Thread Ivan T. Ivanov
Hi,

On 01-22 13:57, Ivan T. Ivanov wrote:
> > Am 20.01.24 um 10:48 schrieb Jens Maus:
> >> Hi,
> >> 
> >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren :
> >>> 
> >>> Am 19.01.24 um 22:26 schrieb Jens Maus:
>  I actually do have some good and bad news:
>  
>  1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB 
>  both on the HDMI and on the serial debug UART like you reported.
>  
>  2. Bad news: I actually got it working by downgrading the rpi-eeprom to 
>  the same 2023/10/30 (VERSION:30de0ba5) version like you have.
>  
> > 
> > One idea would be to enable early debug in U-Boot (no idea how to
> > achieve this). I assume U-Boot crashes before it's able to print the
> > first line, but it's hard to believe it crashes at the very first
> > instruction of U-Boot. So with some luck we should be able to narrow
> > done the cause.
> 
> I was able to enable early debug UART in U-Boot and I will try to
> find what is happening, once I get some free cycles.

Ok, this was relatively easy to find :-)

New versions of EEPROM firmware change “kernel”/U-Boot load address 
from 0x8 to 0x20. And because on RPi’s CONFIG_TEXT_BASE is
hardcoded to 0x8 code run through the fields. 

Hopefully simple patch like bellow make it work fine in older and
newer EEPROM firmware versions.

Regards,
Ivan  

diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 11ede9435d..ce64f9554f 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_BCM283X=y
 CONFIG_TEXT_BASE=0x0008
+CONFIG_POSITION_INDEPENDENT=y



Re: [PATCH v4 0/6] rpi5: initial support

2024-01-22 Thread Matthias Brugger




On 10/01/2024 13:29, Ivan T. Ivanov wrote:

Hi,

These patches are slight update for patches posted earlier here[1].
They are adding basic support for RPi5 and are based on v2 series
from Dmitry Malkin[2].

What changed:

* Initial memory map now includes whole first 1GB of DRAM. At runtime,
   the firmware will adjust this size depending on whether an HDMI cable
   is plugged in or not. If there is HDMI monitor connected it will reserve
   framebufer memory region and will add simple-framebuffer device into
   devicetree.

* Dynamically calculate bits per pixel in video driver. This works
   on all prevous RPi's models that I have.

* I am dropping PCIe patch for now. I made some progress on porting changes
   from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit
   tricky. They are many devices behind PCIe, but more or less all of them
   requires missing either "reset-controller" or "clock-controller" or
   "pin-controller" drivers. I was able to probe "cdns,macb" device, but
   access to ethernet PHY over MDIO bus is stucking. Then I ported
   "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires
   missing clock. And on top of that machine that I used for developing this
   crashed and I lost my PCIe changes :-|. Anyway.

These patches allows me to boot current openSUSE Tumbleweed without
modification. I can see serial console log and boot process on HDMI
connected monitor.

I think these patches should be enough for start. Please consider for
inclusion.

Thanks,
Ivan

[1] https://lore.kernel.org/all/20231218210341.30073-1-iiva...@suse.de/
[2] 
https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@mail.gmail.com/

Dmitry Malkin (2):
   rpi5: add initial memory map for bcm2712
   rpi5: Use devicetree as alternative way to read IO base addresses

Ivan T. Ivanov (4):
   rpi5: Use devicetree to retrieve board revision
   bcm2835: Dynamically calculate bytes per pixel parameter
   mmc: bcmstb: Add support for bcm2712 SD controller
   configs: rpi_arm64: enable SDHCI BCMSTB driver



In the meantime I was able to test this series. So here my:
Tested-by: Matthias Brugger 


  arch/arm/mach-bcm283x/include/mach/base.h  |   5 +-
  arch/arm/mach-bcm283x/include/mach/mbox.h  |   3 +-
  arch/arm/mach-bcm283x/include/mach/sdhci.h |   3 +-
  arch/arm/mach-bcm283x/include/mach/timer.h |   3 +-
  arch/arm/mach-bcm283x/include/mach/wdog.h  |   3 +-
  arch/arm/mach-bcm283x/init.c   |  74 -
  board/raspberrypi/rpi/rpi.c|  22 ++-
  configs/rpi_arm64_defconfig|   1 +
  drivers/mmc/bcmstb_sdhci.c | 173 -
  drivers/video/bcm2835.c|  18 ++-
  10 files changed, 282 insertions(+), 23 deletions(-)



Re: [PATCH 1/1] lib: support SMBIOS3 table in uuid_guid_get_str()

2024-01-22 Thread Mark Kettenis
> From: Heinrich Schuchardt 
> Date: Mon, 22 Jan 2024 14:04:35 +0100
> 
> As we support installing SMBIOS3 tables in U-Boot we need to add this GUID
> to the translation table used buy uuid_guid_get_str().
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Mark Kettenis 

> ---
>  lib/uuid.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/uuid.c b/lib/uuid.c
> index 0be22bc05f7..2d7d99535e7 100644
> --- a/lib/uuid.c
> +++ b/lib/uuid.c
> @@ -176,6 +176,10 @@ static const struct {
>   "SMBIOS table",
>   SMBIOS_TABLE_GUID,
>   },
> + {
> + "SMBIOS3 table",
> + SMBIOS3_TABLE_GUID,
> + },
>   {
>   "Runtime properties",
>   EFI_RT_PROPERTIES_TABLE_GUID,
> -- 
> 2.43.0
> 
> 


[PATCH 1/1] lib: support SMBIOS3 table in uuid_guid_get_str()

2024-01-22 Thread Heinrich Schuchardt
As we support installing SMBIOS3 tables in U-Boot we need to add this GUID
to the translation table used buy uuid_guid_get_str().

Signed-off-by: Heinrich Schuchardt 
---
 lib/uuid.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/uuid.c b/lib/uuid.c
index 0be22bc05f7..2d7d99535e7 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -176,6 +176,10 @@ static const struct {
"SMBIOS table",
SMBIOS_TABLE_GUID,
},
+   {
+   "SMBIOS3 table",
+   SMBIOS3_TABLE_GUID,
+   },
{
"Runtime properties",
EFI_RT_PROPERTIES_TABLE_GUID,
-- 
2.43.0



Pull request: Please pull u-boot-imx-20240115

2024-01-22 Thread Fabio Estevam
Hi Tom,

Please pull from u-boot-imx, thanks.

The following changes since commit 3c04fcf3137d5f694d52b8f355373e4baabe5f78:

  Merge patch series "k3-j721e: beagleboneai: Fix USB" (2024-01-20 11:39:13 
-0500)

are available in the Git repository at:

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

for you to fetch changes up to a80e0e7711a2b2890a583d88dcd9af978ddada32:

  ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM (2024-01-22 
08:40:02 -0300)

u-boot-imx-master-20240122
--

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

- Allow i.MX8M Plus DHCOM to operate in overdrive mode.
- Allow i.MX8M Plus eDM SBC to operate in overdrive mode.
- Enable the 'kaslrseed' command on DH i.MX8M Plus DHCOM.
- Select LTO by default on i.MX8M.
- Convert pico-dwarf/hobbit-imx6ul to CONFIG_DM_SERIAL.
- Fix 'reset' command on wandboard.


Fabio Estevam (3):
  imx8m: Enable LTO by default
  wandboard: Convert to watchdog driver model
  pico-dwarf/hobbit-imx6ul: Convert to CONFIG_DM_SERIAL

Marek Vasut (3):
  ARM: imx: Enable SPL_BOARD_INIT on DH i.MX8M Plus DHCOM
  ARM: imx: Configure GIC clock parent on Data Modul i.MX8M Plus eDM SBC
  ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM

 arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi  | 10 ++
 arch/arm/mach-imx/imx8m/Kconfig |  1 +
 board/data_modul/imx8mp_edm_sbc/spl.c   | 13 +
 configs/imx8mp_data_modul_edm_sbc_defconfig |  1 +
 configs/imx8mp_dhcom_pdk2_defconfig |  3 +++
 configs/imx8mp_dhcom_pdk3_defconfig |  3 +++
 configs/pico-dwarf-imx6ul_defconfig |  1 +
 configs/pico-hobbit-imx6ul_defconfig|  1 +
 configs/wandboard_defconfig |  3 +++
 9 files changed, 36 insertions(+)


Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM

2024-01-22 Thread Fabio Estevam
On Fri, Jan 19, 2024 at 9:36 PM Marek Vasut  wrote:
>
> Linux 6.6.y with KASLR enabled would print the following message on boot:
> "
> KASLR disabled due to lack of seed
> "
> Enable the 'kaslrseed' command so a random number seed can be pulled
> from CAAM and inserted into the /chosen node 'kaslr-seed' property of
> Linux kernel DT before boot, thus letting KASLR work properly.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.


Re: [PATCH] pico-dwarf/hobbit-imx6ul: Convert to CONFIG_DM_SERIAL

2024-01-22 Thread Fabio Estevam
On Fri, Jan 19, 2024 at 4:41 PM Fabio Estevam  wrote:
>
> The conversion to CONFIG_DM_SERIAL is mandatory, so select
> this option.
>
> Signed-off-by: Fabio Estevam 

Applied, thanks.


Re: [PATCH] wandboard: Convert to watchdog driver model

2024-01-22 Thread Fabio Estevam
On Fri, Jan 19, 2024 at 2:25 PM Fabio Estevam  wrote:
>
> Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
> the 'reset' command in U-Boot to not cause a board reset.
>
> Fix it by switching to the watchdog driver model via sysreset, which
> is the preferred method for implementing the watchdog reset.
>
> Signed-off-by: Fabio Estevam 

Applied, thanks.


Re: [PATCH v2] ARM: imx: Configure GIC clock parent on Data Modul i.MX8M Plus eDM SBC

2024-01-22 Thread Fabio Estevam
On Fri, Jan 19, 2024 at 1:09 PM Marek Vasut  wrote:
>
> The CONFIG_SPL_BOARD_INIT lets SPL common code call spl_board_init()
> during the SPL start up. On this particular system, spl_board_init()
> is used to reconfigure GIC clock parent to PLL2 500M, which is the
> configuration expected by the Linux kernel. Enable SPL_BOARD_INIT
> and fill in the GIC clock configuration code.
>
> Set GIC clock to 500 MHz for OD VDD_SOC. Kernel driver does not
> allow to change it. Should set the clock after PMIC setting done.
> Default is 400 MHz (system_pll1_800m with div = 2) set by ROM for
> ND VDD_SOC.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.


Re: [PATCH 1/2] imx8m: Enable LTO by default

2024-01-22 Thread Fabio Estevam
On Thu, Jan 18, 2024 at 12:06 PM Fabio Estevam  wrote:
>
> From: Fabio Estevam 
>
> In an attempt to select ARMV8_SPL_EXCEPTION_VECTORS, the SPL size
> could not fit into the internal SRAM of some imx8m targets:
>
>aarch64:  +   imx8mm_phg
> +aarch64-linux-ld.bfd: u-boot-spl section `__u_boot_list' will not fit in 
> region `.sram'
> +aarch64-linux-ld.bfd: region `.sram' overflowed by 1824 bytes
>
> Select LTO to prevent that.
>
> Signed-off-by: Fabio Estevam 

Applied only this one, thanks.


Re: [PATCH v2 2/2] tools: binman: ti_board_cfg: Check for linting problems

2024-01-22 Thread Max Krummenacher
Hi

On Fri, Jan 05, 2024 at 05:09:17PM +0530, Neha Malcom Francis wrote:
> Use yamllint for checking whether YAML configuration files are adhering
> to default yamllint rules.

If I understand this correctly this patch now runs checks to verify
that yaml files which are part of the U-Boot source tree are correct.

Shouldn't this be done when one commits a yaml file, i.e. in U-Boot CI
rather than repeating the process on every build and thus having an
additional dependency to build U-Boot and additional build time?

Note that in openembedded there is currently no python yamllint
recipe providing the used python module in the regularly used layers.
How do you plan to integrate the change in the OE U-Boot recipe?
At least our OE CI of latest master now fails (for a TI AM62 based SoM)
as the python module is missing.

Regards
Max

> 
> Signed-off-by: Neha Malcom Francis 
> Suggested-by: Nishanth Menon 
> ---
> Changes since v1:
>   - add yamllint to requirements.txt (Nishanth)
> 
>  tools/binman/etype/ti_board_config.py|  5 +
>  tools/binman/ftest.py|  6 ++
>  tools/binman/test/323_ti_board_cfg_phony.dts | 14 ++
>  tools/binman/test/yaml/config.yaml   |  4 ++--
>  tools/binman/test/yaml/config_phony.yaml | 18 ++
>  tools/buildman/requirements.txt  |  1 +
>  6 files changed, 46 insertions(+), 2 deletions(-)
>  create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts
>  create mode 100644 tools/binman/test/yaml/config_phony.yaml
> 
> diff --git a/tools/binman/etype/ti_board_config.py 
> b/tools/binman/etype/ti_board_config.py
> index 94f894c281..2c3bb8f7b5 100644
> --- a/tools/binman/etype/ti_board_config.py
> +++ b/tools/binman/etype/ti_board_config.py
> @@ -9,6 +9,7 @@
>  import os
>  import struct
>  import yaml
> +import yamllint
>  
>  from collections import OrderedDict
>  from jsonschema import validate
> @@ -18,6 +19,7 @@ from binman.entry import Entry
>  from binman.etype.section import Entry_section
>  from dtoc import fdt_util
>  from u_boot_pylib import tools
> +from yamllint import config
>  
>  BOARDCFG = 0xB
>  BOARDCFG_SEC = 0xD
> @@ -244,6 +246,9 @@ class Entry_ti_board_config(Entry_section):
>  with open(self._schema_file, 'r') as sch:
>  self.schema_yaml = yaml.safe_load(sch)
>  
> +yaml_config = config.YamlLintConfig("extends: default")
> +for p in yamllint.linter.run(open(self._config_file, "r"), 
> yaml_config):
> +self.Raise(f"Yamllint error: {p.line}: {p.rule}")
>  try:
>  validate(self.file_yaml, self.schema_yaml)
>  except Exception as e:
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index a4ac520cbb..1fbb0fef1a 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -7030,6 +7030,12 @@ fdt fdtmapExtract the 
> devicetree blob from the fdtmap
>  data = self._DoReadFile('293_ti_board_cfg.dts')
>  self.assertEqual(TI_BOARD_CONFIG_DATA, data)
>  
> +def testTIBoardConfigLint(self):
> +"""Test that an incorrectly linted config file would generate 
> error"""
> +with self.assertRaises(ValueError) as e:
> +data = self._DoReadFile('323_ti_board_cfg_phony.dts')
> +self.assertIn("Yamllint error", str(e.exception))
> +
>  def testTIBoardConfigCombined(self):
>  """Test that a schema validated combined board config file can be 
> generated"""
>  data = self._DoReadFile('294_ti_board_cfg_combined.dts')
> diff --git a/tools/binman/test/323_ti_board_cfg_phony.dts 
> b/tools/binman/test/323_ti_board_cfg_phony.dts
> new file mode 100644
> index 00..441296de4f
> --- /dev/null
> +++ b/tools/binman/test/323_ti_board_cfg_phony.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + ti-board-config {
> + config = "yaml/config_phony.yaml";
> + schema = "yaml/schema.yaml";
> + };
> + };
> +};
> diff --git a/tools/binman/test/yaml/config.yaml 
> b/tools/binman/test/yaml/config.yaml
> index 5f799a6e3a..c2be32128b 100644
> --- a/tools/binman/test/yaml/config.yaml
> +++ b/tools/binman/test/yaml/config.yaml
> @@ -10,9 +10,9 @@ main-branch:
>  b: 0
>arr: [0, 0, 0, 0]
>another-arr:
> -- #1
> +-  # 1
>c: 0
>d: 0
> -- #2
> +-  # 2
>c: 0
>d: 0
> diff --git a/tools/binman/test/yaml/config_phony.yaml 
> b/tools/binman/test/yaml/config_phony.yaml
> new file mode 100644
> index 00..d76fcb3b82
> --- /dev/null
> +++ b/tools/binman/test/yaml/config_phony.yaml
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Test config
> +#
> +---
> +
> +main-branch :
> +  obj :
> +a : 0x0
> +b: 0
> +  arr: [0, 0, 0, 0]
> +  a

Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM

2024-01-22 Thread Fabio Estevam
On Fri, Jan 19, 2024 at 9:36 PM Marek Vasut  wrote:
>
> Linux 6.6.y with KASLR enabled would print the following message on boot:
> "
> KASLR disabled due to lack of seed
> "
> Enable the 'kaslrseed' command so a random number seed can be pulled
> from CAAM and inserted into the /chosen node 'kaslr-seed' property of
> Linux kernel DT before boot, thus letting KASLR work properly.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.


Re: [PATCH v8 13/16] arm: dts: Introduce am69-sk u-boot dts files

2024-01-22 Thread Roger Quadros



On 19/01/2024 19:50, Apurva Nandan wrote:
> From: Dasnavis Sabiya 
> 
> Introduce the base dts files needed for u-boot or to augment the linux
> dtbs for use in the u-boot-spl and u-boot binaries.
> 
> Signed-off-by: Dasnavis Sabiya 
> Signed-off-by: Apurva Nandan 
> ---
>  arch/arm/dts/Makefile   |   1 +
>  arch/arm/dts/k3-am69-r5-sk.dts  | 105 
>  arch/arm/dts/k3-am69-sk-u-boot.dtsi |  48 +
>  board/ti/j784s4/MAINTAINERS |   2 +
>  4 files changed, 156 insertions(+)
>  create mode 100644 arch/arm/dts/k3-am69-r5-sk.dts
>  create mode 100644 arch/arm/dts/k3-am69-sk-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 876802b88e..1c5a6662f6 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1412,6 +1412,7 @@ dtb-$(CONFIG_SOC_K3_J721S2) += 
> k3-am68-sk-base-board.dtb\
>  k3-j721s2-r5-common-proc-board.dtb
>  
>  dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-sk.dtb \
> +k3-am69-r5-sk.dtb \
>  k3-j784s4-evm.dtb \
>  k3-j784s4-r5-evm.dtb
>  
> diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts
> new file mode 100644
> index 00..d2e73bd1bf
> --- /dev/null
> +++ b/arch/arm/dts/k3-am69-r5-sk.dts
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
> https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am69-sk.dts"
> +#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
> +#include "k3-j784s4-ddr.dtsi"
> +#include "k3-am69-sk-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + tick-timer = &mcu_timer0;
> + };
> +
> + aliases {
> + remoteproc0 = &sysctrler;
> + remoteproc1 = &a72_0;
> + };
> +
> + a72_0: a72@0 {
> + compatible = "ti,am654-rproc";
> + reg = <0x0 0x00a9 0x0 0x10>;
> + power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>,
> + <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>;
> + resets = <&k3_reset 202 0>;
> + clocks = <&k3_clks 61 0>;
> + assigned-clocks = <&k3_clks 61 0>, <&k3_clks 202 0>;
> + assigned-clock-parents = <&k3_clks 61 2>;
> + assigned-clock-rates = <2>, <20>;
> + ti,sci = <&sms>;
> + ti,sci-proc-id = <32>;
> + ti,sci-host-id = <10>;
> + bootph-pre-ram;
> + };
> +
> + dm_tifs: dm-tifs {
> + compatible = "ti,j721e-dm-sci";
> + ti,host-id = <3>;
> + ti,secure-host;
> + mbox-names = "rx", "tx";
> + mboxes= <&secure_proxy_mcu 21>, <&secure_proxy_mcu 23>;
> + bootph-pre-ram;
> + };
> +};
> +
> +&mcu_timer0 {
> + status = "okay";
> + clock-frequency = <25000>;
> + bootph-pre-ram;
> +};
> +
> +&secure_proxy_sa3 {
> + status = "okay";
> + bootph-pre-ram;
> +};
> +
> +&secure_proxy_mcu {
> + status = "okay";
> + bootph-pre-ram;
> +};
> +
> +&cbass_mcu_wakeup {
> + sysctrler: sysctrler {
> + compatible = "ti,am654-system-controller";
> + mboxes= <&secure_proxy_mcu 4>,
> + <&secure_proxy_mcu 5>,
> + <&secure_proxy_sa3 5>;
> + mbox-names = "tx", "rx", "boot_notify";
> + bootph-pre-ram;
> + };
> +};
> +
> +&sms {
> + mboxes= <&secure_proxy_mcu 8>, <&secure_proxy_mcu 6>, 
> <&secure_proxy_mcu 5>;
> + mbox-names = "tx", "rx", "notify";
> + ti,host-id = <4>;
> + ti,secure-host;
> + bootph-pre-ram;
> +};
> +
> +&wkup_uart0 {
> + bootph-pre-ram;
> + status = "okay";

In k3-am69-sk.dts this is marked as reserved. Why do you need to enable it here?
Maybe a comment would help readers.

> +};
> +
> +&ospi0 {
> + reg = <0x0 0x4704 0x0 0x100>,
> +   <0x0 0x5000 0x0 0x800>;
> +};
> +
> +&ospi1 {
> + reg = <0x0 0x4705 0x0 0x100>,
> +   <0x0 0x5800 0x0 0x800>;
> +};
> +
> +&mcu_ringacc {
> + ti,sci = <&dm_tifs>;
> +};
> +
> +&mcu_udmap {
> + ti,sci = <&dm_tifs>;
> +};
> diff --git a/arch/arm/dts/k3-am69-sk-u-boot.dtsi 
> b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> new file mode 100644
> index 00..4f8c99a1e6
> --- /dev/null
> +++ b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
> https://www.ti.com/
> + */
> +
> +#include "k3-j784s4-binman.dtsi"
> +
> +&mcu_udmap {
> + reg =   <0x0 0x285c 0x0 0x100>,
> + <0x0 0x284c 0x0 0x4000>,
> + <0x0 0x2a80 0x0 0x4>,
> + <0x0 0x284a 0x0 0x4000>,
> + <0x0 0x2aa0 0x0 0x4>,
> + <0x0 0x2840 0x0 0x2000>;
> + reg-names = "g

Re: [PATCH v8 08/16] drivers: dma: Add support for J784S4 SoC

2024-01-22 Thread Roger Quadros



On 19/01/2024 19:50, Apurva Nandan wrote:
> Add support for DMA in J784S4 SoC.
> 
> Signed-off-by: Jayesh Choudhary 
> Signed-off-by: Hari Nagalla 
> Signed-off-by: Apurva Nandan 
> Reviewed-by: Nishanth Menon 
> ---
>  drivers/dma/ti/Makefile   |   1 +
>  drivers/dma/ti/k3-psil-j784s4.c   | 166 ++
>  drivers/dma/ti/k3-psil-priv.h |   1 +
>  drivers/dma/ti/k3-psil.c  |   2 +
>  drivers/firmware/ti_sci_static_data.h |  34 ++
>  drivers/ram/Kconfig   |   2 +-
>  6 files changed, 205 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/dma/ti/k3-psil-j784s4.c
> 
> diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
> index f4e0271efb..9e0b13e8c0 100644
> --- a/drivers/dma/ti/Makefile
> +++ b/drivers/dma/ti/Makefile
> @@ -9,3 +9,4 @@ k3-psil-data-$(CONFIG_SOC_K3_J721S2) += k3-psil-j721s2.o
>  k3-psil-data-$(CONFIG_SOC_K3_AM642) += k3-psil-am64.o
>  k3-psil-data-$(CONFIG_SOC_K3_AM625) += k3-psil-am62.o
>  k3-psil-data-$(CONFIG_SOC_K3_AM62A7) += k3-psil-am62a.o
> +k3-psil-data-$(CONFIG_SOC_K3_J784S4) += k3-psil-j784s4.o
> diff --git a/drivers/dma/ti/k3-psil-j784s4.c b/drivers/dma/ti/k3-psil-j784s4.c
> new file mode 100644
> index 00..7f06a1f307
> --- /dev/null
> +++ b/drivers/dma/ti/k3-psil-j784s4.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + *  Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com
> + */
> +#include 
> +
> +#include "k3-psil-priv.h"
> +
> +#define PSIL_PDMA_XY_TR(x)   \
> + {   \
> + .thread_id = x, \
> + .ep_config = {  \
> + .ep_type = PSIL_EP_PDMA_XY, \
> + },  \
> + }
> +
> +#define PSIL_PDMA_XY_PKT(x)  \
> + {   \
> + .thread_id = x, \
> + .ep_config = {  \
> + .ep_type = PSIL_EP_PDMA_XY, \
> + .pkt_mode = 1,  \
> + },  \
> + }
> +
> +#define PSIL_PDMA_MCASP(x)   \
> + {   \
> + .thread_id = x, \
> + .ep_config = {  \
> + .ep_type = PSIL_EP_PDMA_XY, \
> + .pdma_acc32 = 1,\
> + .pdma_burst = 1,\
> + },  \
> + }
> +
> +#define PSIL_ETHERNET(x) \
> + {   \
> + .thread_id = x, \
> + .ep_config = {  \
> + .ep_type = PSIL_EP_NATIVE,  \
> + .pkt_mode = 1,  \
> + .needs_epib = 1,\
> + .psd_size = 16, \
> + },  \
> + }
> +
> +#define PSIL_SA2UL(x, tx)\
> + {   \
> + .thread_id = x, \
> + .ep_config = {  \
> + .ep_type = PSIL_EP_NATIVE,  \
> + .pkt_mode = 1,  \
> + .needs_epib = 1,\
> + .psd_size = 64, \
> + .notdpkt = tx,  \
> + },  \
> + }
> +
> +/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
> +static struct psil_ep j784s4_src_ep_map[] = {
> + /* PDMA_MCASP - McASP0-4 */
> + PSIL_PDMA_MCASP(0x4400),
> + PSIL_PDMA_MCASP(0x4401),
> + PSIL_PDMA_MCASP(0x4402),
> + PSIL_PDMA_MCASP(0x4403),
> + PSIL_PDMA_MCASP(0x4404),
> + /* PDMA_SPI_G0 - SPI0-3 */
> + PSIL_PDMA_XY_PKT(0x4600),
> + PSIL_PDMA_XY_PKT(0x4601),
> + PSIL_PDMA_XY_PKT(0x4602),
> + PSIL_PDMA_XY_PKT(0x4603),
> + PSIL_PDMA_XY_PKT(0x4604),
> + PSIL_PDMA_XY_PKT(0x4605),
> + PSIL_PDMA_XY_PKT(0x4606),
> + PSIL_PDMA_XY_PKT(0x4607),
> + PSIL_PDMA_XY_PKT(0x4608),
> + PSIL_PDMA_XY_PKT(0x4609),
> + PSIL_PDMA_XY_PKT(0x460a),
> + PSIL_PDMA_XY_PKT(0x460b),
> + PSIL_PDMA_XY_PKT(0x460c),
> + PSIL_PDMA_XY_PKT(0x460d),
> + PSIL_PDMA_XY_PKT(0x460e),
> + PSIL_PDMA_XY_PKT(0x460f),
> + /* PDMA_SPI_G1 - SPI4-7 */
> + PSIL_PDMA_XY_PKT(0x4610),
> + PSIL_PDMA_XY_PKT(0x4611),
> + PSIL_PDMA_XY_PKT(0x4612),
> + PSIL_PDMA_XY_PKT(0x4613),
> + PSIL_PDM

[PATCH 5/5] rockchip: rv1126: Move RAM disk address

2024-01-22 Thread Tim Lunn
OPTEE gets loaded into a memory region overlapping with the ram disk.

Fix the ramdisk address so it doesn't overlap with the OPTEE memory
region.

Signed-off-by: Tim Lunn 

---

 include/configs/rv1126_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/rv1126_common.h b/include/configs/rv1126_common.h
index a64c0c6364..6961dbe20b 100644
--- a/include/configs/rv1126_common.h
+++ b/include/configs/rv1126_common.h
@@ -26,7 +26,7 @@
"fdt_addr_r=0x0830\0" \
"fdtoverlay_addr_r=0x0200\0" \
"kernel_addr_r=0x02008000\0" \
-   "ramdisk_addr_r=0x0a20\0"
+   "ramdisk_addr_r=0x0a40\0"
 
 #include 
 #define CFG_EXTRA_ENV_SETTINGS \
-- 
2.40.1



[PATCH 4/5] rockchip: rv1126: select SPL_OPTEE_IMAGE

2024-01-22 Thread Tim Lunn
rv1126 requires OPTEE as it provides pcsi support. Mainline Linux
kernel will fail to boot without this.

Select SPL_OPTEE_IMAGE when building FIT image. TEE must be provided
when building.

Signed-off-by: Tim Lunn 
---

 arch/arm/mach-rockchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 6ff0aa6911..cce118a004 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -359,6 +359,7 @@ config ROCKCHIP_RV1126
select PMIC_RK8XX
select BOARD_LATE_INIT
imply ROCKCHIP_COMMON_BOARD
+   select SPL_OPTEE_IMAGE if SPL_FIT
imply OF_LIBFDT_OVERLAY
imply ROCKCHIP_OTP
imply MISC_INIT_R
-- 
2.40.1



[PATCH 3/5] board: rockchip: Add Sonoff iHost board

2024-01-22 Thread Tim Lunn
Sonoff iHost is gateway device designed to provide a Smart Home Hub,
it is based on Rockchip RV1126. There is also a version with 2GB RAM
based off the RV1109 dual core SoC however this works with the same
config as the RV1126 for uboot purposes.

Features:
- Rockchip RV1126
- 4GB DDR4
- 8GB eMMC
- microSD slot
- RMII Ethernet PHY
- 1x USB 2.0 Host
- 1x USB 2.0 OTG
- Realtek RTL8723DS WiFi/BT
- EFR32MG21 Silabs Zigbee radio
- Speaker/Microphone

Signed-off-by: Tim Lunn 
---

 arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi | 13 +
 arch/arm/mach-rockchip/rv1126/Kconfig|  8 +++
 board/itead/sonoff-ihost/Kconfig | 16 ++
 board/itead/sonoff-ihost/MAINTAINERS |  6 ++
 configs/sonoff-ihost-rv1126_defconfig| 60 
 include/configs/sonoff-ihost.h   | 18 ++
 6 files changed, 121 insertions(+)
 create mode 100644 arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi
 create mode 100644 board/itead/sonoff-ihost/Kconfig
 create mode 100644 board/itead/sonoff-ihost/MAINTAINERS
 create mode 100644 configs/sonoff-ihost-rv1126_defconfig
 create mode 100644 include/configs/sonoff-ihost.h

diff --git a/arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi 
b/arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi
new file mode 100644
index 00..a625660d58
--- /dev/null
+++ b/arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rv1126-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", &sdmmc, &emmc;
+   };
+};
+
+&sdio {
+   status = "disabled";
+};
diff --git a/arch/arm/mach-rockchip/rv1126/Kconfig 
b/arch/arm/mach-rockchip/rv1126/Kconfig
index a6e2b5903c..55b1112120 100644
--- a/arch/arm/mach-rockchip/rv1126/Kconfig
+++ b/arch/arm/mach-rockchip/rv1126/Kconfig
@@ -14,6 +14,13 @@ config TARGET_RV1126_NEU2
  IO board and Neu2 needs to mount on top of this IO board in order to
  create complete Edgeble Neural Compute Module 2(Neu2) IO platform.
 
+config TARGET_RV1126_SONOFF_IHOST
+   bool "Sonoff iHost smart home hub"
+   help
+ Sonoff iHost is a smart home gateway based on Rockchip RV1126 SoC.
+ It features Wifi, Bluetooth and Zigbee radios that are used by many
+ smart home devices.
+
 config SOC_SPECIFIC_OPTIONS # dummy
def_bool y
select HAS_CUSTOM_SYS_INIT_SP_ADDR
@@ -58,5 +65,6 @@ config TEXT_BASE
default 0x60
 
 source board/edgeble/neural-compute-module-2/Kconfig
+source board/itead/sonoff-ihost/Kconfig
 
 endif
diff --git a/board/itead/sonoff-ihost/Kconfig b/board/itead/sonoff-ihost/Kconfig
new file mode 100644
index 00..30d9a6b3e6
--- /dev/null
+++ b/board/itead/sonoff-ihost/Kconfig
@@ -0,0 +1,16 @@
+if TARGET_RV1126_SONOFF_IHOST
+
+config SYS_BOARD
+   default "sonoff-ihost"
+
+config SYS_VENDOR
+   default "itead"
+
+config SYS_CONFIG_NAME
+   default "sonoff-ihost"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+   select RAM_ROCKCHIP_DDR4
+
+endif
diff --git a/board/itead/sonoff-ihost/MAINTAINERS 
b/board/itead/sonoff-ihost/MAINTAINERS
new file mode 100644
index 00..eff9274bea
--- /dev/null
+++ b/board/itead/sonoff-ihost/MAINTAINERS
@@ -0,0 +1,6 @@
+RV1126-SONOFF-IHOST
+M: Tim Lunn 
+S: Maintained
+F: board/itead/sonoff-ihost
+F: include/configs/sonoff-ihost.h
+F: configs/sonoff-ihost-rv1126_defconfig
diff --git a/configs/sonoff-ihost-rv1126_defconfig 
b/configs/sonoff-ihost-rv1126_defconfig
new file mode 100644
index 00..fe99bd92f9
--- /dev/null
+++ b/configs/sonoff-ihost-rv1126_defconfig
@@ -0,0 +1,60 @@
+CONFIG_ARM=y
+CONFIG_SPL_SKIP_LOWLEVEL_INIT_ONLY=y
+CONFIG_TPL_SKIP_LOWLEVEL_INIT_ONLY=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_SYS_ARCH_TIMER=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_DEVICE_TREE="rv1126-sonoff-ihost"
+CONFIG_SYS_MONITOR_LEN=614400
+CONFIG_ROCKCHIP_RV1126=y
+CONFIG_TARGET_RV1126_SONOFF_IHOST=y
+CONFIG_DEBUG_UART_BASE=0xff57
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SYS_LOAD_ADDR=0xe00800
+CONFIG_DEBUG_UART=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
+CONFIG_SYS_BOOTM_LEN=0x400
+CONFIG_DEFAULT_FDT_FILE="rv1126-sonoff-ihost.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_PAD_TO=0x7f8000
+CONFIG_SPL_NO_BSS_LIMIT=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+CONFIG_CMD_GPT=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_ISO_PARTITION is not set
+CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64
+CONFIG_OF_SPL_REMOVE_PROPS="cloc

[PATCH 2/5] ram: rockchip: Add rv1126 ddr4 support

2024-01-22 Thread Tim Lunn
Add support for ddr4 on rv1126. Timing detection files are imported
from downstream Rockchip BSP u-boot. Allow selecting ddr4 ram with
define CONFIG_RAM_ROCKCHIP_DDR4.

Signed-off-by: Tim Lunn 
---

 .../sdram-rv1126-ddr4-detect-1056.inc | 75 +++
 .../rockchip/sdram-rv1126-ddr4-detect-328.inc | 75 +++
 .../rockchip/sdram-rv1126-ddr4-detect-396.inc | 75 +++
 .../rockchip/sdram-rv1126-ddr4-detect-528.inc | 75 +++
 .../rockchip/sdram-rv1126-ddr4-detect-664.inc | 75 +++
 .../rockchip/sdram-rv1126-ddr4-detect-784.inc | 75 +++
 .../rockchip/sdram-rv1126-ddr4-detect-924.inc | 75 +++
 drivers/ram/rockchip/sdram_rv1126.c   |  8 ++
 8 files changed, 533 insertions(+)
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-1056.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-328.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-396.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-528.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-664.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-784.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-924.inc

diff --git a/drivers/ram/rockchip/sdram-rv1126-ddr4-detect-1056.inc 
b/drivers/ram/rockchip/sdram-rv1126-ddr4-detect-1056.inc
new file mode 100644
index 00..295b0871e0
--- /dev/null
+++ b/drivers/ram/rockchip/sdram-rv1126-ddr4-detect-1056.inc
@@ -0,0 +1,75 @@
+{
+   {
+   {
+   .rank = 0x1,
+   .col = 0xA,
+   .bk = 0x2,
+   .bw = 0x1,
+   .dbw = 0x0,
+   .row_3_4 = 0x0,
+   .cs0_row = 0x11,
+   .cs1_row = 0x0,
+   .cs0_high16bit_row = 0x11,
+   .cs1_high16bit_row = 0x0,
+   .ddrconfig = 0
+   },
+   {
+   {0x561d1219},
+   {0x10030703},
+   {0x0002},
+   {0x},
+   {0x000c},
+   {0x034b},
+   0x00ff
+   }
+   },
+   {
+   .ddr_freq = 1056,   /* clock rate(MHz) */
+   .dramtype = DDR4,
+   .num_channels = 1,
+   .stride = 0,
+   .odt = 1
+   },
+   {
+   {
+   {0x, 0x43041010},   /* MSTR */
+   {0x0064, 0x008000b9},   /* RFSHTMG */
+   {0x00d0, 0x00020103},   /* INIT0 */
+   {0x00d4, 0x0069},   /* INIT1 */
+   {0x00d8, 0x0100},   /* INIT2 */
+   {0x00dc, 0x07340401},   /* INIT3 */
+   {0x00e0, 0x0010},   /* INIT4 */
+   {0x00e4, 0x0011},   /* INIT5 */
+   {0x00e8, 0x0420},   /* INIT6 */
+   {0x00ec, 0x0800},   /* INIT7 */
+   {0x00f4, 0x000f011f},   /* RANKCTL */
+   {0x0100, 0x0f102411},   /* DRAMTMG0 */
+   {0x0104, 0x0004041a},   /* DRAMTMG1 */
+   {0x0108, 0x0608060d},   /* DRAMTMG2 */
+   {0x010c, 0x0040400c},   /* DRAMTMG3 */
+   {0x0110, 0x08030409},   /* DRAMTMG4 */
+   {0x0114, 0x06060403},   /* DRAMTMG5 */
+   {0x0120, 0x07070d07},   /* DRAMTMG8 */
+   {0x0124, 0x00020309},   /* DRAMTMG9 */
+   {0x0180, 0x0140},   /* ZQCTL0 */
+   {0x0184, 0x},   /* ZQCTL1 */
+   {0x0190, 0x07060004},   /* DFITMG0 */
+   {0x0198, 0x07000101},   /* DFILPCFG0 */
+   {0x01a0, 0xc043},   /* DFIUPD0 */
+   {0x0240, 0x06000614},   /* ODTCFG */
+   {0x0244, 0x0201},   /* ODTMAP */
+   {0x0250, 0x1f00},   /* SCHED */
+   {0x0490, 0x0001},   /* PCTRL_0 */
+   {0x, 0x}
+   }
+   },
+   {
+   {
+   {0x0004, 0x008c},   /* PHYREG01 */
+   {0x0014, 0x0010},   /* PHYREG05 */
+   {0x0018, 0x},   /* PHYREG06 */
+   {0x001c, 0x000b},   /* PHYREG07 */
+   {0x, 0x}

[PATCH 1/5] arm: dts: rockchip: Sync rv1126 dts from linux 6.8-rc1

2024-01-22 Thread Tim Lunn
Sync linux dts files for rv1126 boards from linux v6.8-rc1 tag. Includes
the newly added dts for Sonoff iHost.

Signed-off-by: Tim Lunn 
---

 arch/arm/dts/rv1126-edgeble-neu2-io.dts |  70 
 arch/arm/dts/rv1126-edgeble-neu2.dtsi   |  27 +-
 arch/arm/dts/rv1126-pinctrl.dtsi| 130 
 arch/arm/dts/rv1126-sonoff-ihost.dts|  29 ++
 arch/arm/dts/rv1126-sonoff-ihost.dtsi   | 404 
 arch/arm/dts/rv1126.dtsi| 185 +++
 6 files changed, 835 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/dts/rv1126-sonoff-ihost.dts
 create mode 100644 arch/arm/dts/rv1126-sonoff-ihost.dtsi

diff --git a/arch/arm/dts/rv1126-edgeble-neu2-io.dts 
b/arch/arm/dts/rv1126-edgeble-neu2-io.dts
index dded0a12f0..0c2396b8f8 100644
--- a/arch/arm/dts/rv1126-edgeble-neu2-io.dts
+++ b/arch/arm/dts/rv1126-edgeble-neu2-io.dts
@@ -20,6 +20,76 @@
chosen {
stdout-path = "serial2:150n8";
};
+
+   vcc12v_dcin: vcc12v-dcin-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc12v_dcin";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <&vcc12v_dcin>;
+   };
+
+   v3v3_sys: v3v3-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "v3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+};
+
+&gmac {
+   assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
+ <&cru CLK_GMAC_ETHERNET_OUT>;
+   assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>, <&cru RGMII_MODE_CLK>;
+   assigned-clock-rates = <12500>, <0>, <2500>;
+   clock_in_out = "input";
+   phy-handle = <&phy>;
+   phy-mode = "rgmii";
+   phy-supply = <&vcc_3v3>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4 
&clk_out_ethernetm1_pins>;
+   tx_delay = <0x2a>;
+   rx_delay = <0x1a>;
+   status = "okay";
+};
+
+&mdio {
+   phy: ethernet-phy@0 {
+   compatible = "ethernet-phy-id001c.c916",
+"ethernet-phy-ieee802.3-c22";
+   reg = <0x0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <ð_phy_rst>;
+   reset-assert-us = <2>;
+   reset-deassert-us = <10>;
+   reset-gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_LOW>;
+   };
+};
+
+&pinctrl {
+   ethernet {
+   eth_phy_rst: eth-phy-rst {
+   rockchip,pins = <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+   };
+   };
+};
+
+&pwm11 {
+   status = "okay";
 };
 
 &sdmmc {
diff --git a/arch/arm/dts/rv1126-edgeble-neu2.dtsi 
b/arch/arm/dts/rv1126-edgeble-neu2.dtsi
index cc64ba4be3..7ea8d7d16f 100644
--- a/arch/arm/dts/rv1126-edgeble-neu2.dtsi
+++ b/arch/arm/dts/rv1126-edgeble-neu2.dtsi
@@ -11,15 +11,6 @@
mmc0 = &emmc;
};
 
-   vcc5v0_sys: vcc5v0-sys-regulator {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc5v0_sys";
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vccio_flash: vccio-flash-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -52,7 +43,7 @@
bus-width = <8>;
non-removable;
pinctrl-names = "default";
-   pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_rstnout>;
+   pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk>;
rockchip,default-sample-phase = <90>;
vmmc-supply = <&vcc_3v3>;
vqmmc-supply = <&vccio_flash>;
@@ -301,6 +292,22 @@
status = "okay";
 };
 
+&sfc {
+   pinctrl-names = "default";
+   pinctrl-0 = <&fspi_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+   spi-rx-bus-width = <4>;
+   spi-tx-bus-width = <1>;
+   };
+};
+
 &sdio {
bus-width = <4>;
cap-sd-highspeed;
diff --git a/arch/arm/dts/rv1126-pinctrl.dtsi b/arch/arm/dts/rv1126-pin

[PATCH 0/5] rockchip: Add support for rv1126 based Sonoff iHost Gateway

2024-01-22 Thread Tim Lunn


Sonoff iHost is gateway device designed to provide a Smart Home Hub,
it is based on Rockchip RV1126. It features Wifi, BT and Zigbee radios
as required by many smart home devices.

Features:
- Rockchip RV1126
- 4GB DDR4
- 8GB eMMC
- microSD slot
- RMII Ethernet PHY
- 1x USB 2.0 Host
- 1x USB 2.0 OTG
- Realtek RTL8723DS WiFi/BT
- EFR32MG21 Silabs Zigbee radio
- Speaker/Microphone

Sync rv1126 dts from linux v6.8-rc1, add support for ddr4 ram and add
board support for the Sonoff ihost.


Tim Lunn (5):
  arm: dts: rockchip: Sync rv1126 dts from linux 6.8-rc1
  ram: rockchip: Add rv1126 ddr4 support
  board: rockchip: Add Sonoff iHost board
  rockchip: rv1126: select SPL_OPTEE_IMAGE
  rockchip: rv1126: Move RAM disk address

 arch/arm/dts/rv1126-edgeble-neu2-io.dts   |  70 +++
 arch/arm/dts/rv1126-edgeble-neu2.dtsi |  27 +-
 arch/arm/dts/rv1126-pinctrl.dtsi  | 130 ++
 arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi  |  13 +
 arch/arm/dts/rv1126-sonoff-ihost.dts  |  29 ++
 arch/arm/dts/rv1126-sonoff-ihost.dtsi | 404 ++
 arch/arm/dts/rv1126.dtsi  | 185 
 arch/arm/mach-rockchip/Kconfig|   1 +
 arch/arm/mach-rockchip/rv1126/Kconfig |   8 +
 board/itead/sonoff-ihost/Kconfig  |  16 +
 board/itead/sonoff-ihost/MAINTAINERS  |   6 +
 configs/sonoff-ihost-rv1126_defconfig |  60 +++
 .../sdram-rv1126-ddr4-detect-1056.inc |  75 
 .../rockchip/sdram-rv1126-ddr4-detect-328.inc |  75 
 .../rockchip/sdram-rv1126-ddr4-detect-396.inc |  75 
 .../rockchip/sdram-rv1126-ddr4-detect-528.inc |  75 
 .../rockchip/sdram-rv1126-ddr4-detect-664.inc |  75 
 .../rockchip/sdram-rv1126-ddr4-detect-784.inc |  75 
 .../rockchip/sdram-rv1126-ddr4-detect-924.inc |  75 
 drivers/ram/rockchip/sdram_rv1126.c   |   8 +
 include/configs/rv1126_common.h   |   2 +-
 include/configs/sonoff-ihost.h|  18 +
 22 files changed, 1491 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/dts/rv1126-sonoff-ihost-u-boot.dtsi
 create mode 100644 arch/arm/dts/rv1126-sonoff-ihost.dts
 create mode 100644 arch/arm/dts/rv1126-sonoff-ihost.dtsi
 create mode 100644 board/itead/sonoff-ihost/Kconfig
 create mode 100644 board/itead/sonoff-ihost/MAINTAINERS
 create mode 100644 configs/sonoff-ihost-rv1126_defconfig
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-1056.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-328.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-396.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-528.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-664.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-784.inc
 create mode 100644 drivers/ram/rockchip/sdram-rv1126-ddr4-detect-924.inc
 create mode 100644 include/configs/sonoff-ihost.h

-- 
2.40.1



Re: [PATCH v8 07/16] arm: mach-k3: j784s4: Add clk and power support

2024-01-22 Thread Roger Quadros



On 19/01/2024 19:50, Apurva Nandan wrote:
> Add clk and device data which can be used by respective drivers
> to configure clocks and PSC.
> 
> Signed-off-by: Hari Nagalla 
> Signed-off-by: Apurva Nandan 
> Reviewed-by: Sean Anderson 
> Reviewed-by: Nishanth Menon 
> Reviewed-by: Bryan Brattlof 

Reviewed-by: Roger Quadros 


Re: [PATCH v8 06/16] soc: ti: k3-socinfo: Add entry for J784S4 SoC

2024-01-22 Thread Roger Quadros



On 19/01/2024 19:50, Apurva Nandan wrote:
> Add support for J784S4 SoC Identification.
> 
> Signed-off-by: Hari Nagalla 
> Signed-off-by: Apurva Nandan 
> Reviewed-by: Nishanth Menon 

Reviewed-by: Roger Quadros 


Re: [PATCH v8 05/16] arm: mach-k3: Sort SoC JTAG_ID entries

2024-01-22 Thread Roger Quadros



On 19/01/2024 19:50, Apurva Nandan wrote:
> Sort JTAG_IDs for K3 SoCs in hardware.h in alphabetical order.
> 
> Signed-off-by: Apurva Nandan 
> Reviewed-by: Nishanth Menon 

Reviewed-by: Roger Quadros 


Re: [PATCH v8 01/16] arm: mach-k3: Kconfig: Sort SOC_K3 config entries

2024-01-22 Thread Roger Quadros



On 19/01/2024 19:50, Apurva Nandan wrote:
> Sort SOC_K3 config entries in alphabetical order
> for clean up.
> 
> Signed-off-by: Apurva Nandan 

Reviewed-by: Roger Quadros 


Re: [PATCH 07/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS

2024-01-22 Thread Chintan Vankar



On 12/01/24 18:00, Nishanth Menon wrote:

On 12:17-20240112, Siddharth Vadapalli wrote:

From: Kishon Vijay Abraham I 

In order to support Ethernet boot on AM62x, probe AM65 CPSW NUSS driver
in board_init_f().

Why? doesn't the DM framework handle this?

Can you suggest how can we do this ?



Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
  arch/arm/mach-k3/am625_init.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 6c96e88114..b89dd206e5 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -209,6 +209,16 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM init failed: %d\n", ret);
}
+
+   if (IS_ENABLED(CONFIG_SPL_ETH) && IS_ENABLED(CONFIG_TI_AM65_CPSW_NUSS) 
&&
+   spl_boot_device() == BOOT_DEVICE_ETHERNET) {
+   struct udevice *cpswdev;
+
+   if (uclass_get_device_by_driver(UCLASS_MISC, 
DM_DRIVER_GET(am65_cpsw_nuss),
+   &cpswdev))
+   printf("Failed to probe am65_cpsw_nuss driver\n");
+   }
+




Re: [PATCH u-boot v2019.04-aspeed-openbmc] ARM: dts: aspeed: Add Ampere's BMC platform (AST2600)

2024-01-22 Thread Chanh Nguyen

Dear all,

I'm looking forward to seeing your feedback on my patch. Please share 
your comments with me!


Thank you very much,
Chanh Ng

On 04/01/2024 11:19, Chanh Nguyen wrote:

Dear maintainers,

Just a gentle ping on the patch.
I’m eagerly awaiting your response. Please share with me your comments 
if you need to update anything.


Best Regards,
Chanh Nguyen

On 10/12/2023 11:25, Chanh Nguyen wrote:

Add the initial version of the device tree for the Ampere BMC
platform, which is equipped with the Aspeed AST2600 BMC SoC.

Signed-off-by: Chanh Nguyen 
---
  arch/arm/dts/Makefile   |   1 +
  arch/arm/dts/ast2600-ampere.dts | 113 
  2 files changed, 114 insertions(+)
  create mode 100644 arch/arm/dts/ast2600-ampere.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 37675a3277..3642d59c89 100755
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -691,6 +691,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
  ast2600-greatlakes.dtb \
  ast2600-intel.dtb \
  ast2600-ncsi.dtb \
+    ast2600-ampere.dtb \
  ast2600-p10bmc.dtb \
  ast2600-pfr.dtb \
  ast2600-qcom-dc-scm-v1.dtb \
diff --git a/arch/arm/dts/ast2600-ampere.dts 
b/arch/arm/dts/ast2600-ampere.dts

new file mode 100644
index 00..63088703a7
--- /dev/null
+++ b/arch/arm/dts/ast2600-ampere.dts
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2022, Ampere Computing LLC
+/dts-v1/;
+
+#include "ast2600-u-boot.dtsi"
+
+/ {
+    model = "AST2600 Ampere BMC";
+    compatible = "aspeed,ast2600-ampere", "aspeed,ast2600";
+
+    memory {
+    device_type = "memory";
+    reg = <0x8000 0x4000>;
+    };
+
+    chosen {
+    stdout-path = &uart5;
+    };
+
+    aliases {
+    spi0 = &fmc;
+    ethernet0 = &mac0;
+    };
+
+    cpus {
+    cpu@0 {
+    clock-frequency = <8>;
+    };
+    cpu@1 {
+    clock-frequency = <8>;
+    };
+    };
+};
+
+&uart5 {
+    u-boot,dm-pre-reloc;
+    status = "okay";
+};
+
+&sdrammc {
+    clock-frequency = <4>;
+};
+
+&wdt1 {
+    status = "okay";
+};
+
+&wdt2 {
+    status = "okay";
+};
+
+&wdt3 {
+    status = "okay";
+};
+
+&mdio {
+    status = "okay";
+    pinctrl-names = "default";
+    pinctrl-0 = <&pinctrl_mdio1_default>;
+
+};
+
+&mac0 {
+    status = "okay";
+    phy-mode = "rgmii-rxid";
+    pinctrl-names = "default";
+    pinctrl-0 = <&pinctrl_rgmii1_default>;
+};
+
+&fmc {
+    status = "okay";
+
+    pinctrl-names = "default";
+    pinctrl-0 = <&pinctrl_fmcquad_default>;
+
+    flash@0 {
+    status = "okay";
+    spi-max-frequency = <5000>;
+    spi-tx-bus-width = <4>;
+    spi-rx-bus-width = <4>;
+    };
+
+    flash@1 {
+    status = "okay";
+    spi-max-frequency = <5000>;
+    spi-tx-bus-width = <4>;
+    spi-rx-bus-width = <4>;
+    };
+};
+
+&scu {
+    mac0-clk-delay = <0x10 0x0a
+  0x10 0x10
+  0x10 0x10>;
+};
+
+&hace {
+    u-boot,dm-pre-reloc;
+    status = "okay";
+};
+
+&acry {
+    u-boot,dm-pre-reloc;
+    status = "okay";
+};
+
+&i2c4 {
+    status = "okay";
+};
+
+&i2c14 {
+    status = "okay";
+};


Re: [PATCH v4 0/6] rpi5: initial support

2024-01-22 Thread Ivan T. Ivanov
Hi,

> On 20 Jan 2024, at 12:50, Stefan Wahren  wrote:
> 
> Hi,
> 
> Am 20.01.24 um 10:48 schrieb Jens Maus:
>> Hi,
>> 
>>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren :
>>> 
>>> Am 19.01.24 um 22:26 schrieb Jens Maus:
 I actually do have some good and bad news:
 
 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB 
 both on the HDMI and on the serial debug UART like you reported.
 
 2. Bad news: I actually got it working by downgrading the rpi-eeprom to 
 the same 2023/10/30 (VERSION:30de0ba5) version like you have.
 
> 
> One idea would be to enable early debug in U-Boot (no idea how to
> achieve this). I assume U-Boot crashes before it's able to print the
> first line, but it's hard to believe it crashes at the very first
> instruction of U-Boot. So with some luck we should be able to narrow
> done the cause.

I was able to enable early debug UART in U-Boot and I will try to
find what is happening, once I get some free cycles.

Regards,
Ivan

[PATCH 18/18] doc: fwu: Make changes for supporting FWU Metadata version 2

2024-01-22 Thread Sughosh Ganu
Make changes to the FWU documentation to reflect the changes made with
migration of the FWU metadata to version 2.

Signed-off-by: Sughosh Ganu 
---
 doc/board/socionext/developerbox.rst |  9 +++--
 doc/develop/uefi/fwu_updates.rst | 12 +---
 doc/usage/cmd/fwu_mdata.rst  | 12 
 3 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/doc/board/socionext/developerbox.rst 
b/doc/board/socionext/developerbox.rst
index 46712c379b..d8c1bb4986 100644
--- a/doc/board/socionext/developerbox.rst
+++ b/doc/board/socionext/developerbox.rst
@@ -113,8 +113,6 @@ configs/synquacer_developerbox_defconfig enables default 
FWU configuration ::
  CONFIG_FWU_MULTI_BANK_UPDATE=y
  CONFIG_FWU_MDATA=y
  CONFIG_FWU_MDATA_MTD=y
- CONFIG_FWU_NUM_BANKS=2
- CONFIG_FWU_NUM_IMAGES_PER_BANK=1
  CONFIG_CMD_FWU_METADATA=y
 
 And build it::
@@ -126,10 +124,9 @@ And build it::
   make -j `noproc`
   cd ../
 
-By default, the CONFIG_FWU_NUM_BANKS and CONFIG_FWU_NUM_IMAGES_PER_BANKS are
-set to 2 and 1 respectively. This uses FIP (Firmware Image Package) type image
-which contains TF-A, U-Boot and OP-TEE (the OP-TEE is optional).
-You can use fiptool to compose the FIP image from those firmware images.
+This uses FIP (Firmware Image Package) type image which contains TF-A,
+U-Boot and OP-TEE (the OP-TEE is optional). You can use fiptool to
+compose the FIP image from those firmware images.
 
 Rebuild SCP firmware
 
diff --git a/doc/develop/uefi/fwu_updates.rst b/doc/develop/uefi/fwu_updates.rst
index e4709d82b4..7911c954d9 100644
--- a/doc/develop/uefi/fwu_updates.rst
+++ b/doc/develop/uefi/fwu_updates.rst
@@ -43,8 +43,6 @@ The feature can be enabled by specifying the following 
configs::
 CONFIG_FWU_MULTI_BANK_UPDATE=y
 CONFIG_FWU_MDATA=y
 CONFIG_FWU_MDATA_GPT_BLK=y
-CONFIG_FWU_NUM_BANKS=
-CONFIG_FWU_NUM_IMAGES_PER_BANK=
 
 in the .config file
 
@@ -94,12 +92,12 @@ of. Each GPT partition entry in the GPT header has two 
GUIDs::
 * UniquePartitionGUID
 
 The PartitionTypeGUID value should correspond to the
-``image_type_uuid`` field of the FWU metadata. This field is used to
+``image_type_guid`` field of the FWU metadata. This field is used to
 identify a given type of updatable firmware image, e.g. U-Boot,
 OP-TEE, FIP etc. This GUID should also be used for specifying the
 `--guid` parameter when generating the capsule.
 
-The UniquePartitionGUID value should correspond to the ``image_uuid``
+The UniquePartitionGUID value should correspond to the ``image_guid``
 field in the FWU metadata. This GUID is used to identify images of a
 given image type in different banks.
 
@@ -108,8 +106,8 @@ metadata partitions. This would be the PartitionTypeGUID 
for the
 metadata partitions. Similarly, the UEFI specification defines the ESP
 GUID to be be used.
 
-When generating the metadata, the ``image_type_uuid`` and the
-``image_uuid`` values should match the *PartitionTypeGUID* and the
+When generating the metadata, the ``image_type_guid`` and the
+``image_guid`` values should match the *PartitionTypeGUID* and the
 *UniquePartitionGUID* values respectively.
 
 Performing the Update
@@ -181,5 +179,5 @@ empty capsule would be::
 Links
 -
 
-* [1] https://developer.arm.com/documentation/den0118/a/ - FWU Specification
+* [1] https://developer.arm.com/documentation/den0118/ - FWU Specification
 * [2] 
https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
 - Dependable Boot Specification
diff --git a/doc/usage/cmd/fwu_mdata.rst b/doc/usage/cmd/fwu_mdata.rst
index f1bf08fde1..1804422b33 100644
--- a/doc/usage/cmd/fwu_mdata.rst
+++ b/doc/usage/cmd/fwu_mdata.rst
@@ -26,10 +26,14 @@ The output may look like:
 
 => fwu_mdata_read
 FWU Metadata
-crc32: 0xec4fb997
-version: 0x1
-active_index: 0x0
-previous_active_index: 0x1
+crc32: 0x13c330
+version: 0x2
+active_index: 0x1
+previous_active_index: 0x0
+bank_state[0]: 0xfc
+bank_state[1]: 0xfc
+bank_state[2]: 0xff
+bank_state[3]: 0xff
 Image Info
 
 Image Type Guid: 19D5DF83-11B0-457B-BE2C-7559C13142A5
-- 
2.34.1



[PATCH 17/18] configs: fwu: Re-enable FWU configs

2024-01-22 Thread Sughosh Ganu
Now that the migration to the FWU metadata version 2 is complete, the
feature can be re-enabled on platforms which had it enabled.

Signed-off-by: Sughosh Ganu 
---
 configs/corstone1000_defconfig   | 2 ++
 configs/sandbox64_defconfig  | 1 +
 configs/synquacer_developerbox_defconfig | 3 +++
 3 files changed, 6 insertions(+)

diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig
index 24b7984959..e45415b90c 100644
--- a/configs/corstone1000_defconfig
+++ b/configs/corstone1000_defconfig
@@ -25,6 +25,7 @@ CONFIG_BOARD_LATE_INIT=y
 CONFIG_SYS_PROMPT="corstone1000# "
 CONFIG_SYS_MAXARGS=64
 # CONFIG_CMD_CONSOLE is not set
+CONFIG_CMD_FWU_METADATA=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_XIMG is not set
 CONFIG_CMD_GPT=y
@@ -66,3 +67,4 @@ CONFIG_FFA_SHARED_MM_BUF_OFFSET=0
 CONFIG_FFA_SHARED_MM_BUF_ADDR=0x0200
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_IGNORE_OSINDICATIONS=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 7b5888af38..996bb7aa4f 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -274,6 +274,7 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_EFI_SECURE_BOOT=y
 CONFIG_TEST_FDTDEC=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
diff --git a/configs/synquacer_developerbox_defconfig 
b/configs/synquacer_developerbox_defconfig
index 616d410074..1bb55be0a7 100644
--- a/configs/synquacer_developerbox_defconfig
+++ b/configs/synquacer_developerbox_defconfig
@@ -17,6 +17,7 @@ CONFIG_SYS_BOOTM_LEN=0x80
 CONFIG_BOOTSTAGE_STASH_SIZE=4096
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_MAXARGS=128
+CONFIG_CMD_FWU_METADATA=y
 CONFIG_CMD_IMLS=y
 CONFIG_CMD_ERASEENV=y
 CONFIG_CMD_NVEDIT_EFI=y
@@ -51,6 +52,7 @@ CONFIG_DFU_TFTP=y
 CONFIG_DFU_MTD=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
+CONFIG_FWU_MDATA_MTD=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_SYNQUACER=y
 CONFIG_MMC_SDHCI=y
@@ -93,3 +95,4 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_IGNORE_OSINDICATIONS=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
-- 
2.34.1



[PATCH 16/18] tools: mkfwumdata: Migrate to metadata version 2

2024-01-22 Thread Sughosh Ganu
Migrate the metadata generation tool to generate the version 2
metadata.

Signed-off-by: Sughosh Ganu 
---
 tools/mkfwumdata.c | 43 ---
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
index 9732a8ddc5..b43cf38457 100644
--- a/tools/mkfwumdata.c
+++ b/tools/mkfwumdata.c
@@ -14,12 +14,13 @@
 #include 
 #include 
 
-/* This will dynamically allocate the fwu_mdata */
-#define CONFIG_FWU_NUM_BANKS   0
-#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0
-
 /* Since we can not include fwu.h, redefine version here. */
-#define FWU_MDATA_VERSION  1
+#define FWU_MDATA_VERSION  2
+
+#define MAX_BANKS  4
+
+#define BANK_INVALID   0xFF
+#define BANK_ACCEPTED  0xFC
 
 typedef uint8_t u8;
 typedef int16_t s16;
@@ -29,8 +30,6 @@ typedef uint64_t u64;
 
 #include 
 
-/* TODO: Endianness conversion may be required for some arch. */
-
 static const char *opts_short = "b:i:a:p:gh";
 
 static struct option options[] = {
@@ -48,7 +47,7 @@ static void print_usage(void)
fprintf(stderr, "Usage: mkfwumdata [options]  \n");
fprintf(stderr, "Options:\n"
"\t-i, --images   Number of images (mandatory)\n"
-   "\t-b, --banksNumber of banks (mandatory)\n"
+   "\t-b, --banksNumber of banks(1-4) 
(mandatory)\n"
"\t-a, --active-bank  Active bank (default=0)\n"
"\t-p, --previous-bankPrevious active bank 
(default=active_bank - 1)\n"
"\t-g, --guid  Use GUID instead of UUID\n"
@@ -85,6 +84,7 @@ static struct fwu_mdata_object *fwu_alloc_mdata(size_t 
images, size_t banks)
return NULL;
 
mobj->size = sizeof(struct fwu_mdata) +
+   sizeof(struct fwu_fw_store_desc) +
(sizeof(struct fwu_image_entry) +
 sizeof(struct fwu_image_bank_info) * banks) * images;
mobj->images = images;
@@ -105,6 +105,7 @@ fwu_get_image(struct fwu_mdata_object *mobj, size_t idx)
size_t offset;
 
offset = sizeof(struct fwu_mdata) +
+   sizeof(struct fwu_fw_store_desc) +
(sizeof(struct fwu_image_entry) +
 sizeof(struct fwu_image_bank_info) * mobj->banks) * idx;
 
@@ -117,6 +118,7 @@ fwu_get_bank(struct fwu_mdata_object *mobj, size_t img_idx, 
size_t bnk_idx)
size_t offset;
 
offset = sizeof(struct fwu_mdata) +
+   sizeof(struct fwu_fw_store_desc) +
(sizeof(struct fwu_image_entry) +
 sizeof(struct fwu_image_bank_info) * mobj->banks) * img_idx +
sizeof(struct fwu_image_entry) +
@@ -188,7 +190,7 @@ fwu_parse_fill_image_uuid(struct fwu_mdata_object *mobj,
return -EINVAL;
 
if (strcmp(uuid, "0") &&
-   uuid_guid_parse(uuid, (unsigned char *)&image->location_uuid) < 0)
+   uuid_guid_parse(uuid, (unsigned char *)&image->location_guid) < 0)
return -EINVAL;
 
/* Image type UUID */
@@ -196,7 +198,7 @@ fwu_parse_fill_image_uuid(struct fwu_mdata_object *mobj,
if (!uuid)
return -EINVAL;
 
-   if (uuid_guid_parse(uuid, (unsigned char *)&image->image_type_uuid) < 0)
+   if (uuid_guid_parse(uuid, (unsigned char *)&image->image_type_guid) < 0)
return -EINVAL;
 
/* Fill bank image-UUID */
@@ -210,7 +212,7 @@ fwu_parse_fill_image_uuid(struct fwu_mdata_object *mobj,
return -EINVAL;
 
if (strcmp(uuid, "0") &&
-   uuid_guid_parse(uuid, (unsigned char *)&bank->image_uuid) < 
0)
+   uuid_guid_parse(uuid, (unsigned char *)&bank->image_guid) < 
0)
return -EINVAL;
}
return 0;
@@ -225,6 +227,19 @@ static int fwu_parse_fill_uuids(struct fwu_mdata_object 
*mobj, char *uuids[])
mdata->version = FWU_MDATA_VERSION;
mdata->active_index = active_bank;
mdata->previous_active_index = previous_bank;
+   mdata->metadata_size = mobj->size;
+   mdata->desc_offset = sizeof(struct fwu_mdata);
+
+   for (i = 0; i < MAX_BANKS; i++)
+   mdata->bank_state[i] = i < mobj->banks ?
+   BANK_ACCEPTED : BANK_INVALID;
+
+   mdata->fw_desc[0].num_banks = mobj->banks;
+   mdata->fw_desc[0].num_images = mobj->images;
+   mdata->fw_desc[0].img_entry_size = sizeof(struct fwu_image_entry) +
+   (sizeof(struct fwu_image_bank_info) * mobj->banks);
+   mdata->fw_desc[0].bank_info_entry_size =
+   sizeof(struct fwu_image_bank_info);
 
for (i = 0; i < mobj->images; i++) {
ret = fwu_parse_fill_image_uuid(mobj, i, uuids[i]);
@@ -313,6 +328,12 @@ int main(int argc, char *argv[])
return -EINVAL;
}
 
+   if (banks > MAX_BANKS) {

[PATCH 15/18] fwu: Remove the config symbols for number of banks and images

2024-01-22 Thread Sughosh Ganu
With the migration to the FWU metadata version 2 structure, the values
of number of banks and number of images per bank are now obtained from
the metadata at runtime. Remove the now superfluous config symbols.

Signed-off-by: Sughosh Ganu 
---
 arch/sandbox/Kconfig |  6 --
 board/armltd/corstone1000/corstone1000.c |  2 +-
 lib/fwu_updates/Kconfig  | 11 ---
 3 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index 0ce77de2fc..29013a5673 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -79,9 +79,3 @@ config SYS_FDT_LOAD_ADDR
  See `doc/arch/sandbox.rst` for more information.
 
 endmenu
-
-config FWU_NUM_BANKS
-   default 2
-
-config FWU_NUM_IMAGES_PER_BANK
-   default 2
diff --git a/board/armltd/corstone1000/corstone1000.c 
b/board/armltd/corstone1000/corstone1000.c
index 01c80aaf9d..15de738154 100644
--- a/board/armltd/corstone1000/corstone1000.c
+++ b/board/armltd/corstone1000/corstone1000.c
@@ -109,7 +109,7 @@ void fwu_plat_get_bootidx(uint *boot_idx)
 */
ret = fwu_get_active_index(boot_idx);
if (ret < 0) {
-   *boot_idx = CONFIG_FWU_NUM_BANKS;
+   *boot_idx = 0;
log_err("corstone1000: failed to read active index\n");
}
 }
diff --git a/lib/fwu_updates/Kconfig b/lib/fwu_updates/Kconfig
index d35247d0e5..6bb94f88d3 100644
--- a/lib/fwu_updates/Kconfig
+++ b/lib/fwu_updates/Kconfig
@@ -12,17 +12,6 @@ menuconfig FWU_MULTI_BANK_UPDATE
 
 if FWU_MULTI_BANK_UPDATE
 
-config FWU_NUM_BANKS
-   int "Number of Banks defined by the platform"
-   help
- Define the number of banks of firmware images on a platform
-
-config FWU_NUM_IMAGES_PER_BANK
-   int "Number of firmware images per bank"
-   help
- Define the number of firmware images per bank. This value
- should be the same for all the banks.
-
 config FWU_TRIAL_STATE_CNT
int "Number of times system boots in Trial State"
default 3
-- 
2.34.1



[PATCH 14/18] test: fwu: Align the FWU metadata access test with version 2

2024-01-22 Thread Sughosh Ganu
With the FWU metadata support having been migrated to version 2, make
corresponding changes to the test for accessing the FWU metadata.

Signed-off-by: Sughosh Ganu 
---
 test/dm/fwu_mdata.c|  56 ---
 test/dm/fwu_mdata_disk_image.h | 124 ++---
 2 files changed, 83 insertions(+), 97 deletions(-)

diff --git a/test/dm/fwu_mdata.c b/test/dm/fwu_mdata.c
index 52018f610f..73b3382917 100644
--- a/test/dm/fwu_mdata.c
+++ b/test/dm/fwu_mdata.c
@@ -88,10 +88,15 @@ static int write_mmc_blk_device(struct unit_test_state *uts)
return 0;
 }
 
-static int dm_test_fwu_mdata_read(struct unit_test_state *uts)
+static int fwu_mdata_access_setup(struct unit_test_state *uts,
+  struct fwu_mdata **mdata)
 {
+   u32 mdata_size;
struct udevice *dev;
-   struct fwu_mdata mdata = { 0 };
+
+   ut_assertok(setup_blk_device(uts));
+   ut_assertok(populate_mmc_disk_image(uts));
+   ut_assertok(write_mmc_blk_device(uts));
 
/*
 * Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
@@ -100,13 +105,24 @@ static int dm_test_fwu_mdata_read(struct unit_test_state 
*uts)
event_notify_null(EVT_MAIN_LOOP);
 
ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, &dev));
-   ut_assertok(setup_blk_device(uts));
-   ut_assertok(populate_mmc_disk_image(uts));
-   ut_assertok(write_mmc_blk_device(uts));
 
-   ut_assertok(fwu_get_mdata(&mdata));
+   ut_assertok(fwu_get_mdata_size(&mdata_size));
 
-   ut_asserteq(mdata.version, 0x1);
+   *mdata = malloc(mdata_size);
+   ut_assertnonnull(*mdata);
+
+   return 0;
+}
+
+static int dm_test_fwu_mdata_read(struct unit_test_state *uts)
+{
+   struct fwu_mdata *mdata = NULL;
+
+   fwu_mdata_access_setup(uts, &mdata);
+
+   ut_assertok(fwu_get_mdata(mdata));
+
+   ut_asserteq(mdata->version, 0x2);
 
return 0;
 }
@@ -114,29 +130,21 @@ DM_TEST(dm_test_fwu_mdata_read, UT_TESTF_SCAN_FDT);
 
 static int dm_test_fwu_mdata_write(struct unit_test_state *uts)
 {
+   u8 num_banks;
u32 active_idx;
-   struct udevice *dev;
-   struct fwu_mdata mdata = { 0 };
-
-   /*
-* Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
-* to populate g_dev global pointer in that library.
-*/
-   event_notify_null(EVT_MAIN_LOOP);
+   struct fwu_mdata *mdata = NULL;
 
-   ut_assertok(setup_blk_device(uts));
-   ut_assertok(populate_mmc_disk_image(uts));
-   ut_assertok(write_mmc_blk_device(uts));
-
-   ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, &dev));
+   fwu_mdata_access_setup(uts, &mdata);
 
-   ut_assertok(fwu_get_mdata(&mdata));
+   ut_assertok(fwu_get_mdata(mdata));
+   num_banks = mdata->fw_desc[0].num_banks;
+   ut_asserteq(2, num_banks);
 
-   active_idx = (mdata.active_index + 1) % CONFIG_FWU_NUM_BANKS;
+   active_idx = (mdata->active_index + 1) % num_banks;
ut_assertok(fwu_set_active_index(active_idx));
 
-   ut_assertok(fwu_get_mdata(&mdata));
-   ut_asserteq(mdata.active_index, active_idx);
+   ut_assertok(fwu_get_mdata(mdata));
+   ut_asserteq(mdata->active_index, active_idx);
 
return 0;
 }
diff --git a/test/dm/fwu_mdata_disk_image.h b/test/dm/fwu_mdata_disk_image.h
index b9803417c8..b15b06b9de 100644
--- a/test/dm/fwu_mdata_disk_image.h
+++ b/test/dm/fwu_mdata_disk_image.h
@@ -6,107 +6,85 @@
  */
 
 #define FWU_MDATA_DISK_IMG { 0x0001, { \
-   {0x01c0, "\x02\x00\xee\x02\x02\x00\x01\x00"}, /*  */ \
+   {0x01c0, "\x02\x00\xee\xff\xff\xff\x01\x00"}, /*  */ \
{0x01c8, "\x00\x00\x7f\x00\x00\x00\x00\x00"}, /*  */ \
{0x01f8, "\x00\x00\x00\x00\x00\x00\x55\xaa"}, /* ..U. */ \
{0x0200, "\x45\x46\x49\x20\x50\x41\x52\x54"}, /* EFI PART */ \
{0x0208, "\x00\x00\x01\x00\x5c\x00\x00\x00"}, /* \... */ \
-   {0x0210, "\xa6\xf6\x92\x20\x00\x00\x00\x00"}, /* ...  */ \
+   {0x0210, "\x52\x5f\x3a\xa1\x00\x00\x00\x00"}, /* R_:. */ \
{0x0218, "\x01\x00\x00\x00\x00\x00\x00\x00"}, /*  */ \
{0x0220, "\x7f\x00\x00\x00\x00\x00\x00\x00"}, /*  */ \
{0x0228, "\x22\x00\x00\x00\x00\x00\x00\x00"}, /* "... */ \
{0x0230, "\x5e\x00\x00\x00\x00\x00\x00\x00"}, /* ^... */ \
-   {0x0238, "\xde\x99\xa2\x7e\x46\x34\xeb\x47"}, /* ...~F4.G */ \
-   {0x0240, "\x87\xf6\x4f\x75\xe8\xd5\x7d\xc7"}, /* ..Ou..}. */ \
+   {0x0238, "\xf5\xf3\x9d\xb9\x92\xdd\x48\x60"}, /* ..H` */ \
+   {0x0240, "\x9a\x04\xe5\x2b\x11\xcb\x42\x61"}, /* ...+..Ba */ \
{0x0248, "\x02\x00\x00\x00\x00\x00\x00\x00"}, /*  */ \
{0x0250, "\x80\x00\x00\x00\x80\x00\x00\x00"}, /*  */ \
-   {0x0258, "\x2a\x64\x03\x83\x00\x00\x00\x00"}, /* .d.. */ \
+   {0x0258, "\xc4\x80\x68

  1   2   >