Re: [PATCH 0/5] riscv: mbv: Enhance MB-V support with also enabling SPL

[Michal Simek]

On 2/14/24 12:52, Michal Simek wrote:

Hi,

enhance MB-V support with SPL configuration to support OpenSBI.
All of that changes are out of generic Risc-V support that's why happy to
take it via my tree. Please let me know if you want this to take via riscv
subtree.


Applied via my xilinx tree.

Thanks,
Michal

Re: [PATCH] arm64: zynqmp: Remove snps,enable_guctl1_ipd_quirk property

[Michal Simek]

On 2/26/24 16:54, Michal Simek wrote:

Remove undocumented DT property. Suggested solution was to apply quirk
via glue logic driver that's why make no sense to have it listed in DT.

Signed-off-by: Michal Simek 
---

For more information please take a look at:
https://lore.kernel.org/r/1708023665-1441674-1-git-send-email-radhey.shyam.pan...@amd.com
https://lore.kernel.org/r/1708717523-4006664-1-git-send-email-radhey.shyam.pan...@amd.com
---
  arch/arm/dts/zynqmp.dtsi | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index b50b83b7723f..daae23c12b79 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -1008,7 +1008,6 @@
/* iommus = < 0x860>; */
snps,quirk-frame-length-adjustment = <0x20>;
clock-names = "ref";
-   snps,enable_guctl1_ipd_quirk;
snps,resume-hs-terminations;
/* dma-coherent; */
};
@@ -1040,7 +1039,6 @@
/* iommus = < 0x861>; */
snps,quirk-frame-length-adjustment = <0x20>;
clock-names = "ref";
-   snps,enable_guctl1_ipd_quirk;
snps,resume-hs-terminations;
/* dma-coherent; */
};


Applied.
M

Re: [PATCH 1/5] configs: zynqmp: don't remove power-domains for spl device tree

[Michal Simek]

On 2/23/24 15:06, Steffen Dirkwinkel wrote:

From: Steffen Dirkwinkel 

These are used during sdhci initialization as functions are called with
node_id even if we're not talking to the firmware.

Signed-off-by: Steffen Dirkwinkel 
---

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

diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index 1fcae45e95d..a96b088534a 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -107,7 +107,7 @@ CONFIG_PARTITION_TYPE_GUID=y
  CONFIG_SPL_OF_CONTROL=y
  CONFIG_OF_BOARD=y
  CONFIG_OF_LIST="avnet-ultra96-rev1 zynqmp-a2197-revA zynqmp-e-a2197-00-revA 
zynqmp-e-a2197-00-revB zynqmp-g-a2197-00-revA zynqmp-m-a2197-01-revA 
zynqmp-m-a2197-02-revA zynqmp-m-a2197-03-revA zynqmp-p-a2197-00-revA zynqmp-zc1232-revA 
zynqmp-zc1254-revA zynqmp-zc1751-xm015-dc1 zynqmp-zc1751-xm016-dc2 
zynqmp-zc1751-xm017-dc3 zynqmp-zc1751-xm018-dc4 zynqmp-zc1751-xm019-dc5 
zynqmp-zcu100-revC zynqmp-zcu102-rev1.1 zynqmp-zcu102-rev1.0 zynqmp-zcu102-revA 
zynqmp-zcu102-revB zynqmp-zcu104-revA zynqmp-zcu104-revC zynqmp-zcu106-revA 
zynqmp-zcu106-rev1.0 zynqmp-zcu111-revA zynqmp-zcu1275-revA zynqmp-zcu1275-revB 
zynqmp-zcu1285-revA zynqmp-zcu208-revA zynqmp-zcu216-revA 
zynqmp-topic-miamimp-xilinx-xdp-v1r1 zynqmp-sm-k26-revA zynqmp-smk-k26-revA 
zynqmp-dlc21-revA"
-CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent interrupts 
iommus power-domains"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent interrupts 
iommus"
  CONFIG_ENV_IS_NOWHERE=y
  CONFIG_ENV_IS_IN_FAT=y
  CONFIG_ENV_IS_IN_NAND=y


just FYI. I have asked my colleague to take this to regression and see if there 
is any issue. I will let you know when I know more.


Thanks,
Michal

Re: [PATCH v1 2/5] tee: sandbox: fix spelling errors

[Ilias Apalodimas]

On Wed, Feb 14, 2024 at 07:34:41PM +0100, Igor Opaniuk wrote:
> Fix spelling errors in comments.
> 
> Signed-off-by: Igor Opaniuk 
> ---
> 
>  drivers/tee/sandbox.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
> index 86219a9bb1a..ec66401878c 100644
> --- a/drivers/tee/sandbox.c
> +++ b/drivers/tee/sandbox.c
> @@ -14,7 +14,7 @@
>  #include "optee/optee_private.h"
>  
>  /*
> - * The sandbox tee driver tries to emulate a generic Trusted Exectution
> + * The sandbox tee driver tries to emulate a generic Trusted Execution
>   * Environment (TEE) with the Trusted Applications (TA) OPTEE_TA_AVB and
>   * OPTEE_TA_RPC_TEST available.
>   */
> @@ -23,7 +23,7 @@ static const u32 pstorage_max = 16;
>  /**
>   * struct ta_entry - TA entries
>   * @uuid:UUID of an emulated TA
> - * @open_session Called when a session is openened to the TA
> + * @open_session Called when a session is opened to the TA
>   * @invoke_func  Called when a function in the TA is to be 
> invoked
>   *
>   * This struct is used to register TAs in this sandbox emulation of a TEE.
> @@ -140,8 +140,8 @@ static u32 pta_scp03_invoke_func(struct udevice *dev, u32 
> func, uint num_params,
>   provisioned = true;
>  
>   /*
> -  * Either way, we asume both operations succeeded and that
> -  * the communication channel has now been stablished
> +  * Either way, we assume both operations succeeded and that
> +  * the communication channel has now been established
>*/
>  
>   return TEE_SUCCESS;
> -- 
> 2.34.1
> 
Reviewed-by: Ilias Apalodimas 

Re: [PATCH v1 1/5] tee: optee: fix description in Kconfig

[Ilias Apalodimas]

On Wed, Feb 14, 2024 at 07:34:40PM +0100, Igor Opaniuk wrote:
> Fix OPTEE_TA_AVB symbol description in Kconfig:
> s/"write"rb"/"write_rb"/g
> 
> Signed-off-by: Igor Opaniuk 
> ---
> 
>  drivers/tee/optee/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
> index 9dc65b0501e..db0bcfa6f15 100644
> --- a/drivers/tee/optee/Kconfig
> +++ b/drivers/tee/optee/Kconfig
> @@ -19,7 +19,7 @@ config OPTEE_TA_AVB
>   default y
>   help
> Enables support for the AVB Trusted Application (TA) in OP-TEE.
> -   The TA can support the "avb" subcommands "read_rb", "write"rb"
> +   The TA can support the "avb" subcommands "read_rb", "write_rb"
> and "is_unlocked".
>  
>  config OPTEE_TA_RPC_TEST
> -- 
> 2.34.1
> 

Reviewed-by: Ilias Apalodimas 

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Sumit Garg]

On Thu, 29 Feb 2024 at 19:31, Tom Rini  wrote:
>
> On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
> > On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
> > > On Wed, 28 Feb 2024 at 20:50, Tom Rini  wrote:
> > > >
> > > > On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > > > > + Shawn, Krzysztof, Conor
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini  wrote:
> > > > > >
> > > > > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski 
> > > > > > > wrote:
> > > > > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees 
> > > > > > > > with
> > > > > > > > linux") removed the display timings from the board device tree 
> > > > > > > > whereas
> > > > > > > > they are still needed by the mxsfb driver.
> > > > > > > > Add the timings back (the correct ones) in the
> > > > > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > > > > > opos6uldev.env file.
> > > > > > > >
> > > > > > > > Update the opos6uldev_defconfig file so that the LCD turns on 
> > > > > > > > at boot.
> > > > > > > >
> > > > > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees 
> > > > > > > > with linux")
> > > > > > > > Signed-off-by: Sébastien Szymanski 
> > > > > > > > 
> > > > > > >
> > > > > > > Huh.  This is the commit that did that upstream.
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > > > > >
> > > > > > > It's interesting how the timings in linux were always slightly 
> > > > > > > different
> > > > > > > from in u-boot.
> > > > > >
> > > > > > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> > > > > > because this is a recent (rather than ancient) example of one of the
> > > > > > concerns about OF_UPSTREAM.
> > > > >
> > > > > I rather think about this as an opportunity to improve with
> > > > > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > > > > corresponding Linux kernel sub-arch maintainers. Especially once we
> > > > > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
> > > > > to keep them aware that U-Boot should be considered too.
> > > >
> > > > Yes, a more extensive check around when removing information from dts
> > > > files would be good.
> > > >
> > > > > > I think the commit in question can be
> > > > > > summarized as "remove a bunch of explicit HW information because 
> > > > > > there's
> > > > > > now a Linux Kernel driver that determines that dynamically". What 
> > > > > > do we
> > > > > > do next? The old information is in a presumably valid binding 
> > > > > > still, can
> > > > > > we just put it back and comment that consumers outside of Linux use 
> > > > > > this
> > > > > > still so it's not removed again later? Or am I just missing where 
> > > > > > we can
> > > > > > instead get this information from the DT still and not need to come 
> > > > > > up
> > > > > > with a new driver and subsystems?
> > > > >
> > > > > I can see following two paths forward:
> > > > >
> > > > > 1) Partially revert the Linux kernel commit to add back the display
> > > > > timings in DT.
> > > > > 2) Extend drivers/video/simple_panel.c in U-Boot to add support for
> > > > > compatible: "armadeus,st0700-adapt".
> > > > >
> > > > > If possible then I would be in favour of (2) rather than the current
> > > > > patch to do this properly.
> > > >
> > > > Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
> > > > and then our drivers/video/simple_panel.c it sure would be nice if it's
> > > > just a matter of adding a compatible but I wouldn't be surprised if it
> > > > ends up needing more information being passed along too?
> > >
> > > Although I am not a LCD panel expert but looking at the kernel driver
> > > code [1], the display timings are rather taken from a static data
> > > structure matching the compatible "armadeus,st0700-adapt".
> > >
> > > [1] 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c#n901
> >
> > Yes. My point is that it seems like the situation changed from "device
> > tree provides timings for the platform" to "driver has timing
> > information for N displays" and so we'll need to do something clever to
> > avoid including the structs for 5 panels when we'll only ever
> > (likely...) see one. And that also yes, we'll probably need to add data
> > for this panel rather than re-use the PANASONIC_VVX10F004B00 data.
> >
> > > > And I'm going
> > > > assume there's good reasons for the design change in how the drivers
> > > > work in Linux now and note that it might make things more challenging
> > > > for us when we do care about space.
> > >
> > > I agree it is always going to be challenging to use DT during SPL
> > > stage which is mostly 

Re: [RFC PATCH 3/4] arm: dts: k3-j721e: Separate boot binary build

[Neha Malcom Francis]

Hi Manorit

On 01/03/24 10:56, Manorit Chawdhry wrote:

Hi Neha,

On 16:50-20240228, Neha Malcom Francis wrote:

Separate out the boot binaries built for J721E boards; J721E EVM and
J721E SK by using the common templates in k3-j721e-binman.dtsi.

Only the required boot binaries can be built from the templates in the
boards' respective -u-boot.dtsi file. FDTs and configurations are also
moved to the -u-boot.dtsi file to allow clear distinction between the
SoC common stuff vs. what is needed to boot up a board.

Signed-off-by: Neha Malcom Francis 
---
Note: I have added "dummy" sections so that node for a phandle is found
correctly. The node for a phandle is searched for among sub-nodes of a
section (check tools/binman/etype/section.py GetContentsByPhandle) and
having a template as the section instead, causes failure to find the
phandle despite it being present in the FDT. So the dummy section
bypasses this.

Avoided correct DTS alignment for the RFC at least so that it's clear
what is actually being changed.

  arch/arm/dts/k3-j721e-binman.dtsi | 178 +-
  .../k3-j721e-common-proc-board-u-boot.dtsi| 138 ++
  arch/arm/dts/k3-j721e-sk-u-boot.dtsi  | 104 ++
  3 files changed, 284 insertions(+), 136 deletions(-)



[snip]


diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 7ae7cf3d4c9..ff96bc3f724 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -187,3 +187,141 @@
  _fss0_ospi1_pins_default {
bootph-all;
  };
+
+#ifdef CONFIG_TARGET_J721E_R5_EVM
+
+ {
+   tiboot3-j721e-sr1-1-hs-evm {
+   insert-template = <_j721e_sr1_1_hs>;
+   };
+   sysfw-j721e-sr1-1-hs-evm {
+   insert-template = <>;
+   };
+   itb-j721e-sr1-1-hs-evm {
+   insert-template = <>;
+   };
+};
+
+ {
+   tiboot3-j721e-sr2-hs-evm {
+   insert-template = <_j721e_sr2_hs>;
+   };
+   sysfw-j721e-sr2-hs-evm {
+   insert-template = <_sr2>;
+   };
+   itb-j721e-sr2-hs-evm {
+   insert-template = <_sr2>;
+   };
+};
+
+ {
+   tiboot3-j721e-sr2-hs-fs-evm {
+   insert-template = <_j721e_sr2_hs_fs>;
+   };
+   sysfw-j721e-sr2-hs-fs-evm {
+   insert-template = <_fs>;
+   };
+   itb-j721e-sr2-hs-fs-evm {
+   insert-template = <_fs>;
+   };
+};
+
+ {
+   tiboot3-j721e-gp-evm {
+   insert-template = <_j721e_gp>;
+   };
+   sysfw-j721e-gp-evm {
+   insert-template = <_gp>;
+   };
+   itb-j721e-gp-evm {
+   insert-template = <_gp>;
+   };
+};
+
+#else
+
+#define SPL_J721E_EVM_DTB "spl/dts/k3-j721e-common-proc-board.dtb"
+


Trying to gauge the changes that are required for EVM to SK, I notice a
few only ( let me know if I missed ).

1. DTB
2. Description name.

Considering this, templating does seem good but I was thinking of a
different design as well. Let me know what you think about it.

I was thinking that the binman node can remain as is with some generic
macros like taking the fdt-0 node of tispl.bin

We can have something like this.

in arch/arm/dts/k3-j721e-binman.dtsi:

fit {
images {
fdt-0 {
description = BOARD_DESCRIPTION;
ti-secure {
content = <_j721e_dtb>;
keyfile = "custMpk.pem";
}
spl_j721e_dtb: blob-ext {
filename = BOARD_SPL_DTB;
}
}
}
}

And then in the board specific -u-boot overrides, we can have something
like this -

in arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi

#define BOARD_DESCRIPTION "k3-j721e-common-proc-board";
#define BOARD_SPL_DTB "spl/dts/k3-j721e-common-proc-board.dtb";
#include 

in arch/arm/dts/k3-j721e-sk-u-boot.dtsi

#define BOARD_DESCRIPTION "k3-j721e-sk";
#define BOARD_SPL_DTB "spl/dts/k3-j721e-sk.dtb"
#include 

I think if we have a less enough diff only between these two then I am
hoping something like this can be better maybe. Let me know what your
thoughts would be on that.

Regards,
Manorit



Yes this can reduce the code size nicely and cleanly, I will take this into 
account in the proper version, thanks!



+ {
+   tispl {
+   insert-template = <_spl>;
+   fit {
+   images {
+   fdt-0 {
+   description = 
"k3-j721e-common-proc-board";
+   ti-secure {
+   content = <_j721e_evm_dtb>;
+   keyfile = "custMpk.pem";
+   };
+  

Re: [PATCH v2] board: synquacer: developerbox: add myself as maintainer

[Jassi Brar]

On Thu, 29 Feb 2024 at 22:38, Masahisa Kojima
 wrote:
>
> Add myself as maintainer for SynQuacer Developerbox,
> as I'm currently working on it.
> This commit also removes Jassi from maintainer since he
> no longer has a Developerbox.
>
Acked-by: Jassi Brar 

Re: [RFC PATCH 3/4] arm: dts: k3-j721e: Separate boot binary build

[Manorit Chawdhry]

Hi Neha,

On 16:50-20240228, Neha Malcom Francis wrote:
> Separate out the boot binaries built for J721E boards; J721E EVM and
> J721E SK by using the common templates in k3-j721e-binman.dtsi.
> 
> Only the required boot binaries can be built from the templates in the
> boards' respective -u-boot.dtsi file. FDTs and configurations are also
> moved to the -u-boot.dtsi file to allow clear distinction between the
> SoC common stuff vs. what is needed to boot up a board.
> 
> Signed-off-by: Neha Malcom Francis 
> ---
> Note: I have added "dummy" sections so that node for a phandle is found
> correctly. The node for a phandle is searched for among sub-nodes of a
> section (check tools/binman/etype/section.py GetContentsByPhandle) and
> having a template as the section instead, causes failure to find the
> phandle despite it being present in the FDT. So the dummy section
> bypasses this.
> 
> Avoided correct DTS alignment for the RFC at least so that it's clear
> what is actually being changed.
> 
>  arch/arm/dts/k3-j721e-binman.dtsi | 178 +-
>  .../k3-j721e-common-proc-board-u-boot.dtsi| 138 ++
>  arch/arm/dts/k3-j721e-sk-u-boot.dtsi  | 104 ++
>  3 files changed, 284 insertions(+), 136 deletions(-)
> 

[snip]

> diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
> b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> index 7ae7cf3d4c9..ff96bc3f724 100644
> --- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> @@ -187,3 +187,141 @@
>  _fss0_ospi1_pins_default {
>   bootph-all;
>  };
> +
> +#ifdef CONFIG_TARGET_J721E_R5_EVM
> +
> + {
> + tiboot3-j721e-sr1-1-hs-evm {
> + insert-template = <_j721e_sr1_1_hs>;
> + };
> + sysfw-j721e-sr1-1-hs-evm {
> + insert-template = <>;
> + };
> + itb-j721e-sr1-1-hs-evm {
> + insert-template = <>;
> + };
> +};
> +
> + {
> + tiboot3-j721e-sr2-hs-evm {
> + insert-template = <_j721e_sr2_hs>;
> + };
> + sysfw-j721e-sr2-hs-evm {
> + insert-template = <_sr2>;
> + };
> + itb-j721e-sr2-hs-evm {
> + insert-template = <_sr2>;
> + };
> +};
> +
> + {
> + tiboot3-j721e-sr2-hs-fs-evm {
> + insert-template = <_j721e_sr2_hs_fs>;
> + };
> + sysfw-j721e-sr2-hs-fs-evm {
> + insert-template = <_fs>;
> + };
> + itb-j721e-sr2-hs-fs-evm {
> + insert-template = <_fs>;
> + };
> +};
> +
> + {
> + tiboot3-j721e-gp-evm {
> + insert-template = <_j721e_gp>;
> + };
> + sysfw-j721e-gp-evm {
> + insert-template = <_gp>;
> + };
> + itb-j721e-gp-evm {
> + insert-template = <_gp>;
> + };
> +};
> +
> +#else
> +
> +#define SPL_J721E_EVM_DTB "spl/dts/k3-j721e-common-proc-board.dtb"
> +

Trying to gauge the changes that are required for EVM to SK, I notice a
few only ( let me know if I missed ). 

1. DTB
2. Description name.

Considering this, templating does seem good but I was thinking of a
different design as well. Let me know what you think about it.

I was thinking that the binman node can remain as is with some generic
macros like taking the fdt-0 node of tispl.bin

We can have something like this.

in arch/arm/dts/k3-j721e-binman.dtsi:

fit {
images {
fdt-0 {
description = BOARD_DESCRIPTION;
ti-secure {
content = <_j721e_dtb>;
keyfile = "custMpk.pem";
}
spl_j721e_dtb: blob-ext {
filename = BOARD_SPL_DTB;
}
}
}
}

And then in the board specific -u-boot overrides, we can have something
like this -

in arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi

#define BOARD_DESCRIPTION "k3-j721e-common-proc-board";
#define BOARD_SPL_DTB "spl/dts/k3-j721e-common-proc-board.dtb";
#include 

in arch/arm/dts/k3-j721e-sk-u-boot.dtsi

#define BOARD_DESCRIPTION "k3-j721e-sk";
#define BOARD_SPL_DTB "spl/dts/k3-j721e-sk.dtb"
#include 

I think if we have a less enough diff only between these two then I am
hoping something like this can be better maybe. Let me know what your
thoughts would be on that.

Regards,
Manorit

> + {
> + tispl {
> + insert-template = <_spl>;
> + fit {
> + images {
> + fdt-0 {
> + description = 
> "k3-j721e-common-proc-board";
> + ti-secure {
> + content = <_j721e_evm_dtb>;
> + keyfile = "custMpk.pem";
> + };
> + spl_j721e_evm_dtb: blob-ext {
> + 

[PATCH v2] board: synquacer: developerbox: add myself as maintainer

[Masahisa Kojima]

Add myself as maintainer for SynQuacer Developerbox,
as I'm currently working on it.
This commit also removes Jassi from maintainer since he
no longer has a Developerbox.

Cc: Jassi Brar 
Signed-off-by: Masahisa Kojima 
---
v1 -> v2
- remove Jassi from maintainer

 board/socionext/developerbox/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/socionext/developerbox/MAINTAINERS 
b/board/socionext/developerbox/MAINTAINERS
index c6d4f2749d..ca606c83d3 100644
--- a/board/socionext/developerbox/MAINTAINERS
+++ b/board/socionext/developerbox/MAINTAINERS
@@ -1,5 +1,5 @@
 DEVELOPER BOX
-M: Jassi Brar 
+M: Masahisa Kojima 
 S: Maintained
 F: arch/arm/dts/synquacer-*
 F: board/socionext/developerbox/*
-- 
2.34.1

RE: [PATCH] board: synquacer: developerbox: add myself as co-maintainer

[kojima.masahisa]

> -Original Message-
> From: Jassi Brar 
> Sent: Friday, March 1, 2024 1:14 PM
> To: Kojima, Masahisa/小島 雅久 
> Cc: u-boot@lists.denx.de; Jassi Brar ; Tom Rini
> 
> Subject: Re: [PATCH] board: synquacer: developerbox: add myself as
> co-maintainer
> 
> On Thu, Feb 29, 2024 at 6:37 PM Masahisa Kojima
>  wrote:
> >
> > Add myself as co-maintainer for SynQuacer Developerbox,
> > as I'm currently working on it.
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> >  board/socionext/developerbox/MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/board/socionext/developerbox/MAINTAINERS
> b/board/socionext/developerbox/MAINTAINERS
> > index c6d4f2749d..d772bc3b4c 100644
> > --- a/board/socionext/developerbox/MAINTAINERS
> > +++ b/board/socionext/developerbox/MAINTAINERS
> > @@ -1,5 +1,6 @@
> >  DEVELOPER BOX
> >  M: Jassi Brar 
> > +M: Masahisa Kojima 
> >  S: Maintained
> >  F: arch/arm/dts/synquacer-*
> >  F: board/socionext/developerbox/*
> >
> Considering that I no longer have a Developerbox, maybe remove me as a
> maintainer too.

OK, will send v2.

Thanks,
Masahisa Kojima

> 
> Thanks,
> Jassi

Re: [PATCH] board: synquacer: developerbox: add myself as co-maintainer

[Jassi Brar]

On Thu, Feb 29, 2024 at 6:37 PM Masahisa Kojima
 wrote:
>
> Add myself as co-maintainer for SynQuacer Developerbox,
> as I'm currently working on it.
>
> Signed-off-by: Masahisa Kojima 
> ---
>  board/socionext/developerbox/MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/board/socionext/developerbox/MAINTAINERS 
> b/board/socionext/developerbox/MAINTAINERS
> index c6d4f2749d..d772bc3b4c 100644
> --- a/board/socionext/developerbox/MAINTAINERS
> +++ b/board/socionext/developerbox/MAINTAINERS
> @@ -1,5 +1,6 @@
>  DEVELOPER BOX
>  M: Jassi Brar 
> +M: Masahisa Kojima 
>  S: Maintained
>  F: arch/arm/dts/synquacer-*
>  F: board/socionext/developerbox/*
>
Considering that I no longer have a Developerbox, maybe remove me as a
maintainer too.

Thanks,
Jassi

Re: [PATCH] board: rockchip: add Rockchip Toybrick TB-RK3588X board

[Elon Zhang]

Hi Tom,

On 2/29/2024 23:08, Tom Rini wrote:

On Thu, Feb 29, 2024 at 08:04:16PM +0800, Elon Zhang wrote:


TB-RK3588X board is a Rockchip Toybrick RK3588 based development board.

Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB Memory LPDDR4x
Mali G610MC4 GPU
2× MIPI-CSI0 Connector
1x 2Lanes PCIe3.0 Connector
1x SATA3.0 Connector
32GB eMMC Module
2x USB 2.0, 2x USB 3.0
1x HDMI Output, 1x HDMI Input
2x Ethernet Port

Functions work normally:
[1] USB2.0 Host
[2] Ethernet0 with PHY RTL8211F

More information can be obtained from the following websites:
[1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html
[2] http://t.rock-chips.com/

Kernel commits:
8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for TB-RK3588X 
board")
7140387ff49d ("dt-bindings: arm: rockchip: Add Toybrick TB-RK3588X")

Signed-off-by: Elon Zhang 

[snip]

+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y

Is this just a copy/paste thing that keeps getting re-used? Ideally,
BOARD_SPECIFIC_OPTIONS shouldn't exist and it's either a select/imply at
the TARGET_... level or something in the defconfig. But having an empty
one is very confusing.

Yes... It will be removed later. Thanks for review!

Best regards,
Elon

[PATCH] board: synquacer: developerbox: add myself as co-maintainer

[Masahisa Kojima]

Add myself as co-maintainer for SynQuacer Developerbox,
as I'm currently working on it.

Signed-off-by: Masahisa Kojima 
---
 board/socionext/developerbox/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/socionext/developerbox/MAINTAINERS 
b/board/socionext/developerbox/MAINTAINERS
index c6d4f2749d..d772bc3b4c 100644
--- a/board/socionext/developerbox/MAINTAINERS
+++ b/board/socionext/developerbox/MAINTAINERS
@@ -1,5 +1,6 @@
 DEVELOPER BOX
 M: Jassi Brar 
+M: Masahisa Kojima 
 S: Maintained
 F: arch/arm/dts/synquacer-*
 F: board/socionext/developerbox/*
-- 
2.34.1

Re: [RFC PATCH 0/6] Clean up arm linker scripts

[Tom Rini]

On Thu, Feb 29, 2024 at 02:07:39PM -0700, Sam Edwards wrote:
> 
> 
> On 2/28/24 04:15, Ilias Apalodimas wrote:
> > On Wed, 28 Feb 2024 at 13:11, Peter Robinson  wrote:
> > > 
> > > On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
> > >  wrote:
> > > > 
> > > > The arm linker scripts had a mix of symbols and C defined variables in 
> > > > an
> > > > effort to emit relative references instead of absolute ones e.g [0].
> > > > This has led to confusion over the years, ending up with mixed section
> > > > definitions. Some sections being defined with overlays and different
> > > > definitions between v7 and v8 architectures.
> > > > For example __efi_runtime_rel_start/end is defined as a linker symbol 
> > > > for
> > > > armv8 and a C variable in armv7.
> > > > 
> > > > I am not sure if this used to be a compiler bug, but linker scripts 
> > > > nowadays
> > > > can emit relative references, as long as the symbol definition is 
> > > > contained
> > > > within the section definition. So let's switch most of the C defined 
> > > > variables
> > > 
> > > Should we be setting/upping the minimum version of the linker version
> > > as part of this?
> > 
> > The patch that added those as C-defined variables, was in 2013. So any
> > linker that's not ancient history should emit those correctly.
> > 
> 
> GNU ld fixed the problem on 2016-02-23, with this entry in the bfd
> changelog:
> 
>   * elflink.c (bfd_elf_record_link_assignment): Check for shared
>   library, instead of PIC, and don't check PDE when making linker
>   assigned symbol dynamic.
> 
> It looks like the change was first included in binutils 2.27, released
> 2016-08-03. I don't know where the minimum linker version requirement is
> memorialized but there's a good chance that U-Boot already requires a
> version more recent than that. (Someone who knows where that is will have to
> check.)
> 
> In either case, I strongly agree: sections.c is an unnecessary workaround
> with any reasonably recent linker version, it's fickle/incompatible with
> non-GNU linkers such as LLD, and the marker symbols belong in the linker
> script. This patchset is a big step in the right direction!

We have the ld-version check logic same as the kernel but do not today
enforce any minimum version. On ARM we only enforce gcc 6.0.0 being a
minimum version, and that's likely too old too, in reality. So adding a
check would be nice, but not required I think, given the age of the fix.
Thanks for digging in to this!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] autoboot: Add check for result of malloc_cache_aligned()

[Maks Mishin]

Return value of a function 'malloc_cache_aligned'
is dereferenced at autoboot.c:207 without checking for NULL,
but it is usually checked for this function.

Found by RASU JSC.

Signed-off-by: Maks Mishin 
---
 common/autoboot.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/autoboot.c b/common/autoboot.c
index 5d331991c1..6f0aeae6bf 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -167,6 +167,9 @@ static int passwd_abort_sha256(uint64_t etime)
sha_env_str = AUTOBOOT_STOP_STR_SHA256;
 
presskey = malloc_cache_aligned(DELAY_STOP_STR_MAX_LENGTH);
+   if (!presskey)
+   return -ENOMEM;
+
c = strstr(sha_env_str, ":");
if (c && (c - sha_env_str < DELAY_STOP_STR_MAX_LENGTH)) {
/* preload presskey with salt */
-- 
2.30.2

Re: [RFC PATCH 0/6] Clean up arm linker scripts

[Sam Edwards]

On 2/28/24 04:15, Ilias Apalodimas wrote:

On Wed, 28 Feb 2024 at 13:11, Peter Robinson  wrote:


On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
 wrote:


The arm linker scripts had a mix of symbols and C defined variables in an
effort to emit relative references instead of absolute ones e.g [0].
This has led to confusion over the years, ending up with mixed section
definitions. Some sections being defined with overlays and different
definitions between v7 and v8 architectures.
For example __efi_runtime_rel_start/end is defined as a linker symbol for
armv8 and a C variable in armv7.

I am not sure if this used to be a compiler bug, but linker scripts nowadays
can emit relative references, as long as the symbol definition is contained
within the section definition. So let's switch most of the C defined variables


Should we be setting/upping the minimum version of the linker version
as part of this?


The patch that added those as C-defined variables, was in 2013. So any
linker that's not ancient history should emit those correctly.



GNU ld fixed the problem on 2016-02-23, with this entry in the bfd 
changelog:


* elflink.c (bfd_elf_record_link_assignment): Check for shared
library, instead of PIC, and don't check PDE when making linker
assigned symbol dynamic.

It looks like the change was first included in binutils 2.27, released 
2016-08-03. I don't know where the minimum linker version requirement is 
memorialized but there's a good chance that U-Boot already requires a 
version more recent than that. (Someone who knows where that is will 
have to check.)


In either case, I strongly agree: sections.c is an unnecessary 
workaround with any reasonably recent linker version, it's 
fickle/incompatible with non-GNU linkers such as LLD, and the marker 
symbols belong in the linker script. This patchset is a big step in the 
right direction!







and clean up the arm sections.c file. There's still a few symbols remaining --
__secure_start/end, __secure_stack_start/end and __end which can be cleaned up
in a followup series.

The resulting binary (tested in QEMU v7/v8) had no size differences apart from
the emited sections and object types of those variables. I've also added prints
throughout the U-Boot init sequence. The offsets and delta for 'end - start'
section sizes is unchanged.

For example on QEMU v8:
$~ ./scripts/bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new   delta
Total: Before=798861, After=798861, chg +0.00%

$~ readelf -sW u-boot | grep bss_s
 12: 001029b8 0 SECTION LOCAL  DEFAULT   12 .bss_start
   8088: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
   8376: 001029b8 0 OBJECT  GLOBAL DEFAULT   12 __bss_start
$~ readelf -sW u-boot.new | grep bss_s
   8085: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
   8373: 001029b8 0 NOTYPE  GLOBAL DEFAULT   12 __bss_start

For QEMU v7 the differences are a bit bigger but only affect the variables
placed in the .bss section because that was defined as an OVERLAY in the
existing linker script.
For example:
$~ nm u-boot | grep tftp_prev_block
000ca0dc ? tftp_prev_block
$~ nm u-boot.new | grep tftp_prev_block
000e0a5c b tftp_prev_block -> The symbol is now placed into .bss

It's worth noting that since the efi regions are affected by the change, booting
with EFI is preferable while testing. Booting the kernel only should be enough
since the efi stub and the kernel proper do request boottime and runtime
services respectively.
Something along the lines of

virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r

will work for QEMU aarch64.

Tested platforms:
- QEMU aarch64
- Xilinx kv260 kria starter kit & zynq
- QEMU armv7
- STM32MP157C-DK2

[0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ 
compiler-generated")

Ilias Apalodimas (6):
   arm: baltos: remove custom linker script
   arm: clean up v7 and v8 linker scripts for bss_start/end
   arm: fix __efi_runtime_rel_start/end definitions
   arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end
   arm: fix __efi_runtime_start/end definitions
   arm: move image_copy_start/end to linker symbols

  arch/arm/cpu/armv8/u-boot-spl.lds |  14 +--
  arch/arm/cpu/armv8/u-boot.lds |  45 ++--
  arch/arm/cpu/u-boot.lds   |  74 +++--
  arch/arm/lib/sections.c   |  10 --
  arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  22 +---
  arch/arm/mach-zynq/u-boot.lds |  72 +++-
  board/qualcomm/dragonboard820c/u-boot.lds |  41 ++-
  board/vscom/baltos/u-boot.lds | 128 --
  include/asm-generic/sections.h|   3 +
  lib/efi_loader/efi_runtime.c  |   1 +
  10 files changed, 58 insertions(+), 352 deletions(-)
  delete mode 100644 

Re: [PATCH 01/10] mach-snapdragon: Add support for IPQ9574

[Krzysztof Kozlowski]

On 26/02/2024 11:07, Varadarajan Narayanan wrote:
> Signed-off-by: Varadarajan Narayanan 
> ---
> 
>  arch/arm/dts/Makefile |2 +
>  arch/arm/dts/ipq9574-default.dts  |  167 +++
>  arch/arm/dts/ipq9574-rdp433-mht-phy.dts   |  208 +++
>  arch/arm/dts/ipq9574.dtsi |  771 ++
>  .../include/mach/sysmap-ipq9574.h |  252 
>  arch/arm/mach-snapdragon/init_ipq9574.c   |   81 +
>  board/qualcomm/ipq9574/Kconfig|   15 +
>  board/qualcomm/ipq9574/Makefile   |4 +
>  board/qualcomm/ipq9574/board_init.c   |  326 
>  board/qualcomm/ipq9574/ipq9574.c  |  170 +++
>  board/qualcomm/ipq9574/ipq9574.h  |   75 +
>  board/qualcomm/ipq9574/u-boot-x32.lds |  250 
>  board/qualcomm/ipq9574/u-boot-x64.lds |  188 +++
>  drivers/clk/qcom/clock-ipq9574.c  | 1320 +
>  drivers/pinctrl/qcom/pinctrl-ipq9574.c|   77 +
>  include/configs/ipq9574.h |  111 ++
>  include/dt-bindings/clock/gcc-ipq9574.h   |  156 ++
>  include/dt-bindings/net/qti-ipqsoc.h  |   20 +
>  include/dt-bindings/pinctrl/pinctrl-ipqsoc.h  |   19 +
>  include/dt-bindings/reset/ipq9574-reset.h |   54 +
>  20 files changed, 4266 insertions(+)
>  create mode 100644 arch/arm/dts/ipq9574-default.dts
>  create mode 100644 arch/arm/dts/ipq9574-rdp433-mht-phy.dts
>  create mode 100644 arch/arm/dts/ipq9574.dtsi
>  create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-ipq9574.h
>  create mode 100644 arch/arm/mach-snapdragon/init_ipq9574.c
>  create mode 100644 board/qualcomm/ipq9574/Kconfig
>  create mode 100644 board/qualcomm/ipq9574/Makefile
>  create mode 100644 board/qualcomm/ipq9574/board_init.c
>  create mode 100644 board/qualcomm/ipq9574/ipq9574.c
>  create mode 100644 board/qualcomm/ipq9574/ipq9574.h
>  create mode 100644 board/qualcomm/ipq9574/u-boot-x32.lds
>  create mode 100644 board/qualcomm/ipq9574/u-boot-x64.lds
>  create mode 100644 drivers/clk/qcom/clock-ipq9574.c
>  create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq9574.c
>  create mode 100644 include/configs/ipq9574.h
>  create mode 100644 include/dt-bindings/clock/gcc-ipq9574.h
>  create mode 100644 include/dt-bindings/net/qti-ipqsoc.h
>  create mode 100644 include/dt-bindings/pinctrl/pinctrl-ipqsoc.h
>  create mode 100644 include/dt-bindings/reset/ipq9574-reset.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d9725030d5..8931dfa2aa 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1523,6 +1523,8 @@ dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
>  dtb-$(CONFIG_TARGET_CORSTONE1000) += corstone1000-mps3.dtb \
>   corstone1000-fvp.dtb
>  
> +dtb-$(CONFIG_TARGET_IPQ9574) += ipq9574-rdp433-mht-phy.dtb
> +
>  include $(srctree)/scripts/Makefile.dts
>  
>  targets += $(dtb-y)
> diff --git a/arch/arm/dts/ipq9574-default.dts 
> b/arch/arm/dts/ipq9574-default.dts
> new file mode 100644
> index 00..501c9492df
> --- /dev/null
> +++ b/arch/arm/dts/ipq9574-default.dts
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include "ipq9574.dtsi"
> +
> +/ {
> + config_name = "config-default";
> +
> + aliases {
> + console = _uart2_console;
> + uart2 = _uart3_additional;
> + sdhci = 
> + };
> +
> + soc: soc {
> + tlmm: pinctrl@100 {
> +
> + sdhci_pinmux: mmc {
> + pinconfig;
> + emmc_data {

No, please use upstream DTS.

You imported here a lot of vendor junk. There is no way this will pass
any System Ready tests if you hand over this DTB to Linux. Plus really,
that's ugly DTS to look at.

I am not a maintainer of DTS in U-Boot, so up to the folks here, but I
really recommend to NAK such DTS. It just re-adds all the issues we
fixed in upstream kernel!

I suggest using dts/upstream/qcom, but if you cannot then please import
kernel DTS.

Best regards,
Krzysztof

Re: [PATCH 2/8] dts: qcom: import device trees and bindings for SA8155P-ADP

[Krzysztof Kozlowski]

On 29/02/2024 15:21, Volodymyr Babchuk wrote:
> Add device tree bindings and actual device trees for SM8150 SoC and
> SA8155P-ADP board. Those files were imported from Linux kernel 6.8-rc5
> as is. In this configuration they will not work with U-Boot for couple
> reasons:
> 

Aren't you now duplicating dts/upstream/qcom?

https://lore.kernel.org/all/20240222093607.3085545-1-sumit.g...@linaro.org/

Best regards,
Krzysztof

Re: [PATCH v2] scripts: dtc-version: Don't show error messages

[Dragan Simic]

On 2024-02-15 15:21, Dragan Simic wrote:

On 2024-02-15 14:13, Tom Rini wrote:

On Wed, Feb 14, 2024 at 04:48:52AM +0100, Dragan Simic wrote:

On 2024-02-06 12:00, Dragan Simic wrote:
> Prevent the error messages produced by which(1), such as the one quoted
> below, from being visible in the build outputs.
>
> which: no dtc in (./scripts/dtc)
>
> This makes the build outputs look a tiny bit cleaner.

Just checking, is there something that prevents this patch from
becoming merged?


I'll probably take this once the merge window opens, thanks.


Great, thanks!


Just a small reminder about, possibly, picking this up for -next.

Re: [PATCH v4] cmd: add FDT setup for bootelf by flag

[Maxim M. Moskalets]

Hello Tom,

On 26.02.2024 21:35, Maxim Moskalets wrote:

From: Maxim Moskalets 

Added the ability to use FDT for ELF applications, required to run some
OS. To make FDT setup, you need to set the -d fdt_addr_r cmd option for
bootelf command.

Signed-off-by: Maxim Moskalets 

Cc: Tom Rini 
---
  cmd/elf.c | 27 ---
  1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/cmd/elf.c b/cmd/elf.c
index b7b9f506a5..2fa28448c0 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -38,6 +38,8 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, char 
* const[]),
  /* Interpreter command to boot an arbitrary ELF image from memory */
  int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
  {
+   struct bootm_headers img = {0};
+   unsigned long fdt_addr = 0; /* Address of the FDT */
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
char *sload = NULL;
@@ -46,13 +48,23 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
/* Consume 'bootelf' */
argc--; argv++;

-   /* Check for flag. */
+   /* Check for [-p|-s] flag. */
if (argc >= 1 && (argv[0][0] == '-' && \
(argv[0][1] == 'p' || argv[0][1] == 's'))) {
sload = argv[0];
/* Consume flag. */
argc--; argv++;
}
+
+   /* Check for [-d fdt_addr_r] option. */
+   if ((argc >= 2) && (argv[0][0] == '-') && (argv[0][1] == 'd')) {
+   if (strict_strtoul(argv[1], 16, _addr) != 0)
+   return CMD_RET_USAGE;
+   /* Consume option. */
+   argc -= 2;
+   argv += 2;
+   }
+
/* Check for address. */
if (argc >= 1 && strict_strtoul(argv[0], 16, ) != -EINVAL) {
/* Consume address */
@@ -68,6 +80,14 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
else
addr = load_elf_image_shdr(addr);
  
+	if (fdt_addr) {

+   printf("## Setting up FDT at 0x%08lx ...\n", fdt_addr);
+   flush();
+
+   if (image_setup_libfdt(, (void *)fdt_addr, NULL))
+   return 1;
+   }
+
if (!env_get_autostart())
return rcode;
  
@@ -298,9 +318,10 @@ int do_bootvx(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])

  U_BOOT_CMD(
bootelf, CONFIG_SYS_MAXARGS, 0, do_bootelf,
"Boot from an ELF image in memory",
-   "[-p|-s] [address]\n"
+   "[-p|-s] [-d fdt_addr_r] [address]\n"
"\t- load ELF image at [address] via program headers (-p)\n"
-   "\t  or via section headers (-s)"
+   "\t  or via section headers (-s)\n"
+   "\t- setup FDT image at [fdt_addr_r] (-d)"
  );
  
  U_BOOT_CMD(

Is it ok to merge?

Re: [PATCH v1 0/5] TEE: minor cleanup

[Tom Rini]

On Thu, Feb 29, 2024 at 07:25:10PM +, Peter Robinson wrote:
> On Thu, 29 Feb 2024 at 19:11, Igor Opaniuk  wrote:
> >
> > Hi Ilias,
> >
> > On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk 
> > wrote:
> >
> > > - Address some spelling errors and typos
> > > - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests
> > > - Remove common.h inclusion for drivers/tee
> > >
> > > Igor Opaniuk (5):
> > >   tee: optee: fix description in Kconfig
> > >   tee: sandbox: fix spelling errors
> > >   cmd: optee_rpmb: build cmd for sandbox
> > >   test: py: add optee_rpmb tests
> > >   tee: remove common.h inclusion
> > >
> > >  cmd/Kconfig|  4 +++-
> > >  drivers/tee/broadcom/chimp_optee.c |  2 +-
> > >  drivers/tee/optee/Kconfig  |  2 +-
> > >  drivers/tee/optee/core.c   |  1 -
> > >  drivers/tee/optee/i2c.c|  1 -
> > >  drivers/tee/optee/rpmb.c   |  1 -
> > >  drivers/tee/optee/supplicant.c |  2 +-
> > >  drivers/tee/sandbox.c  | 10 +-
> > >  drivers/tee/tee-uclass.c   |  1 -
> > >  test/py/tests/test_optee_rpmb.py   | 20 
> > >  10 files changed, 31 insertions(+), 13 deletions(-)
> > >  create mode 100644 test/py/tests/test_optee_rpmb.py
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > Are there currently any comments/objections that can prevent these cosmetic
> > changes from being applied? If there are - just let me know, thanks
> 
> Probably awaiting the next dev cycle, we're post RC3 now so it's
> mostly fixes landing ATM.

The -next branch is open too now tho, and I am picking up things out of
my queue. And other custodians can as well, time permitting :)

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 0/5] TEE: minor cleanup

[Peter Robinson]

On Thu, 29 Feb 2024 at 19:11, Igor Opaniuk  wrote:
>
> Hi Ilias,
>
> On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk 
> wrote:
>
> > - Address some spelling errors and typos
> > - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests
> > - Remove common.h inclusion for drivers/tee
> >
> > Igor Opaniuk (5):
> >   tee: optee: fix description in Kconfig
> >   tee: sandbox: fix spelling errors
> >   cmd: optee_rpmb: build cmd for sandbox
> >   test: py: add optee_rpmb tests
> >   tee: remove common.h inclusion
> >
> >  cmd/Kconfig|  4 +++-
> >  drivers/tee/broadcom/chimp_optee.c |  2 +-
> >  drivers/tee/optee/Kconfig  |  2 +-
> >  drivers/tee/optee/core.c   |  1 -
> >  drivers/tee/optee/i2c.c|  1 -
> >  drivers/tee/optee/rpmb.c   |  1 -
> >  drivers/tee/optee/supplicant.c |  2 +-
> >  drivers/tee/sandbox.c  | 10 +-
> >  drivers/tee/tee-uclass.c   |  1 -
> >  test/py/tests/test_optee_rpmb.py   | 20 
> >  10 files changed, 31 insertions(+), 13 deletions(-)
> >  create mode 100644 test/py/tests/test_optee_rpmb.py
> >
> > --
> > 2.34.1
> >
> >
> Are there currently any comments/objections that can prevent these cosmetic
> changes from being applied? If there are - just let me know, thanks

Probably awaiting the next dev cycle, we're post RC3 now so it's
mostly fixes landing ATM.

Re: [PATCH v1] cmd: md5sum: use hash_command

[Igor Opaniuk]

Hello Tom,

On Sun, Feb 11, 2024 at 7:56 PM Igor Opaniuk 
wrote:

> From: Igor Opaniuk 
>
> Drop old implementation and use hash_command() instead, as
> how it's currently done for crc32 and sha1sum cmds.
>
> Test:
> => md5sum 0x6000 0x200
> md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050
>
> Signed-off-by: Igor Opaniuk 
> ---
>
>  cmd/md5sum.c | 149 ---
>  1 file changed, 9 insertions(+), 140 deletions(-)
>
> diff --git a/cmd/md5sum.c b/cmd/md5sum.c
> index 0f0e1d3dd68..618265e8d50 100644
> --- a/cmd/md5sum.c
> +++ b/cmd/md5sum.c
> @@ -7,7 +7,6 @@
>   * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -15,158 +14,28 @@
>  #include 
>  #include 
>
> -/*
> - * Store the resulting sum to an address or variable
> - */
> -static void store_result(const u8 *sum, const char *dest)
> -{
> -   unsigned int i;
> -
> -   if (*dest == '*') {
> -   u8 *ptr;
> -
> -   ptr = (u8 *)hextoul(dest + 1, NULL);
> -   for (i = 0; i < 16; i++)
> -   *ptr++ = sum[i];
> -   } else {
> -   char str_output[33];
> -   char *str_ptr = str_output;
> -
> -   for (i = 0; i < 16; i++) {
> -   sprintf(str_ptr, "%02x", sum[i]);
> -   str_ptr += 2;
> -   }
> -   env_set(dest, str_output);
> -   }
> -}
> -
> -#ifdef CONFIG_MD5SUM_VERIFY
> -static int parse_verify_sum(char *verify_str, u8 *vsum)
> -{
> -   if (*verify_str == '*') {
> -   u8 *ptr;
> -
> -   ptr = (u8 *)hextoul(verify_str + 1, NULL);
> -   memcpy(vsum, ptr, 16);
> -   } else {
> -   unsigned int i;
> -   char *vsum_str;
> -
> -   if (strlen(verify_str) == 32)
> -   vsum_str = verify_str;
> -   else {
> -   vsum_str = env_get(verify_str);
> -   if (vsum_str == NULL || strlen(vsum_str) != 32)
> -   return 1;
> -   }
> -
> -   for (i = 0; i < 16; i++) {
> -   char *nullp = vsum_str + (i + 1) * 2;
> -   char end = *nullp;
> -
> -   *nullp = '\0';
> -   *(u8 *)(vsum + i) =
> -   hextoul(vsum_str + (i * 2), NULL);
> -   *nullp = end;
> -   }
> -   }
> -   return 0;
> -}
> -
> -int do_md5sum(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> +static int do_md5sum(struct cmd_tbl *cmdtp, int flag, int argc,
> +char *const argv[])
>  {
> -   ulong addr, len;
> -   unsigned int i;
> -   u8 output[16];
> -   u8 vsum[16];
> -   int verify = 0;
> +   int flags = HASH_FLAG_ENV;
> int ac;
> -   char * const *av;
> -   void *buf;
> +   char *const *av;
>
> if (argc < 3)
> return CMD_RET_USAGE;
>
> av = argv + 1;
> ac = argc - 1;
> -   if (strcmp(*av, "-v") == 0) {
> -   verify = 1;
> +   if (IS_ENABLED(CONFIG_MD5SUM_VERIFY) && strcmp(*av, "-v") == 0) {
> +   flags |= HASH_FLAG_VERIFY;
> av++;
> ac--;
> -   if (ac < 3)
> -   return CMD_RET_USAGE;
> }
>
> -   addr = hextoul(*av++, NULL);
> -   len = hextoul(*av++, NULL);
> -
> -   buf = map_sysmem(addr, len);
> -   md5_wd(buf, len, output, CHUNKSZ_MD5);
> -   unmap_sysmem(buf);
> -
> -   if (!verify) {
> -   printf("md5 for %08lx ... %08lx ==> ", addr, addr + len -
> 1);
> -   for (i = 0; i < 16; i++)
> -   printf("%02x", output[i]);
> -   printf("\n");
> -
> -   if (ac > 2)
> -   store_result(output, *av);
> -   } else {
> -   char *verify_str = *av++;
> -
> -   if (parse_verify_sum(verify_str, vsum)) {
> -   printf("ERROR: %s does not contain a valid md5
> sum\n",
> -   verify_str);
> -   return 1;
> -   }
> -   if (memcmp(output, vsum, 16) != 0) {
> -   printf("md5 for %08lx ... %08lx ==> ", addr,
> -   addr + len - 1);
> -   for (i = 0; i < 16; i++)
> -   printf("%02x", output[i]);
> -   printf(" != ");
> -   for (i = 0; i < 16; i++)
> -   printf("%02x", vsum[i]);
> -   printf(" ** ERROR **\n");
> -   return 1;
> -   }
> -   }
> -
> -   return 0;
> -}
> -#else
> -static int do_md5sum(struct cmd_tbl *cmdtp, int flag, int 

Re: [PATCH v1 0/5] TEE: minor cleanup

[Igor Opaniuk]

Hi Ilias,

On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk 
wrote:

> - Address some spelling errors and typos
> - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests
> - Remove common.h inclusion for drivers/tee
>
> Igor Opaniuk (5):
>   tee: optee: fix description in Kconfig
>   tee: sandbox: fix spelling errors
>   cmd: optee_rpmb: build cmd for sandbox
>   test: py: add optee_rpmb tests
>   tee: remove common.h inclusion
>
>  cmd/Kconfig|  4 +++-
>  drivers/tee/broadcom/chimp_optee.c |  2 +-
>  drivers/tee/optee/Kconfig  |  2 +-
>  drivers/tee/optee/core.c   |  1 -
>  drivers/tee/optee/i2c.c|  1 -
>  drivers/tee/optee/rpmb.c   |  1 -
>  drivers/tee/optee/supplicant.c |  2 +-
>  drivers/tee/sandbox.c  | 10 +-
>  drivers/tee/tee-uclass.c   |  1 -
>  test/py/tests/test_optee_rpmb.py   | 20 
>  10 files changed, 31 insertions(+), 13 deletions(-)
>  create mode 100644 test/py/tests/test_optee_rpmb.py
>
> --
> 2.34.1
>
>
Are there currently any comments/objections that can prevent these cosmetic
changes from being applied? If there are - just let me know, thanks

Regards,
Igor

-- 
Best regards - Atentamente - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
http://ua.linkedin.com/in/iopaniuk

Re: [PATCH v1] include: android_bootloader_message.h: sync with AOSP upstream

[Igor Opaniuk]

+CC Mattijs

On Mon, Feb 19, 2024 at 11:16 AM Igor Opaniuk 
wrote:

> This takes the latest changes from AOSP from [1][2] (as this
> header was split on two) with minimal changes (this could lead
> to warnings reported by checkpatch).
>
> Some local changes have been applied:
> 1. Enable static_assert() for defined structures to be sure
> that all of them have correct sizes.
> 2. Adjuste types in bootloader_control structure with bitfields
> (uint8_t -> uint16_t). It seems that gcc just doesn't like bitfields
> that cross the width of the type. Changing the type doesn't change
> the layout though.
> This addresses this gcc note:
> In file included from boot/android_ab.c:7:
> include/android_bootloader_message.h:230:1: note: offset of packed
> bit-field ‘merge_status’ has changed in GCC 4.4
>   230 | } __attribute__((packed));
>
> [1]
> https://android.googlesource.com/platform/bootable/recovery/+/main/bootloader_message/include/bootloader_message/bootloader_message.h
> [2]
> https://android.googlesource.com/platform/hardware/interfaces/+/main/boot/1.1/default/boot_control/include/private/boot_control_definition.h
>
> CC: Alex Deymo 
> CC: Sam Protsenko 
> CC: Eugeniu Rosca 
> CC: Simon Glass 
> Signed-off-by: Igor Opaniuk 
> ---
>
>  include/android_bootloader_message.h | 104 +++
>  1 file changed, 92 insertions(+), 12 deletions(-)
>
> diff --git a/include/android_bootloader_message.h
> b/include/android_bootloader_message.h
> index 286d7ab0f31..75198fc9dc2 100644
> --- a/include/android_bootloader_message.h
> +++ b/include/android_bootloader_message.h
> @@ -21,17 +21,22 @@
>   * stddef.h
>   */
>  #include 
> +#include 
>  #endif
>
>  // Spaces used by misc partition are as below:
>  // 0   - 2K For bootloader_message
>  // 2K  - 16KUsed by Vendor's bootloader (the 2K - 4K range may be
> optionally used
>  //  as bootloader_message_ab struct)
> -// 16K - 64KUsed by uncrypt and recovery to store wipe_package for
> A/B devices
> +// 16K - 32KUsed by uncrypt and recovery to store wipe_package for
> A/B devices
> +// 32K - 64KSystem space, used for miscellanious AOSP features. See
> below.
>  // Note that these offsets are admitted by bootloader,recovery and
> uncrypt, so they
>  // are not configurable without changing all of them.
>  static const size_t BOOTLOADER_MESSAGE_OFFSET_IN_MISC = 0;
> +static const size_t VENDOR_SPACE_OFFSET_IN_MISC = 2 * 1024;
>  static const size_t WIPE_PACKAGE_OFFSET_IN_MISC = 16 * 1024;
> +static const size_t SYSTEM_SPACE_OFFSET_IN_MISC = 32 * 1024;
> +static const size_t SYSTEM_SPACE_SIZE_IN_MISC = 32 * 1024;
>
>  /* Bootloader Message (2-KiB)
>   *
> @@ -81,24 +86,67 @@ struct bootloader_message {
>  char reserved[1184];
>  };
>
> +// Holds Virtual A/B merge status information. Current version is 1. New
> fields
> +// must be added to the end.
> +struct misc_virtual_ab_message {
> +  uint8_t version;
> +  uint32_t magic;
> +  uint8_t merge_status;  // IBootControl 1.1, MergeStatus enum.
> +  uint8_t source_slot;   // Slot number when merge_status was written.
> +  uint8_t reserved[57];
> +} __attribute__((packed));
> +
> +struct misc_memtag_message {
> +  uint8_t version;
> +  uint32_t magic; // magic string for treble compat
> +  uint32_t memtag_mode;
> +  uint8_t reserved[55];
> +} __attribute__((packed));
> +
> +struct misc_kcmdline_message {
> +  uint8_t version;
> +  uint32_t magic;
> +  uint64_t kcmdline_flags;
> +  uint8_t reserved[51];
> +} __attribute__((packed));
> +
> +#define MISC_VIRTUAL_AB_MESSAGE_VERSION 2
> +#define MISC_VIRTUAL_AB_MAGIC_HEADER 0x56740AB0
> +
> +#define MISC_MEMTAG_MESSAGE_VERSION 1
> +#define MISC_MEMTAG_MAGIC_HEADER 0x5afefe5a
> +#define MISC_MEMTAG_MODE_MEMTAG 0x1
> +#define MISC_MEMTAG_MODE_MEMTAG_ONCE 0x2
> +#define MISC_MEMTAG_MODE_MEMTAG_KERNEL 0x4
> +#define MISC_MEMTAG_MODE_MEMTAG_KERNEL_ONCE 0x8
> +#define MISC_MEMTAG_MODE_MEMTAG_OFF 0x10
> +// This is set when the state was overridden forcibly. This does not need
> to be
> +// interpreted by the bootloader but is only for bookkeeping purposes so
> +// userspace knows what to do when the override is undone.
> +// See system/extras/mtectrl in AOSP for more information.
> +#define MISC_MEMTAG_MODE_FORCED 0x20
> +
> +#define MISC_KCMDLINE_MESSAGE_VERSION 1
> +#define MISC_KCMDLINE_MAGIC_HEADER 0x6ab5110c
> +#define MISC_KCMDLINE_BINDER_RUST 0x1
>  /**
>   * We must be cautious when changing the bootloader_message struct size,
>   * because A/B-specific fields may end up with different offsets.
>   */
> -#ifndef __UBOOT__
> +
>  #if (__STDC_VERSION__ >= 201112L) || defined(__cplusplus)
>  static_assert(sizeof(struct bootloader_message) == 2048,
>"struct bootloader_message size changes, which may break
> A/B devices");
>  #endif
> -#endif /* __UBOOT__ */
>
>  /**
>   * The A/B-specific bootloader message structure (4-KiB).
>   *
>   * We separate A/B boot control metadata from the regular bootloader
>   * message 

Re: [PATCH v8 0/8] Handoff bloblist from previous boot stage

[Tom Rini]

On Sat, 03 Feb 2024 08:36:19 -0800, Raymond Mao wrote:

> This patch set adds/adapts a few bloblist APIs and implements Arm arch
> custom function to retrieve the bloblist (aka. Transfer List) from
> previous loader via boot arguments when BLOBLIST option is enabled and
> all boot arguments are compliant to the register conventions defined
> in the Firmware Handoff spec v0.9.
> 
> If an arch wishes to have different behaviors for loading bloblist
> from the previous boot stage, it is required to implement the custom
> function xferlist_from_boot_arg().
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH v10 14/15] configs: am69_sk: Add defconfig for AM69 SK board

[Andrew Davis]

On 2/23/24 2:21 PM, Apurva Nandan wrote:

From: Dasnavis Sabiya 

Add defconfig for AM69 SK A72 and R5 configuration.

This inlcudes and modifies the J784S4 EVM defconfigs:
j784s4_evm_a72_defconfig -> am69_sk_a72_defconfig
j784s4_evm_r5_defconfig -> am69_sk_r5_defconfig

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---


Reviewed-by: Andrew Davis 


  board/ti/j784s4/MAINTAINERS   |  2 ++
  configs/am69_sk_a72_defconfig |  9 +
  configs/am69_sk_r5_defconfig  | 10 ++
  3 files changed, 21 insertions(+)
  create mode 100644 configs/am69_sk_a72_defconfig
  create mode 100644 configs/am69_sk_r5_defconfig

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 2b6bff2f5be..46f4ba5da96 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -16,3 +16,5 @@ M:Apurva Nandan 
  S:Maintained
  F:arch/arm/dts/k3-am69-sk-u-boot.dtsi
  F:arch/arm/dts/k3-am69-r5-sk.dts
+F: configs/am69_sk_r5_defconfig
+F: configs/am69_sk_a72_defconfig
diff --git a/configs/am69_sk_a72_defconfig b/configs/am69_sk_a72_defconfig
new file mode 100644
index 000..452de887258
--- /dev/null
+++ b/configs/am69_sk_a72_defconfig
@@ -0,0 +1,9 @@
+#include 
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SOC_K3_J784S4=y
+CONFIG_TARGET_J784S4_A72_EVM=y
+
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am69-sk"
+CONFIG_OF_LIST="ti/k3-am69-sk"
diff --git a/configs/am69_sk_r5_defconfig b/configs/am69_sk_r5_defconfig
new file mode 100644
index 000..2186b9a0490
--- /dev/null
+++ b/configs/am69_sk_r5_defconfig
@@ -0,0 +1,10 @@
+#include 
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SOC_K3_J784S4=y
+CONFIG_TARGET_J784S4_R5_EVM=y
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-r5-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Frieder Schrempf]

Hi Michael,

On 29.02.24 16:45, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> I will ask dario to pick them up. I wil review too We have a bunch of
> patches to get in nand-next

Ok, thanks. But please wait until Bruce sends a new version based on the
Linux driver as I have asked him to do that.

Thanks
Frieder

> 
> Michael
> 
> On Thu, Feb 29, 2024 at 10:24 AM Bruce Sun  wrote:
>>
>> Thans for your advice, I will port the driver from linux driver(xtx.c)
>> later.
>>
>> On 2/29/2024 5:05 PM, Frieder Schrempf wrote:
>>> Hi Bruce,
>>>
>>> On 26.12.23 08:58, Bruce Suen wrote:
 [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
 Informationen, warum dies wichtig ist, finden Sie unter 
 https://aka.ms/LearnAboutSenderIdentification ]

 Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
 XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
 XT26Q04DX SPI NAND.

 These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
 ECC(8bit strength per 512bytes).

 Datasheet Links:
 - http://www.xtxtech.com/download/?AId=458
 - http://www.xtxtech.com/download/?AId=495

 Signed-off-by: Bruce Suen 
>>> Below you seem to have written a new driver based on gigadevice.c. Can
>>> you please instead port the existing Linux driver (xtx.c). This will
>>> help us to sync the drivers in the future if new chips will be added.
>>>
>>> Thanks
>>> Frieder
>>>
 ---
   drivers/mtd/nand/spi/Makefile |   1 +
   drivers/mtd/nand/spi/core.c   |   1 +
   drivers/mtd/nand/spi/xtx.c| 180 ++
   include/linux/mtd/spinand.h   |   1 +
   4 files changed, 183 insertions(+)
   create mode 100644 drivers/mtd/nand/spi/xtx.c

 diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
 index 3051de4f7e..e46cfed446 100644
 --- a/drivers/mtd/nand/spi/Makefile
 +++ b/drivers/mtd/nand/spi/Makefile
 @@ -1,4 +1,5 @@
   # SPDX-License-Identifier: GPL-2.0

   spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o 
 toshiba.o winbond.o
 +spinand-objs += xtx.o
   obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
 diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
 index 597b088ca7..0b4c067425 100644
 --- a/drivers/mtd/nand/spi/core.c
 +++ b/drivers/mtd/nand/spi/core.c
 @@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
 *spinand_manufacturers[] = {
  _spinand_manufacturer,
  _spinand_manufacturer,
  _spinand_manufacturer,
 +   _spinand_manufacturer,
   };

   static int spinand_manufacturer_match(struct spinand_device *spinand,
 diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
 new file mode 100644
 index 00..602861c77b
 --- /dev/null
 +++ b/drivers/mtd/nand/spi/xtx.c
 @@ -0,0 +1,180 @@
 +// SPDX-License-Identifier: GPL-2.0
 +/*
 + * Copyright (C) 2018 Stefan Roese 
 + *
 + * Derived from drivers/mtd/nand/spi/micron.c
 + *   Copyright (c) 2016-2017 Micron Technology, Inc.
 + */
 +
 +#ifndef __UBOOT__
 +#include 
 +#include 
 +#endif
 +#include 
 +#include 
 +
 +#define SPINAND_MFR_XTX0x0B
 +
 +#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
 +#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
 +#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
 +#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
 +#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
 +
 +static SPINAND_OP_VARIANTS(read_cache_variants,
 +   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
 +   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
 +   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
 +   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
 +   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
 +   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
 +
 +static SPINAND_OP_VARIANTS(write_cache_variants,
 +   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
 +   SPINAND_PROG_LOAD(true, 0, NULL, 0));
 +
 +static SPINAND_OP_VARIANTS(update_cache_variants,
 +   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
 +   SPINAND_PROG_LOAD(false, 0, NULL, 0));
 +
 +static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
 + struct mtd_oob_region *region)
 +{
 +   if (section)
 +   return -ERANGE;
 +
 +   region->offset = mtd->oobsize / 2;
 +   region->length = mtd->oobsize / 2;
 +
 +   return 0;
 +}
 +
 +static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
 +

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Michael Nazzareno Trimarchi]

Hi

I will ask dario to pick them up. I wil review too We have a bunch of
patches to get in nand-next

Michael

On Thu, Feb 29, 2024 at 10:24 AM Bruce Sun  wrote:
>
> Thans for your advice, I will port the driver from linux driver(xtx.c)
> later.
>
> On 2/29/2024 5:05 PM, Frieder Schrempf wrote:
> > Hi Bruce,
> >
> > On 26.12.23 08:58, Bruce Suen wrote:
> >> [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
> >> Informationen, warum dies wichtig ist, finden Sie unter 
> >> https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
> >> XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
> >> XT26Q04DX SPI NAND.
> >>
> >> These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
> >> ECC(8bit strength per 512bytes).
> >>
> >> Datasheet Links:
> >> - http://www.xtxtech.com/download/?AId=458
> >> - http://www.xtxtech.com/download/?AId=495
> >>
> >> Signed-off-by: Bruce Suen 
> > Below you seem to have written a new driver based on gigadevice.c. Can
> > you please instead port the existing Linux driver (xtx.c). This will
> > help us to sync the drivers in the future if new chips will be added.
> >
> > Thanks
> > Frieder
> >
> >> ---
> >>   drivers/mtd/nand/spi/Makefile |   1 +
> >>   drivers/mtd/nand/spi/core.c   |   1 +
> >>   drivers/mtd/nand/spi/xtx.c| 180 ++
> >>   include/linux/mtd/spinand.h   |   1 +
> >>   4 files changed, 183 insertions(+)
> >>   create mode 100644 drivers/mtd/nand/spi/xtx.c
> >>
> >> diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
> >> index 3051de4f7e..e46cfed446 100644
> >> --- a/drivers/mtd/nand/spi/Makefile
> >> +++ b/drivers/mtd/nand/spi/Makefile
> >> @@ -1,4 +1,5 @@
> >>   # SPDX-License-Identifier: GPL-2.0
> >>
> >>   spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o 
> >> toshiba.o winbond.o
> >> +spinand-objs += xtx.o
> >>   obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
> >> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> >> index 597b088ca7..0b4c067425 100644
> >> --- a/drivers/mtd/nand/spi/core.c
> >> +++ b/drivers/mtd/nand/spi/core.c
> >> @@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
> >> *spinand_manufacturers[] = {
> >>  _spinand_manufacturer,
> >>  _spinand_manufacturer,
> >>  _spinand_manufacturer,
> >> +   _spinand_manufacturer,
> >>   };
> >>
> >>   static int spinand_manufacturer_match(struct spinand_device *spinand,
> >> diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
> >> new file mode 100644
> >> index 00..602861c77b
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/spi/xtx.c
> >> @@ -0,0 +1,180 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2018 Stefan Roese 
> >> + *
> >> + * Derived from drivers/mtd/nand/spi/micron.c
> >> + *   Copyright (c) 2016-2017 Micron Technology, Inc.
> >> + */
> >> +
> >> +#ifndef __UBOOT__
> >> +#include 
> >> +#include 
> >> +#endif
> >> +#include 
> >> +#include 
> >> +
> >> +#define SPINAND_MFR_XTX0x0B
> >> +
> >> +#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
> >> +#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
> >> +#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
> >> +#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
> >> +#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
> >> +
> >> +static SPINAND_OP_VARIANTS(read_cache_variants,
> >> +   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
> >> +   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
> >> +   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
> >> +   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
> >> +   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
> >> +   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
> >> +
> >> +static SPINAND_OP_VARIANTS(write_cache_variants,
> >> +   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
> >> +   SPINAND_PROG_LOAD(true, 0, NULL, 0));
> >> +
> >> +static SPINAND_OP_VARIANTS(update_cache_variants,
> >> +   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
> >> +   SPINAND_PROG_LOAD(false, 0, NULL, 0));
> >> +
> >> +static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
> >> + struct mtd_oob_region *region)
> >> +{
> >> +   if (section)
> >> +   return -ERANGE;
> >> +
> >> +   region->offset = mtd->oobsize / 2;
> >> +   region->length = mtd->oobsize / 2;
> >> +
> >> +   return 0;
> >> +}
> >> +
> >> +static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
> >> +  struct mtd_oob_region *region)
> >> +{
> >> +   if (section)
> >> +   return -ERANGE;
> >> +
> >> +   region->offset = 2;
> >> +   region->length = mtd->oobsize / 2 - 2;
> 

Re: [PATCH v2 0/1] Fix booting kernels with ATAGS and extlinux

[Tom Rini]

On Thu, Feb 29, 2024 at 12:23:31PM +0200, Svyatoslav Ryhel wrote:
> чт, 25 січ. 2024 р. о 22:17 Svyatoslav Ryhel  пише:
> >
> > Currently, if boot with extlinux.conf and do not set the fdt
> > U-Boot will provide its own device tree. This behavior is
> > beneficial if the U-Boot device tree is in sync with Linux,
> > but it totally halts the booting of pre-dtb kernels (3.4 for
> > example) since it uses ATAGs. To fix this, pass `-` in the
> > fdt extlinux field as a signal that no tree should be used.
> >
> > Tested with 3.4 legacy kernel and mainline 6.7 kernel on
> > P895 (lg_x3 board).
> >
> > ---
> > Changes form v1
> >  - Added CONFIG guards
> >  - Clarified documentation
> > ---
> >
> > Svyatoslav Ryhel (1):
> >   boot: pxe_utils: skip fdt setup in case legacy kernel is booted
> >
> >  boot/pxe_utils.c   | 27 ++-
> >  doc/develop/distro.rst |  6 ++
> >  2 files changed, 28 insertions(+), 5 deletions(-)
> >
> > --
> > 2.40.1
> >
> 
> Hello, Tom! A month passed since v2 was pushed without any actions,
> should I re-send it or maybe some adjustments are needed?

I should pick it up at some point for -next, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] board: rockchip: add Rockchip Toybrick TB-RK3588X board

[Tom Rini]

On Thu, Feb 29, 2024 at 08:04:16PM +0800, Elon Zhang wrote:

> TB-RK3588X board is a Rockchip Toybrick RK3588 based development board.
> 
> Specification:
>   Rockchip Rk3588 SoC
>   4x ARM Cortex-A76, 4x ARM Cortex-A55
>   8/16GB Memory LPDDR4x
>   Mali G610MC4 GPU
>   2× MIPI-CSI0 Connector
>   1x 2Lanes PCIe3.0 Connector
>   1x SATA3.0 Connector
>   32GB eMMC Module
>   2x USB 2.0, 2x USB 3.0
>   1x HDMI Output, 1x HDMI Input
>   2x Ethernet Port
> 
> Functions work normally:
>   [1] USB2.0 Host
>   [2] Ethernet0 with PHY RTL8211F
> 
> More information can be obtained from the following websites:
>   [1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html
>   [2] http://t.rock-chips.com/
> 
> Kernel commits:
>   8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for 
> TB-RK3588X board")
>   7140387ff49d ("dt-bindings: arm: rockchip: Add Toybrick TB-RK3588X")
> 
> Signed-off-by: Elon Zhang 
[snip]
> +config BOARD_SPECIFIC_OPTIONS # dummy
> + def_bool y

Is this just a copy/paste thing that keeps getting re-used? Ideally,
BOARD_SPECIFIC_OPTIONS shouldn't exist and it's either a select/imply at
the TARGET_... level or something in the defconfig. But having an empty
one is very confusing.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/8] clk: qcom: add support for power domains uclass

[Dan Carpenter]

On Thu, Feb 29, 2024 at 02:21:08PM +, Volodymyr Babchuk wrote:
> @@ -223,7 +229,7 @@ U_BOOT_DRIVER(qcom_clk) = {
>  int qcom_cc_bind(struct udevice *parent)
>  {
>   struct msm_clk_data *data = (struct msm_clk_data 
> *)dev_get_driver_data(parent);
> - struct udevice *clkdev, *rstdev;
> + struct udevice *clkdev, *rstdev, *pwrdev;
>   struct driver *drv;
>   int ret;
>  
> @@ -253,6 +259,20 @@ int qcom_cc_bind(struct udevice *parent)
>   if (ret)
>   device_unbind(clkdev);

Change this to:

if (ret)
goto unbind_clkdev;

>  
> + if (!data->power_domains)
> + return ret;


Then this becomes:

if (!data->power_domains)
return 0;

> +
> + /* Get a handle to the common power domain handler */
> + drv = lists_driver_lookup_name("qcom_power");
> + if (!drv)
> + return -ENOENT;

if (!drv) {
ret = -ENOENT;
goto unbind_rstdev;
}

> +
> + /* Register the power domain controller */
> + ret = device_bind_with_driver_data(parent, drv, "qcom_power", 
> (ulong)data,
> +dev_ofnode(parent), );
> + if (ret)
> + device_unbind(pwrdev);

pwrdev wasn't bound.  Free the last *successful* allocation which was
still rstdev.

if (ret)
goto unbind_rstdev;

return 0;

unbind_rstdev:
device_unbind(rstdev);
unbind_clkdev:
device_unbind(clkdev);

return ret;

> +
>   return ret;
>  }
>  

regards,
dan carpenter

[PATCH 0/8] Add support for Qualcomm SA8155-ADP board

[Volodymyr Babchuk]

This patch series adds support for Qualcomm SA8155-ADP development
board. Main motivation for this series is to allow running
virtualization software on this board and U-Boot is a good way to
break Qualcomm's boot chain at EL2 with more convenient ways for
uploading and running the code. With this patches applied it is
possible to upload and run Xen on this board. KVM probably should work
too.

I added myself as a maintainer for this board, but my abilities to
maintain it are quite limited as I have no access to Qualcomm
documentation. I used mostly Linux drivers as the source for
device-specific information, like register addresses and offsets.
If anyone wants to maintain this, I will gladly agree.


Volodymyr Babchuk (8):
  clk: qcom: clear div mask before assigning new divider
  dts: qcom: import device trees and bindings for SA8155P-ADP
  net: dw_eth_qos: add support for Qualcomm SM8150 SoC
  clk: qcom: add support for power domains uclass
  clk: qcom: add driver for SM8150 SoC
  pinctr: qcom: pass pin number to get_function_mux callback
  pinctrl: qcom: add driver for SM8150 SoC
  board: add support for Qualcomm SA8155P-ADP board

 arch/arm/dts/pmm8155au_1.dtsi |  135 +
 arch/arm/dts/pmm8155au_2.dtsi |  108 +
 arch/arm/dts/sa8155p-adp-u-boot.dtsi  |   30 +
 arch/arm/dts/sa8155p-adp.dts  |  606 ++
 arch/arm/dts/sa8155p.dtsi |   40 +
 arch/arm/dts/sm8150.dtsi  | 5293 +
 arch/arm/mach-snapdragon/Kconfig  |   14 +
 arch/arm/mach-snapdragon/Makefile |2 +
 arch/arm/mach-snapdragon/init_sa8155p.c   |   30 +
 arch/arm/mach-snapdragon/sysmap-sm8150.c  |   31 +
 board/qualcomm/sa8155p-adp/Kconfig|   12 +
 board/qualcomm/sa8155p-adp/MAINTAINERS|6 +
 configs/sa8155p_adp_defconfig |   33 +
 doc/board/qualcomm/index.rst  |1 +
 doc/board/qualcomm/sa8155p-adp.rst|   94 +
 drivers/clk/qcom/Kconfig  |8 +
 drivers/clk/qcom/Makefile |1 +
 drivers/clk/qcom/clock-qcom.c |   96 +-
 drivers/clk/qcom/clock-qcom.h |7 +
 drivers/clk/qcom/clock-sm8150.c   |  234 +
 drivers/net/dwc_eth_qos.c |4 +
 drivers/net/dwc_eth_qos.h |2 +
 drivers/net/dwc_eth_qos_qcom.c|   47 +-
 drivers/pinctrl/qcom/Kconfig  |7 +
 drivers/pinctrl/qcom/Makefile |1 +
 drivers/pinctrl/qcom/pinctrl-apq8016.c|3 +-
 drivers/pinctrl/qcom/pinctrl-apq8096.c|3 +-
 drivers/pinctrl/qcom/pinctrl-ipq4019.c|3 +-
 drivers/pinctrl/qcom/pinctrl-qcom.c   |4 +-
 drivers/pinctrl/qcom/pinctrl-qcom.h   |3 +-
 drivers/pinctrl/qcom/pinctrl-qcs404.c |3 +-
 drivers/pinctrl/qcom/pinctrl-sdm845.c |3 +-
 drivers/pinctrl/qcom/pinctrl-sm8150.c |  589 ++
 include/configs/sa8155p_adp.h |   25 +
 .../dt-bindings/clock/qcom,dispcc-sm8150.h|   76 +
 include/dt-bindings/clock/qcom,gcc-sm8150.h   |  252 +
 include/dt-bindings/clock/qcom,gpucc-sm8150.h |   33 +
 include/dt-bindings/clock/qcom,rpmh.h |   37 +
 include/dt-bindings/dma/qcom-gpi.h|   11 +
 include/dt-bindings/firmware/qcom,scm.h   |   39 +
 include/dt-bindings/iio/qcom,spmi-vadc.h  |  303 +
 .../dt-bindings/interconnect/qcom,osm-l3.h|   15 +
 .../dt-bindings/interconnect/qcom,sm8150.h|  159 +
 include/dt-bindings/phy/phy-qcom-qmp.h|   20 +
 include/dt-bindings/power/qcom-rpmpd.h|  412 ++
 .../regulator/qcom,rpmh-regulator.h   |   36 +
 include/dt-bindings/soc/qcom,rpmh-rsc.h   |   14 +
 47 files changed, 8866 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm/dts/pmm8155au_1.dtsi
 create mode 100644 arch/arm/dts/pmm8155au_2.dtsi
 create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
 create mode 100644 arch/arm/dts/sa8155p-adp.dts
 create mode 100644 arch/arm/dts/sa8155p.dtsi
 create mode 100644 arch/arm/dts/sm8150.dtsi
 create mode 100644 arch/arm/mach-snapdragon/init_sa8155p.c
 create mode 100644 arch/arm/mach-snapdragon/sysmap-sm8150.c
 create mode 100644 board/qualcomm/sa8155p-adp/Kconfig
 create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
 create mode 100644 configs/sa8155p_adp_defconfig
 create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
 create mode 100644 drivers/clk/qcom/clock-sm8150.c
 create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8150.c
 create mode 100644 include/configs/sa8155p_adp.h
 create mode 100644 include/dt-bindings/clock/qcom,dispcc-sm8150.h
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8150.h
 create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8150.h
 create mode 100644 include/dt-bindings/clock/qcom,rpmh.h
 create mode 100644 include/dt-bindings/dma/qcom-gpi.h
 create mode 100644 

[PATCH 8/8] board: add support for Qualcomm SA8155P-ADP board

[Volodymyr Babchuk]

SA8155P Automotive Development Platform is Qualcomm SA8155-based board
for developers. The nice thing that it has unlocked loaders with test
keys support, which means that U-Boot for this platform can be
launched at earlier stages.

This patch adds basic board support with only serial port and
networking operation. I am using U-Boot to ease up Xen porting onto
this board, so I am mostly interesting in booting U-Boot in EL2. But
more conventional setup with Android boot image is supported as well.

Signed-off-by: Volodymyr Babchuk 

---

 arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 
 arch/arm/mach-snapdragon/Kconfig | 14 
 arch/arm/mach-snapdragon/Makefile|  2 +
 arch/arm/mach-snapdragon/init_sa8155p.c  | 30 
 arch/arm/mach-snapdragon/sysmap-sm8150.c | 31 
 board/qualcomm/sa8155p-adp/Kconfig   | 12 +++
 board/qualcomm/sa8155p-adp/MAINTAINERS   |  6 ++
 configs/sa8155p_adp_defconfig| 33 +
 doc/board/qualcomm/index.rst |  1 +
 doc/board/qualcomm/sa8155p-adp.rst   | 94 
 include/configs/sa8155p_adp.h| 25 +++
 11 files changed, 278 insertions(+)
 create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
 create mode 100644 arch/arm/mach-snapdragon/init_sa8155p.c
 create mode 100644 arch/arm/mach-snapdragon/sysmap-sm8150.c
 create mode 100644 board/qualcomm/sa8155p-adp/Kconfig
 create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
 create mode 100644 configs/sa8155p_adp_defconfig
 create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
 create mode 100644 include/configs/sa8155p_adp.h

diff --git a/arch/arm/dts/sa8155p-adp-u-boot.dtsi 
b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
new file mode 100644
index 00..4484ea2734
--- /dev/null
+++ b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Qualcomm SA8155P-ADP device tree fixups for U-BOot
+ *
+ * Volodymyr Babchuk 
+ * Copyright (c) 2024 EPAM Systems.
+ */
+
+/ {
+   /* Populate memory node with actual memory configuration */
+   memory@8000 {
+   reg = <0x00 0x8000 0x00 0x3990> ,
+ <0x02 0x00x1  0x7fd0>,
+ <0x00 0xC000 0x1  0x4000>;
+   };
+};
+
+ {
+   /* Ethernet driver tries to find reset by name */
+   reset-names = "emac";
+};
+
+ {
+   /* U-Boot pinctrl driver does not understand multiple tiles */
+   reg = <0x0 0x0300 0x0 0x100>;
+   /delete-property/ reg-names;
+
+   /* U-Boot ethernet driver wants to drive reset as GPIO */
+   /delete-node/ phy-reset-pins;
+};
diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index ad66710819..6431b6eca0 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -19,6 +19,12 @@ config SDM845
imply PINCTRL_QCOM_SDM845
imply BUTTON_QCOM_PMIC
 
+config SM8150
+   bool "Qualcomm Snapdragon 855 SoC"
+   select LINUX_KERNEL_IMAGE_HEADER
+   imply CLK_QCOM_SM8150
+   imply PINCTRL_QCOM_SDM8150
+
 config LNX_KRNL_IMG_TEXT_OFFSET_BASE
default 0x8000
 
@@ -90,6 +96,13 @@ config TARGET_QCS404EVB
  - 1GiB RAM
  - 8GiB eMMC, uSD slot
 
+config TARGET_SA8155P_ADP
+   bool "SA8155 Automotive Development Platform"
+   help
+ Support for Lantronix/Qualcomm SA8155P Automotive Development Platform
+ based on Snapdragon SA8155P
+   select SM8150
+
 endchoice
 
 source "board/qualcomm/dragonboard410c/Kconfig"
@@ -97,5 +110,6 @@ source "board/qualcomm/dragonboard820c/Kconfig"
 source "board/qualcomm/dragonboard845c/Kconfig"
 source "board/samsung/starqltechn/Kconfig"
 source "board/qualcomm/qcs404-evb/Kconfig"
+source "board/qualcomm/sa8155p-adp/Kconfig"
 
 endif
diff --git a/arch/arm/mach-snapdragon/Makefile 
b/arch/arm/mach-snapdragon/Makefile
index 3a3a297c17..ff2887e384 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -4,8 +4,10 @@
 
 obj-$(CONFIG_SDM845) += sysmap-sdm845.o
 obj-$(CONFIG_SDM845) += init_sdm845.o
+obj-$(CONFIG_SM8150) += sysmap-sm8150.o
 obj-$(CONFIG_TARGET_DRAGONBOARD820C) += sysmap-apq8096.o
 obj-$(CONFIG_TARGET_DRAGONBOARD410C) += sysmap-apq8016.o
 obj-y += misc.o
 obj-y += dram.o
 obj-$(CONFIG_TARGET_QCS404EVB) += sysmap-qcs404.o
+obj-$(CONFIG_TARGET_SA8155P_ADP) += init_sa8155p.o
diff --git a/arch/arm/mach-snapdragon/init_sa8155p.c 
b/arch/arm/mach-snapdragon/init_sa8155p.c
new file mode 100644
index 00..64dd07ae92
--- /dev/null
+++ b/arch/arm/mach-snapdragon/init_sa8155p.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Qualcomm SM8150 initialization procedures
+ *
+ * Volodymyr Babchuk 
+ * Copyright (c) 2024 EPAM Systems.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();
+}
+
+void 

[PATCH 4/8] clk: qcom: add support for power domains uclass

[Volodymyr Babchuk]

Now sub-drivers for particular SoCs can register them as power domain
drivers. This is needed for upcoming SM8150 support, because it needs
to power up the Ethernet module.

Signed-off-by: Volodymyr Babchuk 
---

 drivers/clk/qcom/clock-qcom.c | 93 ++-
 drivers/clk/qcom/clock-qcom.h |  6 +++
 2 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
index 729d190c54..986b8e4da4 100644
--- a/drivers/clk/qcom/clock-qcom.c
+++ b/drivers/clk/qcom/clock-qcom.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clock-qcom.h"
 
@@ -30,6 +31,11 @@
 #define CBCR_BRANCH_ENABLE_BIT  BIT(0)
 #define CBCR_BRANCH_OFF_BIT BIT(31)
 
+#define GDSC_POWER_UP_COMPLETE BIT(16)
+#define GDSC_POWER_DOWN_COMPLETE   BIT(15)
+#define CFG_GDSCR_OFFSET   0x4
+#define PWR_ON_MASKBIT(31)
+
 /* Enable clock controlled by CBC soft macro */
 void clk_enable_cbc(phys_addr_t cbcr)
 {
@@ -223,7 +229,7 @@ U_BOOT_DRIVER(qcom_clk) = {
 int qcom_cc_bind(struct udevice *parent)
 {
struct msm_clk_data *data = (struct msm_clk_data 
*)dev_get_driver_data(parent);
-   struct udevice *clkdev, *rstdev;
+   struct udevice *clkdev, *rstdev, *pwrdev;
struct driver *drv;
int ret;
 
@@ -253,6 +259,20 @@ int qcom_cc_bind(struct udevice *parent)
if (ret)
device_unbind(clkdev);
 
+   if (!data->power_domains)
+   return ret;
+
+   /* Get a handle to the common power domain handler */
+   drv = lists_driver_lookup_name("qcom_power");
+   if (!drv)
+   return -ENOENT;
+
+   /* Register the power domain controller */
+   ret = device_bind_with_driver_data(parent, drv, "qcom_power", 
(ulong)data,
+  dev_ofnode(parent), );
+   if (ret)
+   device_unbind(pwrdev);
+
return ret;
 }
 
@@ -306,3 +326,74 @@ U_BOOT_DRIVER(qcom_reset) = {
.ops = _reset_ops,
.probe = qcom_reset_probe,
 };
+
+static int qcom_power_set(struct power_domain *pwr, bool on)
+{
+   struct msm_clk_data *data = (struct msm_clk_data 
*)dev_get_driver_data(pwr->dev);
+   void __iomem *base = dev_get_priv(pwr->dev);
+   const struct qcom_power_map *map;
+   u32 value;
+
+   if (pwr->id >= data->num_power_domains)
+   return -ENODEV;
+
+   map = >power_domains[pwr->id];
+
+   if (!map->reg)
+   return -ENODEV;
+
+   value = readl(base + map->reg);
+
+   if (on)
+   value &= ~BIT(0);
+   else
+   value |= BIT(0);
+
+   writel(value, base + map->reg);
+
+   /* Wait for power on */
+   while (true) {
+   value = readl(base + map->reg + CFG_GDSCR_OFFSET);
+   if (on) {
+   if ((value & GDSC_POWER_UP_COMPLETE) ||
+   (value & PWR_ON_MASK))
+   return 0;
+   } else {
+   if (value & GDSC_POWER_DOWN_COMPLETE ||
+   !(value & PWR_ON_MASK))
+   return 0;
+   }
+   }
+
+   return 0;
+}
+
+static int qcom_power_on(struct power_domain *pwr)
+{
+   return qcom_power_set(pwr, true);
+}
+
+static int qcom_power_off(struct power_domain *pwr)
+{
+   return qcom_power_set(pwr, false);
+}
+
+static const struct power_domain_ops qcom_power_ops = {
+   .on = qcom_power_on,
+   .off = qcom_power_off,
+};
+
+static int qcom_power_probe(struct udevice *dev)
+{
+   /* Set our priv pointer to the base address */
+   dev_set_priv(dev, (void *)dev_read_addr(dev));
+
+   return 0;
+}
+
+U_BOOT_DRIVER(qcom_power) = {
+   .name = "qcom_power",
+   .id = UCLASS_POWER_DOMAIN,
+   .ops = _power_ops,
+   .probe = qcom_power_probe,
+};
diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
index 01088c1901..12a1eaec2b 100644
--- a/drivers/clk/qcom/clock-qcom.h
+++ b/drivers/clk/qcom/clock-qcom.h
@@ -59,9 +59,15 @@ struct qcom_reset_map {
u8 bit;
 };
 
+struct qcom_power_map {
+   unsigned int reg;
+};
+
 struct clk;
 
 struct msm_clk_data {
+   const struct qcom_power_map *power_domains;
+   unsigned long   num_power_domains;
const struct qcom_reset_map *resets;
unsigned long   num_resets;
const struct gate_clk   *clks;
-- 
2.43.0

[PATCH 3/8] net: dw_eth_qos: add support for Qualcomm SM8150 SoC

[Volodymyr Babchuk]

Add support for Qualcomm SM8150 SoC to the EQOS driver. SM8150 has two
main differences from already supported QCS404: it has another RGMII
configuration registers set and it does require RGMII loopback to
be disabled.

To support different variants of QCOM SoC we had to add two new fields
to the eqos_priv struct: eqos_qcom_rgmii_regs and
qcom_enable_loopback.

Signed-off-by: Volodymyr Babchuk 
---

 drivers/net/dwc_eth_qos.c  |  4 +++
 drivers/net/dwc_eth_qos.h  |  2 ++
 drivers/net/dwc_eth_qos_qcom.c | 47 +++---
 3 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 9b3bce1dc8..882b854697 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1700,6 +1700,10 @@ static const struct udevice_id eqos_ids[] = {
.compatible = "qcom,qcs404-ethqos",
.data = (ulong)_qcom_config
},
+   {
+   .compatible = "qcom,sm8150-ethqos",
+   .data = (ulong)_qcom_config
+   },
 #endif
 #if IS_ENABLED(CONFIG_DWC_ETH_QOS_STARFIVE)
{
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index e3222e1e17..216e1afe53 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -255,6 +255,7 @@ struct eqos_priv {
struct eqos_dma_regs *dma_regs;
struct eqos_tegra186_regs *tegra186_regs;
void *eqos_qcom_rgmii_regs;
+   struct dwmac_rgmii_regs *eqos_qcom_por;
struct reset_ctl reset_ctl;
struct gpio_desc phy_reset_gpio;
struct clk clk_master_bus;
@@ -277,6 +278,7 @@ struct eqos_priv {
bool started;
bool reg_access_ok;
bool clk_ck_enabled;
+   bool qcom_enable_loopback;
unsigned int tx_fifo_sz, rx_fifo_sz;
u32 reset_delays[3];
 };
diff --git a/drivers/net/dwc_eth_qos_qcom.c b/drivers/net/dwc_eth_qos_qcom.c
index 8178138fc6..e9592ff686 100644
--- a/drivers/net/dwc_eth_qos_qcom.c
+++ b/drivers/net/dwc_eth_qos_qcom.c
@@ -95,6 +95,15 @@ static struct dwmac_rgmii_regs emac_v2_3_0_por = {
.io_macro_config2 = 0x2060
 };
 
+static struct dwmac_rgmii_regs emac_v2_1_0_por = {
+   .io_macro_config = 0x40C01343,
+   .sdcc_hc_dll_config = 0x2004642C,
+   .sdcc_hc_ddr_config = 0x,
+   .sdcc_hc_dll_config2 = 0x0020,
+   .sdcc_usr_ctl = 0x00010800,
+   .io_macro_config2 = 0x2060
+};
+
 static void ethqos_set_func_clk_en(struct dwmac_rgmii_regs *regs)
 {
setbits_le32(>io_macro_config, RGMII_CONFIG_FUNC_CLK_EN);
@@ -172,6 +181,8 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
   struct dwmac_rgmii_regs *regs,
   unsigned long speed)
 {
+   struct eqos_priv *eqos = dev_get_priv(dev);
+
/* Disable loopback mode */
clrbits_le32(>io_macro_config2,
 RGMII_CONFIG2_TX_TO_RX_LOOPBACK_EN);
@@ -202,7 +213,9 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
SDCC_DDR_CONFIG_PRG_RCLK_DLY, 57);
setbits_le32(>sdcc_hc_ddr_config, 
SDCC_DDR_CONFIG_PRG_DLY_EN);
 
-   setbits_le32(>io_macro_config, RGMII_CONFIG_LOOPBACK_EN);
+   if (eqos->qcom_enable_loopback)
+   setbits_le32(>io_macro_config,
+RGMII_CONFIG_LOOPBACK_EN);
break;
 
case SPEED_100:
@@ -233,7 +246,9 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
setbits_le32(>sdcc_hc_ddr_config,
 SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN);
 
-   setbits_le32(>io_macro_config, RGMII_CONFIG_LOOPBACK_EN);
+   if (eqos->qcom_enable_loopback)
+   setbits_le32(>io_macro_config,
+RGMII_CONFIG_LOOPBACK_EN);
break;
 
case SPEED_10:
@@ -265,7 +280,9 @@ static int ethqos_rgmii_macro_init(struct udevice *dev,
setbits_le32(>sdcc_hc_ddr_config,
 SDCC_DDR_CONFIG_EXT_PRG_RCLK_DLY_EN);
 
-   setbits_le32(>io_macro_config, RGMII_CONFIG_LOOPBACK_EN);
+   if (eqos->qcom_enable_loopback)
+   setbits_le32(>io_macro_config,
+RGMII_CONFIG_LOOPBACK_EN);
break;
 
default:
@@ -281,14 +298,15 @@ static int ethqos_configure(struct udevice *dev,
unsigned long speed)
 {
unsigned int retry = 1000;
+   struct eqos_priv *eqos = dev_get_priv(dev);
 
/* Reset to POR values and enable clk */
-   writel(emac_v2_3_0_por.io_macro_config, >io_macro_config);
-   writel(emac_v2_3_0_por.sdcc_hc_dll_config, >sdcc_hc_dll_config);
-   writel(emac_v2_3_0_por.sdcc_hc_ddr_config, >sdcc_hc_ddr_config);
-   writel(emac_v2_3_0_por.sdcc_hc_dll_config2, 

[PATCH 5/8] clk: qcom: add driver for SM8150 SoC

[Volodymyr Babchuk]

Add clock, reset and power domain driver for SM8150. Driver code is
based on the similar U-Boot drivers. All constants are taken from the
corresponding Linux driver.

This driver supports clock rate setting only for the debug UART and
RGMII/Ethernet modules, because this is all I can test right now.

Signed-off-by: Volodymyr Babchuk 
---

 drivers/clk/qcom/Kconfig|   8 ++
 drivers/clk/qcom/Makefile   |   1 +
 drivers/clk/qcom/clock-qcom.h   |   1 +
 drivers/clk/qcom/clock-sm8150.c | 234 
 4 files changed, 244 insertions(+)
 create mode 100644 drivers/clk/qcom/clock-sm8150.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0df0d1881a..18ccf6a45e 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
  on the Snapdragon 845 SoC. This driver supports the clocks
  and resets exposed by the GCC hardware block.
 
+config CLK_QCOM_SM8150
+   bool "Qualcomm SM8150 GCC"
+   select CLK_QCOM
+   help
+ Say Y here to enable support for the Global Clock Controller
+ on the Snapdragon 8150 SoC. This driver supports the clocks
+ and resets exposed by the GCC hardware block.
+
 endmenu
 
 endif
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index cb179fdac5..12c09ba19e 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
 obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
 obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
 obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
+obj-$(CONFIG_CLK_QCOM_SM8150) += clock-sm8150.o
diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
index 12a1eaec2b..41107df216 100644
--- a/drivers/clk/qcom/clock-qcom.h
+++ b/drivers/clk/qcom/clock-qcom.h
@@ -9,6 +9,7 @@
 
 #define CFG_CLK_SRC_CXO   (0 << 8)
 #define CFG_CLK_SRC_GPLL0 (1 << 8)
+#define CFG_CLK_SRC_GPLL7_MAIN (3 << 8)
 #define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
 #define CFG_CLK_SRC_MASK  (7 << 8)
 
diff --git a/drivers/clk/qcom/clock-sm8150.c b/drivers/clk/qcom/clock-sm8150.c
new file mode 100644
index 00..e23dbccdd3
--- /dev/null
+++ b/drivers/clk/qcom/clock-sm8150.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Clock drivers for Qualcomm SM8150
+ *
+ * Volodymyr Babchuk 
+ * Copyright (c) 2024 EPAM Systems.
+ *
+ * Based on U-Boot driver for SDM845. Constants are taken from the Linux 
driver.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clock-qcom.h"
+
+static struct pll_vote_clk gpll7_vote_clk = {
+   .status = 0x1a000,
+   .status_bit = BIT(31),
+   .ena_vote = 0x52000,
+   .vote_bit = BIT(7),
+};
+
+static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
+   F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
+   F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
+   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+   F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
+   F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
+   F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
+   F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
+   F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
+   F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
+   F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
+   F(10240, CFG_CLK_SRC_GPLL0_EVEN, 1, 128, 375),
+   F(11200, CFG_CLK_SRC_GPLL0_EVEN, 1, 28, 75),
+   F(117964800, CFG_CLK_SRC_GPLL0_EVEN, 1, 6144, 15625),
+   F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
+   F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
+   { }
+};
+
+static const struct freq_tbl ftbl_gcc_emac_rgmii_clk_src[] = {
+   F(250, CFG_CLK_SRC_CXO, 1, 25, 192),
+   F(500, CFG_CLK_SRC_CXO, 1, 25, 96),
+   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+   F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
+   F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
+   F(12500, CFG_CLK_SRC_GPLL7_MAIN, 4, 0, 0),
+   F(25000, CFG_CLK_SRC_GPLL7_MAIN, 2, 0, 0),
+   { }
+};
+
+static const struct bcr_regs uart2_regs = {
+   .cfg_rcgr = 0x1814C,
+   .cmd_rcgr = 0x18148,
+   .M = 0x18150,
+   .N = 0x18154,
+   .D = 0x18158,
+};
+
+static const struct bcr_regs rgmii_regs = {
+   .cfg_rcgr = 0x6020,
+   .cmd_rcgr = 0x601C,
+   .M = 0x6024,
+   .N = 0x6028,
+   .D = 0x602C,
+};
+
+static ulong sm8150_clk_set_rate(struct clk *clk, ulong rate)
+{
+   struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+   const struct freq_tbl *freq;
+
+   switch (clk->id) {
+   case GCC_QUPV3_WRAP1_S4_CLK: /* UART2 aka debug-uart */
+   freq = qcom_find_freq(ftbl_gcc_qupv3_wrap0_s0_clk_src, rate);
+   clk_rcg_set_rate_mnd(priv->base, _regs,
+freq->pre_div, freq->m, freq->n, 

[PATCH 7/8] pinctrl: qcom: add driver for SM8150 SoC

[Volodymyr Babchuk]

Add pinctrl and GPIO driver for SM8150. Driver code is based on the
similar U-Boot drivers. All constants are taken from the corresponding
Linux driver. This drivers differs from the similar U-Boot drivers,
because SM8150 SoC have different function IDs for the same functions
on different pins.

Signed-off-by: Volodymyr Babchuk 
---

 drivers/pinctrl/qcom/Kconfig  |   7 +
 drivers/pinctrl/qcom/Makefile |   1 +
 drivers/pinctrl/qcom/pinctrl-sm8150.c | 589 ++
 3 files changed, 597 insertions(+)
 create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8150.c

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 2fe6398147..290cefca47 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -41,6 +41,13 @@ config PINCTRL_QCOM_SDM845
  Say Y here to enable support for pinctrl on the Snapdragon 845 SoC,
  as well as the associated GPIO driver.
 
+config PINCTRL_QCOM_SM8150
+   bool "Qualcomm SM8150 GCC"
+   select PINCTRL_QCOM
+   help
+ Say Y here to enable support for pinctrl on the Snapdragon SM8150 SoC,
+ as well as the associated GPIO driver.
+
 endmenu
 
 endif
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 6d9aca6d7b..3c7be4a685 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PINCTRL_QCOM_IPQ4019) += pinctrl-ipq4019.o
 obj-$(CONFIG_PINCTRL_QCOM_APQ8096) += pinctrl-apq8096.o
 obj-$(CONFIG_PINCTRL_QCOM_QCS404) += pinctrl-qcs404.o
 obj-$(CONFIG_PINCTRL_QCOM_SDM845) += pinctrl-sdm845.o
+obj-$(CONFIG_PINCTRL_QCOM_SM8150) += pinctrl-sm8150.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sm8150.c 
b/drivers/pinctrl/qcom/pinctrl-sm8150.c
new file mode 100644
index 00..a6c14d7254
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sm8150.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Qualcomm SM8150 pinctrl and GPIO driver
+ *
+ * Volodymyr Babchuk 
+ * Copyright (c) 2024 EPAM Systems.
+ *
+ * Based on similar U-Boot drivers. Constants were taken from the Linux driver
+ */
+
+#include 
+
+#include "pinctrl-qcom.h"
+
+#define WEST   0x0010
+#define EAST   0x0050
+#define NORTH  0x0090
+#define SOUTH  0x00D0
+
+#define MAX_PIN_NAME_LEN 32
+static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
+
+enum sm8150_functions {
+   msm_mux_adsp_ext,
+   msm_mux_agera_pll,
+   msm_mux_aoss_cti,
+   msm_mux_atest_char,
+   msm_mux_atest_char0,
+   msm_mux_atest_char1,
+   msm_mux_atest_char2,
+   msm_mux_atest_char3,
+   msm_mux_atest_usb1,
+   msm_mux_atest_usb2,
+   msm_mux_atest_usb10,
+   msm_mux_atest_usb11,
+   msm_mux_atest_usb12,
+   msm_mux_atest_usb13,
+   msm_mux_atest_usb20,
+   msm_mux_atest_usb21,
+   msm_mux_atest_usb22,
+   msm_mux_atest_usb23,
+   msm_mux_audio_ref,
+   msm_mux_btfm_slimbus,
+   msm_mux_cam_mclk,
+   msm_mux_cci_async,
+   msm_mux_cci_i2c,
+   msm_mux_cci_timer0,
+   msm_mux_cci_timer1,
+   msm_mux_cci_timer2,
+   msm_mux_cci_timer3,
+   msm_mux_cci_timer4,
+   msm_mux_cri_trng,
+   msm_mux_cri_trng0,
+   msm_mux_cri_trng1,
+   msm_mux_dbg_out,
+   msm_mux_ddr_bist,
+   msm_mux_ddr_pxi0,
+   msm_mux_ddr_pxi1,
+   msm_mux_ddr_pxi2,
+   msm_mux_ddr_pxi3,
+   msm_mux_edp_hot,
+   msm_mux_edp_lcd,
+   msm_mux_emac_phy,
+   msm_mux_emac_pps,
+   msm_mux_gcc_gp1,
+   msm_mux_gcc_gp2,
+   msm_mux_gcc_gp3,
+   msm_mux_gpio,
+   msm_mux_jitter_bist,
+   msm_mux_hs1_mi2s,
+   msm_mux_hs2_mi2s,
+   msm_mux_hs3_mi2s,
+   msm_mux_lpass_slimbus,
+   msm_mux_mdp_vsync,
+   msm_mux_mdp_vsync0,
+   msm_mux_mdp_vsync1,
+   msm_mux_mdp_vsync2,
+   msm_mux_mdp_vsync3,
+   msm_mux_mss_lte,
+   msm_mux_m_voc,
+   msm_mux_nav_pps,
+   msm_mux_pa_indicator,
+   msm_mux_pci_e0,
+   msm_mux_pci_e1,
+   msm_mux_phase_flag,
+   msm_mux_pll_bist,
+   msm_mux_pll_bypassnl,
+   msm_mux_pll_reset,
+   msm_mux_pri_mi2s,
+   msm_mux_pri_mi2s_ws,
+   msm_mux_prng_rosc,
+   msm_mux_qdss,
+   msm_mux_qdss_cti,
+   msm_mux_qlink_enable,
+   msm_mux_qlink_request,
+   msm_mux_qspi0,
+   msm_mux_qspi1,
+   msm_mux_qspi2,
+   msm_mux_qspi3,
+   msm_mux_qspi_clk,
+   msm_mux_qspi_cs,
+   msm_mux_qua_mi2s,
+   msm_mux_qup0,
+   msm_mux_qup1,
+   msm_mux_qup2,
+   msm_mux_qup3,
+   msm_mux_qup4,
+   msm_mux_qup5,
+   msm_mux_qup6,
+   msm_mux_qup7,
+   msm_mux_qup8,
+   msm_mux_qup9,
+   msm_mux_qup10,
+   msm_mux_qup11,
+   msm_mux_qup12,
+   msm_mux_qup13,
+   msm_mux_qup14,
+   msm_mux_qup15,
+   msm_mux_qup16,
+   msm_mux_qup17,
+   msm_mux_qup18,
+   msm_mux_qup19,
+   

[PATCH 6/8] pinctr: qcom: pass pin number to get_function_mux callback

[Volodymyr Babchuk]

This patch is the preparation for SM8150 support. This new SoC
depending on the particular pin can have different numbers for the
same function. For example "rgmii" function for GPIO4 has id=2 while
for GPIO59 it has id=1. So, to support this type of SoCs,
get_function_mux() callback needs to know for which pin the function
is requested.

Signed-off-by: Volodymyr Babchuk 
---

 drivers/pinctrl/qcom/pinctrl-apq8016.c | 3 ++-
 drivers/pinctrl/qcom/pinctrl-apq8096.c | 3 ++-
 drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 ++-
 drivers/pinctrl/qcom/pinctrl-qcom.c| 4 ++--
 drivers/pinctrl/qcom/pinctrl-qcom.h| 3 ++-
 drivers/pinctrl/qcom/pinctrl-qcs404.c  | 3 ++-
 drivers/pinctrl/qcom/pinctrl-sdm845.c  | 3 ++-
 7 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c 
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index 8149ffd83c..53042b6e05 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -49,7 +49,8 @@ static const char *apq8016_get_pin_name(struct udevice *dev,
}
 }
 
-static unsigned int apq8016_get_function_mux(unsigned int selector)
+static unsigned int apq8016_get_function_mux(__maybe_unused unsigned int pin,
+unsigned int selector)
 {
return msm_pinctrl_functions[selector].val;
 }
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8096.c 
b/drivers/pinctrl/qcom/pinctrl-apq8096.c
index d64ab1ff7b..8dcd171259 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8096.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8096.c
@@ -44,7 +44,8 @@ static const char *apq8096_get_pin_name(struct udevice *dev,
}
 }
 
-static unsigned int apq8096_get_function_mux(unsigned int selector)
+static unsigned int apq8096_get_function_mux(__maybe_unused unsigned int pin,
+unsigned int selector)
 {
return msm_pinctrl_functions[selector].val;
 }
diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c 
b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
index 2d99f99e1e..c2c358f556 100644
--- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
+++ b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
@@ -40,7 +40,8 @@ static const char *ipq4019_get_pin_name(struct udevice *dev,
return pin_name;
 }
 
-static unsigned int ipq4019_get_function_mux(unsigned int selector)
+static unsigned int ipq4019_get_function_mux(__maybe_unused unsigned int pin,
+unsigned int selector)
 {
return msm_pinctrl_functions[selector].val;
 }
diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c 
b/drivers/pinctrl/qcom/pinctrl-qcom.c
index dc3d8c4d90..de0bb4de0a 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
@@ -82,10 +82,10 @@ static int msm_pinmux_set(struct udevice *dev, unsigned int 
pin_selector,
  unsigned int func_selector)
 {
struct msm_pinctrl_priv *priv = dev_get_priv(dev);
+   u32 func = priv->data->get_function_mux(pin_selector, func_selector);
 
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
-   TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE,
-   priv->data->get_function_mux(func_selector) << 2);
+   TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
return 0;
 }
 
diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.h 
b/drivers/pinctrl/qcom/pinctrl-qcom.h
index 07f2eae9ba..49b7bfbc00 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.h
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.h
@@ -18,7 +18,8 @@ struct msm_pinctrl_data {
int functions_count;
const char *(*get_function_name)(struct udevice *dev,
 unsigned int selector);
-   unsigned int (*get_function_mux)(unsigned int selector);
+   unsigned int (*get_function_mux)(unsigned int pin,
+unsigned int selector);
const char *(*get_pin_name)(struct udevice *dev,
unsigned int selector);
 };
diff --git a/drivers/pinctrl/qcom/pinctrl-qcs404.c 
b/drivers/pinctrl/qcom/pinctrl-qcs404.c
index ac00afa2a1..977f7b2ac3 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcs404.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcs404.c
@@ -56,7 +56,8 @@ static const char *qcs404_get_pin_name(struct udevice *dev,
}
 }
 
-static unsigned int qcs404_get_function_mux(unsigned int selector)
+static unsigned int qcs404_get_function_mux(__maybe_unused unsigned int pin,
+   unsigned int selector)
 {
return msm_pinctrl_functions[selector].val;
 }
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c 
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 9f0f4085ce..64ce1bf15e 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
@@ -70,7 +70,8 @@ static const char *sdm845_get_pin_name(struct udevice *dev,
return pin_name;
 }
 
-static unsigned 

[PATCH 1/8] clk: qcom: clear div mask before assigning new divider

[Volodymyr Babchuk]

We need to do this to ensure that new divider is applied
correctly. This fixes potential issue with 1Gbit ethernet on
SA8155P-ADP boards.

Signed-off-by: Volodymyr Babchuk 
---

 drivers/clk/qcom/clock-qcom.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
index 7c683e5192..729d190c54 100644
--- a/drivers/clk/qcom/clock-qcom.c
+++ b/drivers/clk/qcom/clock-qcom.c
@@ -117,7 +117,8 @@ void clk_rcg_set_rate_mnd(phys_addr_t base, const struct 
bcr_regs *regs,
 
/* setup src select and divider */
cfg  = readl(base + regs->cfg_rcgr);
-   cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK);
+   cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK |
+CFG_SRC_DIV_MASK);
cfg |= source & CFG_SRC_SEL_MASK; /* Select clock source */
 
if (div)
-- 
2.43.0

Re: [PATCH 0/2] arm: socfpga: arria10: allow to reprogram FPGA with warm reboot

[Michał Barnaś]

On Thu, Feb 29, 2024 at 2:03 PM Dinh Nguyen  wrote:
>
>
>
> On 2/22/24 09:20, Michał Barnaś wrote:
> >
> > By default, the board requires power cycle (cold boot) to program the
> > FPGA with bitstream. This change adds Kconfig that allows to enable
> > reprogramming the FPGA with every boot. This makes the update process
> > of the bitstream on the filesystem to be applied with simple system
> > reboot.
> >
> >
>
> If we want to enable the reprogramming on every boot, would it make
> sense to just do it and not even bother with the Kconfig option?
>
> Dinh

The FPGA programming part takes quite a long time, so it increases the
reboot time significantly.
I don't think that everyone needs the reprogramming to happen every
time. We need that
because our boards are closed in the lab and the power is not easily
accessible, so in case of
update to the bitstream, we should be able to remotely update it with
a pure warm reboot.
So I thought that this should be set by Kconfig to not bother other users with
longer reboot times.

Michał

Re: [PATCH 0/2] arm: socfpga: arria10: allow to reprogram FPGA with warm reboot

[Dinh Nguyen]

On 2/22/24 09:20, Michał Barnaś wrote:


By default, the board requires power cycle (cold boot) to program the
FPGA with bitstream. This change adds Kconfig that allows to enable
reprogramming the FPGA with every boot. This makes the update process
of the bitstream on the filesystem to be applied with simple system
reboot.




If we want to enable the reprogramming on every boot, would it make 
sense to just do it and not even bother with the Kconfig option?


Dinh

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Tom Rini]

On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
> On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
> > On Wed, 28 Feb 2024 at 20:50, Tom Rini  wrote:
> > >
> > > On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > > > + Shawn, Krzysztof, Conor
> > > >
> > > > Hi Tom,
> > > >
> > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini  wrote:
> > > > >
> > > > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > > > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees 
> > > > > > > with
> > > > > > > linux") removed the display timings from the board device tree 
> > > > > > > whereas
> > > > > > > they are still needed by the mxsfb driver.
> > > > > > > Add the timings back (the correct ones) in the
> > > > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > > > > opos6uldev.env file.
> > > > > > >
> > > > > > > Update the opos6uldev_defconfig file so that the LCD turns on at 
> > > > > > > boot.
> > > > > > >
> > > > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees 
> > > > > > > with linux")
> > > > > > > Signed-off-by: Sébastien Szymanski 
> > > > > > > 
> > > > > >
> > > > > > Huh.  This is the commit that did that upstream.
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > > > >
> > > > > > It's interesting how the timings in linux were always slightly 
> > > > > > different
> > > > > > from in u-boot.
> > > > >
> > > > > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> > > > > because this is a recent (rather than ancient) example of one of the
> > > > > concerns about OF_UPSTREAM.
> > > >
> > > > I rather think about this as an opportunity to improve with
> > > > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > > > corresponding Linux kernel sub-arch maintainers. Especially once we
> > > > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
> > > > to keep them aware that U-Boot should be considered too.
> > >
> > > Yes, a more extensive check around when removing information from dts
> > > files would be good.
> > >
> > > > > I think the commit in question can be
> > > > > summarized as "remove a bunch of explicit HW information because 
> > > > > there's
> > > > > now a Linux Kernel driver that determines that dynamically". What do 
> > > > > we
> > > > > do next? The old information is in a presumably valid binding still, 
> > > > > can
> > > > > we just put it back and comment that consumers outside of Linux use 
> > > > > this
> > > > > still so it's not removed again later? Or am I just missing where we 
> > > > > can
> > > > > instead get this information from the DT still and not need to come up
> > > > > with a new driver and subsystems?
> > > >
> > > > I can see following two paths forward:
> > > >
> > > > 1) Partially revert the Linux kernel commit to add back the display
> > > > timings in DT.
> > > > 2) Extend drivers/video/simple_panel.c in U-Boot to add support for
> > > > compatible: "armadeus,st0700-adapt".
> > > >
> > > > If possible then I would be in favour of (2) rather than the current
> > > > patch to do this properly.
> > >
> > > Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
> > > and then our drivers/video/simple_panel.c it sure would be nice if it's
> > > just a matter of adding a compatible but I wouldn't be surprised if it
> > > ends up needing more information being passed along too?
> > 
> > Although I am not a LCD panel expert but looking at the kernel driver
> > code [1], the display timings are rather taken from a static data
> > structure matching the compatible "armadeus,st0700-adapt".
> > 
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c#n901
> 
> Yes. My point is that it seems like the situation changed from "device
> tree provides timings for the platform" to "driver has timing
> information for N displays" and so we'll need to do something clever to
> avoid including the structs for 5 panels when we'll only ever
> (likely...) see one. And that also yes, we'll probably need to add data
> for this panel rather than re-use the PANASONIC_VVX10F004B00 data.
> 
> > > And I'm going
> > > assume there's good reasons for the design change in how the drivers
> > > work in Linux now and note that it might make things more challenging
> > > for us when we do care about space.
> > 
> > I agree it is always going to be challenging to use DT during SPL
> > stage which is mostly constrained by limited on-chip RAM.
> 
> Well, no. The DT way handled this more efficiently, I think I wasn't
> clear enough in my reply.

And it's not just SPL, full U-Boot needs to stay small and within flash
partition considerations and I become cranky and question people when

Re: [RFC PATCH 2/6] arm: clean up v7 and v8 linker scripts for bss_start/end

[Caleb Connolly]

On 28/02/2024 10:48, Ilias Apalodimas wrote:

commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated")
and
commit f84a7b8f54db ("ARM: Fix __bss_start and __bss_end in linker scripts")
were moving the bss_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code.

However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section.

So let's start cleaning this up starting with the bss_start and bss_end
variables. Convert them into symbols within the .bss section definition.

[0] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC13

Signed-off-by: Ilias Apalodimas 

Tested-by: Caleb Connolly  # Qualcomm sdm845

This patch and a few others in this series conflict with my patch [1] 
which drops the dragonboard820c linker script. My patch doesn't have any 
external dependencies, so would it be easier for you to take it along 
with this series? Or how best should we avoid the merge conflicts here?


[1]: 
https://lore.kernel.org/u-boot/20240226-b4-qcom-common-target-v5-19-10c8e078b...@linaro.org/


Thanks and regards,

---
  arch/arm/cpu/armv8/u-boot-spl.lds | 14 +++---
  arch/arm/cpu/armv8/u-boot.lds | 15 +++
  arch/arm/cpu/u-boot.lds   | 22 --
  arch/arm/lib/sections.c   |  2 --
  arch/arm/mach-rockchip/u-boot-tpl-v8.lds  | 14 +++---
  arch/arm/mach-zynq/u-boot.lds | 21 +++--
  board/qualcomm/dragonboard820c/u-boot.lds | 15 +++
  7 files changed, 19 insertions(+), 84 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index 7cb9d731246d..16fddb46e9cb 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -63,18 +63,10 @@ SECTIONS

_image_binary_end = .;

-   .bss_start (NOLOAD) : {
-   . = ALIGN(8);
-   KEEP(*(.__bss_start));
-   } >.sdram
-
-   .bss (NOLOAD) : {
+   .bss : {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(8);
-   } >.sdram
-
-   .bss_end (NOLOAD) : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
} >.sdram

/DISCARD/ : { *(.rela*) }
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index fb6a30c922f7..c4ee10ebc3ff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -149,19 +149,10 @@ SECTIONS

_end = .;

-   . = ALIGN(8);
-
-   .bss_start : {
-   KEEP(*(.__bss_start));
-   }
-
-   .bss : {
+   .bss ALIGN(8): {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(8);
-   }
-
-   .bss_end : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
}

/DISCARD/ : { *(.dynsym) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 7724c9332c3b..90d329b1ebe0 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -206,27 +206,13 @@ SECTIONS
*(.mmutable)
}

-/*
- * Compiler-generated __bss_start and __bss_end, see arch/arm/lib/bss.c
- * __bss_base and __bss_limit are for linker only (overlay ordering)
- */
-
-   .bss_start __rel_dyn_start (OVERLAY) : {
-   KEEP(*(.__bss_start));
-   __bss_base = .;
-   }
-
-   .bss __bss_base (OVERLAY) : {
+   .bss ALIGN(4): {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(4);
-__bss_limit = .;
-   }
-
-   .bss_end __bss_limit (OVERLAY) : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
}

-   .dynsym _image_binary_end : { *(.dynsym) }
+   .dynsym  : { *(.dynsym) }
.dynbss : { *(.dynbss) }
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 857879711c6a..8e8bd5797e16 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -19,8 +19,6 @@
   * aliasing warnings.
   */

-char __bss_start[0] __section(".__bss_start");
-char __bss_end[0] __section(".__bss_end");
  char __image_copy_start[0] __section(".__image_copy_start");
  char __image_copy_end[0] __section(".__image_copy_end");
  char __rel_dyn_start[0] __section(".__rel_dyn_start");
diff --git a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds 
b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
index 74618eba591b..b7887194026e 100644
--- a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
+++ b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
@@ -56,18 +56,10 @@ SECTIONS

_image_binary_end = .;

-   .bss_start (NOLOAD) : {
-   . = ALIGN(8);
-   

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Tom Rini]

On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
> On Wed, 28 Feb 2024 at 20:50, Tom Rini  wrote:
> >
> > On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > > + Shawn, Krzysztof, Conor
> > >
> > > Hi Tom,
> > >
> > > On Wed, 28 Feb 2024 at 18:40, Tom Rini  wrote:
> > > >
> > > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with
> > > > > > linux") removed the display timings from the board device tree 
> > > > > > whereas
> > > > > > they are still needed by the mxsfb driver.
> > > > > > Add the timings back (the correct ones) in the
> > > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > > > opos6uldev.env file.
> > > > > >
> > > > > > Update the opos6uldev_defconfig file so that the LCD turns on at 
> > > > > > boot.
> > > > > >
> > > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with 
> > > > > > linux")
> > > > > > Signed-off-by: Sébastien Szymanski 
> > > > > > 
> > > > >
> > > > > Huh.  This is the commit that did that upstream.
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > > >
> > > > > It's interesting how the timings in linux were always slightly 
> > > > > different
> > > > > from in u-boot.
> > > >
> > > > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> > > > because this is a recent (rather than ancient) example of one of the
> > > > concerns about OF_UPSTREAM.
> > >
> > > I rather think about this as an opportunity to improve with
> > > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > > corresponding Linux kernel sub-arch maintainers. Especially once we
> > > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
> > > to keep them aware that U-Boot should be considered too.
> >
> > Yes, a more extensive check around when removing information from dts
> > files would be good.
> >
> > > > I think the commit in question can be
> > > > summarized as "remove a bunch of explicit HW information because there's
> > > > now a Linux Kernel driver that determines that dynamically". What do we
> > > > do next? The old information is in a presumably valid binding still, can
> > > > we just put it back and comment that consumers outside of Linux use this
> > > > still so it's not removed again later? Or am I just missing where we can
> > > > instead get this information from the DT still and not need to come up
> > > > with a new driver and subsystems?
> > >
> > > I can see following two paths forward:
> > >
> > > 1) Partially revert the Linux kernel commit to add back the display
> > > timings in DT.
> > > 2) Extend drivers/video/simple_panel.c in U-Boot to add support for
> > > compatible: "armadeus,st0700-adapt".
> > >
> > > If possible then I would be in favour of (2) rather than the current
> > > patch to do this properly.
> >
> > Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
> > and then our drivers/video/simple_panel.c it sure would be nice if it's
> > just a matter of adding a compatible but I wouldn't be surprised if it
> > ends up needing more information being passed along too?
> 
> Although I am not a LCD panel expert but looking at the kernel driver
> code [1], the display timings are rather taken from a static data
> structure matching the compatible "armadeus,st0700-adapt".
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c#n901

Yes. My point is that it seems like the situation changed from "device
tree provides timings for the platform" to "driver has timing
information for N displays" and so we'll need to do something clever to
avoid including the structs for 5 panels when we'll only ever
(likely...) see one. And that also yes, we'll probably need to add data
for this panel rather than re-use the PANASONIC_VVX10F004B00 data.

> > And I'm going
> > assume there's good reasons for the design change in how the drivers
> > work in Linux now and note that it might make things more challenging
> > for us when we do care about space.
> 
> I agree it is always going to be challenging to use DT during SPL
> stage which is mostly constrained by limited on-chip RAM.

Well, no. The DT way handled this more efficiently, I think I wasn't
clear enough in my reply.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] board: rockchip: add Rockchip Toybrick TB-RK3588X board

[Elon Zhang]

TB-RK3588X board is a Rockchip Toybrick RK3588 based development board.

Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB Memory LPDDR4x
Mali G610MC4 GPU
2× MIPI-CSI0 Connector
1x 2Lanes PCIe3.0 Connector
1x SATA3.0 Connector
32GB eMMC Module
2x USB 2.0, 2x USB 3.0
1x HDMI Output, 1x HDMI Input
2x Ethernet Port

Functions work normally:
[1] USB2.0 Host
[2] Ethernet0 with PHY RTL8211F

More information can be obtained from the following websites:
[1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html
[2] http://t.rock-chips.com/

Kernel commits:
8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for 
TB-RK3588X board")
7140387ff49d ("dt-bindings: arm: rockchip: Add Toybrick TB-RK3588X")

Signed-off-by: Elon Zhang 
---
 arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi   |  12 +
 arch/arm/dts/rk3588-toybrick-x0.dts   | 672 ++
 arch/arm/mach-rockchip/rk3588/Kconfig |  25 +
 board/rockchip/toybrick_rk3588/Kconfig|  15 +
 board/rockchip/toybrick_rk3588/MAINTAINERS|   8 +
 board/rockchip/toybrick_rk3588/Makefile   |   6 +
 .../toybrick_rk3588/toybrick-rk3588.c |  39 +
 configs/toybrick-rk3588_defconfig |  82 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 include/configs/toybrick_rk3588.h |  15 +
 10 files changed, 875 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-toybrick-x0.dts
 create mode 100644 board/rockchip/toybrick_rk3588/Kconfig
 create mode 100644 board/rockchip/toybrick_rk3588/MAINTAINERS
 create mode 100644 board/rockchip/toybrick_rk3588/Makefile
 create mode 100644 board/rockchip/toybrick_rk3588/toybrick-rk3588.c
 create mode 100644 configs/toybrick-rk3588_defconfig
 create mode 100644 include/configs/toybrick_rk3588.h

diff --git a/arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi 
b/arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
new file mode 100644
index 00..1aeb5410e4
--- /dev/null
+++ b/arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Rockchip Electronics Co., Ltd.
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", 
+   };
+};
diff --git a/arch/arm/dts/rk3588-toybrick-x0.dts 
b/arch/arm/dts/rk3588-toybrick-x0.dts
new file mode 100644
index 00..f3f7c1d35e
--- /dev/null
+++ b/arch/arm/dts/rk3588-toybrick-x0.dts
@@ -0,0 +1,672 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include "rk3588.dtsi"
+
+/ {
+   model = "Rockchip Toybrick TB-RK3588X Board";
+   compatible = "rockchip,rk3588-toybrick-x0", "rockchip,rk3588";
+
+   aliases {
+   mmc0 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-vol-up {
+   label = "Volume Up";
+   linux,code = ;
+   press-threshold-microvolt = <17000>;
+   };
+
+   button-vol-down {
+   label = "Volume Down";
+   linux,code = ;
+   press-threshold-microvolt = <417000>;
+   };
+
+   button-menu {
+   label = "Menu";
+   linux,code = ;
+   press-threshold-microvolt = <89>;
+   };
+
+   button-escape {
+   label = "Escape";
+   linux,code = ;
+   press-threshold-microvolt = <1235000>;
+   };
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   power-supply = <_dcin>;
+   pwms = < 0 25000 0>;
+   };
+
+   pcie20_avdd0v85: pcie20-avdd0v85-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "pcie20_avdd0v85";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <85>;
+   vin-supply = <_0v85_s0>;
+   };
+
+   pcie20_avdd1v8: pcie20-avdd1v8-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "pcie20_avdd1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   

Re: [PATCH v2 05/16] power: rk8xx: add support for RK806

[Quentin Schulz]

Hi Jonas,

On 2/29/24 12:47, Jonas Karlman wrote:

Hi Quentin,

On 2024-02-23 10:05, Quentin Schulz wrote:

From: Quentin Schulz 

This adds support for RK806, only the SPI variant has been tested.

The communication "protocol" over SPI is the following:
  - write three bytes:
- 1 byte: [0:3] length of the payload, [6] Enable CRC, [7] Write
- 1 byte: LSB register address
- 1 byte: MSB register address
  - write/read length of payload

The CRC is always disabled for now.

The RK806 technically supports I2C as well, and this should be able to
support it without any change, but it wasn't tested.

The DT node name prefix for the buck converters has changed in the
Device Tree and is now dcdc-reg. The logic for buck converters is
however manageable within the current logic inside the rk8xx regulator
driver. The same cannot be said for the NLDO and PLDO.

Because pmic_bind_children() parses the DT nodes and extracts the LDO
index from the DT node name, NLDO and PLDO will have overlapping
indices. Therefore, we need a separate logic from the already-existing
ldo callbacks. Let's reuse as much as possible though.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  drivers/power/pmic/rk8xx.c  |  85 +++
  drivers/power/regulator/rk8xx.c | 514 +++-
  include/power/rk8xx_pmic.h  |  19 ++
  3 files changed, 616 insertions(+), 2 deletions(-)

diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 4e3a17337ee..15cb82029cc 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -9,8 +9,10 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
+#include 
  #include 
  
  static int rk8xx_sysreset_request(struct udevice *dev, enum sysreset_t type)

@@ -32,6 +34,10 @@ static int rk8xx_sysreset_request(struct udevice *dev, enum 
sysreset_t type)
pmic_clrsetbits(dev->parent, RK817_REG_SYS_CFG3, 0,
BIT(0));
break;
+   case RK806_ID:
+   pmic_clrsetbits(dev->parent, RK806_REG_SYS_CFG3, 0,
+   BIT(0));
+   break;
default:
printf("Unknown PMIC RK%x: Cannot shutdown\n",
   priv->variant);
@@ -83,6 +89,11 @@ void rk8xx_off_for_plugin(struct udevice *dev)
}
  }
  
+static struct reg_data rk806_init_reg[] = {

+   /* RST_FUN */
+   { RK806_REG_SYS_CFG3, GENMASK(7, 6), BIT(7)},
+};
+
  static struct reg_data rk817_init_reg[] = {
  /* enable the under-voltage protection,
   * the under-voltage protection will shutdown the LDO3 and reset the PMIC
@@ -92,7 +103,10 @@ static struct reg_data rk817_init_reg[] = {
  
  static const struct pmic_child_info pmic_children_info[] = {

{ .prefix = "DCDC_REG", .driver = "rk8xx_buck"},
+   { .prefix = "dcdc-reg", .driver = "rk8xx_buck"},
{ .prefix = "LDO_REG", .driver = "rk8xx_ldo"},
+   { .prefix = "nldo-reg", .driver = "rk8xx_nldo"},
+   { .prefix = "pldo-reg", .driver = "rk8xx_pldo"},
{ .prefix = "SWITCH_REG", .driver = "rk8xx_switch"},
{ },
  };
@@ -102,11 +116,47 @@ static int rk8xx_reg_count(struct udevice *dev)
return RK808_NUM_OF_REGS;
  }
  
+struct rk806_cmd {

+   charlen: 4; /* Payload size in bytes - 1 */
+   charreserved: 2;
+   charcrc_en: 1;
+   charop: 1; /* READ=0; WRITE=1; */
+   charreg_l;
+#define REG_L_MASK GENMASK(7, 0)
+   charreg_h;
+#define REG_H_MASK GENMASK(15, 8)
+};
+
  static int rk8xx_write(struct udevice *dev, uint reg, const uint8_t *buff,
  int len)
  {
int ret;
  
+	if (device_get_uclass_id(dev->parent) == UCLASS_SPI) {

+   struct spi_slave *spi = dev_get_parent_priv(dev);
+   struct rk806_cmd cmd = {
+   .op = 1,
+   .len = len - 1,
+   .reg_l = FIELD_GET(REG_L_MASK, reg),
+   .reg_h = FIELD_GET(REG_H_MASK, reg),
+   };
+
+   ret = dm_spi_claim_bus(dev);
+   if (ret) {
+   debug("Couldn't claim bus for device: %p!\n", dev);
+   return ret;
+   }
+
+   ret = spi_write_then_read(spi, (u8 *), sizeof(cmd), buff, 
NULL, len);
+   if (ret)
+   debug("write error to device: %p register: %#x!\n",
+ dev, reg);
+
+   dm_spi_release_bus(dev);


I am getting following build error on PineTab2 [1] with this:

aarch64-linux-gnu-ld.bfd: drivers/power/pmic/rk8xx.o: in function `rk8xx_write':
drivers/power/pmic/rk8xx.c:144:(.text.rk8xx_write+0x60): undefined reference to 
`dm_spi_claim_bus'
aarch64-linux-gnu-ld.bfd: 
drivers/power/pmic/rk8xx.c:150:(.text.rk8xx_write+0x84): undefined reference to 
`spi_write_then_read'
aarch64-linux-gnu-ld.bfd: 

Re: [PATCH v2 05/16] power: rk8xx: add support for RK806

[Jonas Karlman]

Hi Quentin,

On 2024-02-23 10:05, Quentin Schulz wrote:
> From: Quentin Schulz 
> 
> This adds support for RK806, only the SPI variant has been tested.
> 
> The communication "protocol" over SPI is the following:
>  - write three bytes:
>- 1 byte: [0:3] length of the payload, [6] Enable CRC, [7] Write
>- 1 byte: LSB register address
>- 1 byte: MSB register address
>  - write/read length of payload
> 
> The CRC is always disabled for now.
> 
> The RK806 technically supports I2C as well, and this should be able to
> support it without any change, but it wasn't tested.
> 
> The DT node name prefix for the buck converters has changed in the
> Device Tree and is now dcdc-reg. The logic for buck converters is
> however manageable within the current logic inside the rk8xx regulator
> driver. The same cannot be said for the NLDO and PLDO.
> 
> Because pmic_bind_children() parses the DT nodes and extracts the LDO
> index from the DT node name, NLDO and PLDO will have overlapping
> indices. Therefore, we need a separate logic from the already-existing
> ldo callbacks. Let's reuse as much as possible though.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/power/pmic/rk8xx.c  |  85 +++
>  drivers/power/regulator/rk8xx.c | 514 
> +++-
>  include/power/rk8xx_pmic.h  |  19 ++
>  3 files changed, 616 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> index 4e3a17337ee..15cb82029cc 100644
> --- a/drivers/power/pmic/rk8xx.c
> +++ b/drivers/power/pmic/rk8xx.c
> @@ -9,8 +9,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  static int rk8xx_sysreset_request(struct udevice *dev, enum sysreset_t type)
> @@ -32,6 +34,10 @@ static int rk8xx_sysreset_request(struct udevice *dev, 
> enum sysreset_t type)
>   pmic_clrsetbits(dev->parent, RK817_REG_SYS_CFG3, 0,
>   BIT(0));
>   break;
> + case RK806_ID:
> + pmic_clrsetbits(dev->parent, RK806_REG_SYS_CFG3, 0,
> + BIT(0));
> + break;
>   default:
>   printf("Unknown PMIC RK%x: Cannot shutdown\n",
>  priv->variant);
> @@ -83,6 +89,11 @@ void rk8xx_off_for_plugin(struct udevice *dev)
>   }
>  }
>  
> +static struct reg_data rk806_init_reg[] = {
> + /* RST_FUN */
> + { RK806_REG_SYS_CFG3, GENMASK(7, 6), BIT(7)},
> +};
> +
>  static struct reg_data rk817_init_reg[] = {
>  /* enable the under-voltage protection,
>   * the under-voltage protection will shutdown the LDO3 and reset the PMIC
> @@ -92,7 +103,10 @@ static struct reg_data rk817_init_reg[] = {
>  
>  static const struct pmic_child_info pmic_children_info[] = {
>   { .prefix = "DCDC_REG", .driver = "rk8xx_buck"},
> + { .prefix = "dcdc-reg", .driver = "rk8xx_buck"},
>   { .prefix = "LDO_REG", .driver = "rk8xx_ldo"},
> + { .prefix = "nldo-reg", .driver = "rk8xx_nldo"},
> + { .prefix = "pldo-reg", .driver = "rk8xx_pldo"},
>   { .prefix = "SWITCH_REG", .driver = "rk8xx_switch"},
>   { },
>  };
> @@ -102,11 +116,47 @@ static int rk8xx_reg_count(struct udevice *dev)
>   return RK808_NUM_OF_REGS;
>  }
>  
> +struct rk806_cmd {
> + charlen: 4; /* Payload size in bytes - 1 */
> + charreserved: 2;
> + charcrc_en: 1;
> + charop: 1; /* READ=0; WRITE=1; */
> + charreg_l;
> +#define REG_L_MASK   GENMASK(7, 0)
> + charreg_h;
> +#define REG_H_MASK   GENMASK(15, 8)
> +};
> +
>  static int rk8xx_write(struct udevice *dev, uint reg, const uint8_t *buff,
> int len)
>  {
>   int ret;
>  
> + if (device_get_uclass_id(dev->parent) == UCLASS_SPI) {
> + struct spi_slave *spi = dev_get_parent_priv(dev);
> + struct rk806_cmd cmd = {
> + .op = 1,
> + .len = len - 1,
> + .reg_l = FIELD_GET(REG_L_MASK, reg),
> + .reg_h = FIELD_GET(REG_H_MASK, reg),
> + };
> +
> + ret = dm_spi_claim_bus(dev);
> + if (ret) {
> + debug("Couldn't claim bus for device: %p!\n", dev);
> + return ret;
> + }
> +
> + ret = spi_write_then_read(spi, (u8 *), sizeof(cmd), buff, 
> NULL, len);
> + if (ret)
> + debug("write error to device: %p register: %#x!\n",
> +   dev, reg);
> +
> + dm_spi_release_bus(dev);

I am getting following build error on PineTab2 [1] with this:

aarch64-linux-gnu-ld.bfd: drivers/power/pmic/rk8xx.o: in function `rk8xx_write':
drivers/power/pmic/rk8xx.c:144:(.text.rk8xx_write+0x60): undefined reference to 
`dm_spi_claim_bus'
aarch64-linux-gnu-ld.bfd: 
drivers/power/pmic/rk8xx.c:150:(.text.rk8xx_write+0x84): undefined reference to 

Re: [PATCH v2 0/1] Fix booting kernels with ATAGS and extlinux

[Svyatoslav Ryhel]

чт, 25 січ. 2024 р. о 22:17 Svyatoslav Ryhel  пише:
>
> Currently, if boot with extlinux.conf and do not set the fdt
> U-Boot will provide its own device tree. This behavior is
> beneficial if the U-Boot device tree is in sync with Linux,
> but it totally halts the booting of pre-dtb kernels (3.4 for
> example) since it uses ATAGs. To fix this, pass `-` in the
> fdt extlinux field as a signal that no tree should be used.
>
> Tested with 3.4 legacy kernel and mainline 6.7 kernel on
> P895 (lg_x3 board).
>
> ---
> Changes form v1
>  - Added CONFIG guards
>  - Clarified documentation
> ---
>
> Svyatoslav Ryhel (1):
>   boot: pxe_utils: skip fdt setup in case legacy kernel is booted
>
>  boot/pxe_utils.c   | 27 ++-
>  doc/develop/distro.rst |  6 ++
>  2 files changed, 28 insertions(+), 5 deletions(-)
>
> --
> 2.40.1
>

Hello, Tom! A month passed since v2 was pushed without any actions,
should I re-send it or maybe some adjustments are needed?

Re: [PATCH v6] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

[Roger Quadros]

On 28/02/2024 14:06, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
> 
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
> 
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
> 
> Signed-off-by: MD Danish Anwar 
> Acked-by: Ravi Gunasekaran 

Reviewed-by: Roger Quadros 

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Bruce Sun]

Thans for your advice, I will port the driver from linux driver(xtx.c) 
later.


On 2/29/2024 5:05 PM, Frieder Schrempf wrote:

Hi Bruce,

On 26.12.23 08:58, Bruce Suen wrote:

[Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
Informationen, warum dies wichtig ist, finden Sie unter 
https://aka.ms/LearnAboutSenderIdentification ]

Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
XT26Q04DX SPI NAND.

These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
ECC(8bit strength per 512bytes).

Datasheet Links:
- http://www.xtxtech.com/download/?AId=458
- http://www.xtxtech.com/download/?AId=495

Signed-off-by: Bruce Suen 

Below you seem to have written a new driver based on gigadevice.c. Can
you please instead port the existing Linux driver (xtx.c). This will
help us to sync the drivers in the future if new chips will be added.

Thanks
Frieder


---
  drivers/mtd/nand/spi/Makefile |   1 +
  drivers/mtd/nand/spi/core.c   |   1 +
  drivers/mtd/nand/spi/xtx.c| 180 ++
  include/linux/mtd/spinand.h   |   1 +
  4 files changed, 183 insertions(+)
  create mode 100644 drivers/mtd/nand/spi/xtx.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 3051de4f7e..e46cfed446 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,5 @@
  # SPDX-License-Identifier: GPL-2.0

  spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o toshiba.o 
winbond.o
+spinand-objs += xtx.o
  obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 597b088ca7..0b4c067425 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
*spinand_manufacturers[] = {
 _spinand_manufacturer,
 _spinand_manufacturer,
 _spinand_manufacturer,
+   _spinand_manufacturer,
  };

  static int spinand_manufacturer_match(struct spinand_device *spinand,
diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
new file mode 100644
index 00..602861c77b
--- /dev/null
+++ b/drivers/mtd/nand/spi/xtx.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * Derived from drivers/mtd/nand/spi/micron.c
+ *   Copyright (c) 2016-2017 Micron Technology, Inc.
+ */
+
+#ifndef __UBOOT__
+#include 
+#include 
+#endif
+#include 
+#include 
+
+#define SPINAND_MFR_XTX0x0B
+
+#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
+#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
+#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
+#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
+#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+   SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+   SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+   if (section)
+   return -ERANGE;
+
+   region->offset = mtd->oobsize / 2;
+   region->length = mtd->oobsize / 2;
+
+   return 0;
+}
+
+static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
+  struct mtd_oob_region *region)
+{
+   if (section)
+   return -ERANGE;
+
+   region->offset = 2;
+   region->length = mtd->oobsize / 2 - 2;
+
+   return 0;
+}
+
+static const struct mtd_ooblayout_ops xt26xxxd_ooblayout = {
+   .ecc = xt26xxxd_ooblayout_ecc,
+   .rfree = xt26xxxd_ooblayout_free,
+};
+
+static int xt26xxxd_ecc_get_status(struct spinand_device *spinand,
+  u8 status)
+{
+   switch (FIELD_GET(STATUS_ECC_MASK, status)) {
+   case XT26XXXD_STATUS_ECC_NO_DETECTED:
+   return 0;
+   case XT26XXXD_STATUS_ECC_UNCOR_ERROR:
+   return -EBADMSG;
+   case XT26XXXD_STATUS_ECC_1_7_CORRECTED:
+   return 4 + FIELD_GET(XT26XXXD_STATUS_ECC3_ECC2_MASK, status);
+   case XT26XXXD_STATUS_ECC_8_CORRECTED:
+   return 8;
+   default:
+   break;
+   }
+
+   return 

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Frieder Schrempf]

On 30.01.24 04:11, Bruce Sun wrote:
>   
> Sie erhalten nicht oft eine E-Mail von bruce_s...@163.com. Erfahren Sie,
> warum dies wichtig ist 
>   
> 
> 
> On 1/29/2024 8:00 PM, Jagan Teki wrote:
>> On Tue, Dec 26, 2023 at 1:28 PM Bruce Suen  wrote:
>>> Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
>>> XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
>>> XT26Q04DX SPI NAND.
>>>
>>> These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
>>> ECC(8bit strength per 512bytes).
>>>
>>> Datasheet Links:
>>> - http://www.xtxtech.com/download/?AId=458
>>> - http://www.xtxtech.com/download/?AId=495
>>>
>>> Signed-off-by: Bruce Suen 
>>> ---
>> This won't apply on my spi tree, maybe some out-of-master changes are 
>> stopping.
>
> can you give me your spi tree? I use
> "https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git“ before.

Using u-boot-nand-flash seems correct as this is what MAINTAINERS lists
as tree for SPI NAND.

Jagan, I think this is expected to be handled by Dario and Michael and
not by the SPI maintainer.

Re: [PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx

[Frieder Schrempf]

Hi Bruce,

On 26.12.23 08:58, Bruce Suen wrote:
> [Sie erhalten nicht häufig E-Mails von bruce_s...@163.com. Weitere 
> Informationen, warum dies wichtig ist, finden Sie unter 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
> XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
> XT26Q04DX SPI NAND.
> 
> These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
> ECC(8bit strength per 512bytes).
> 
> Datasheet Links:
> - http://www.xtxtech.com/download/?AId=458
> - http://www.xtxtech.com/download/?AId=495
> 
> Signed-off-by: Bruce Suen 

Below you seem to have written a new driver based on gigadevice.c. Can
you please instead port the existing Linux driver (xtx.c). This will
help us to sync the drivers in the future if new chips will be added.

Thanks
Frieder

> ---
>  drivers/mtd/nand/spi/Makefile |   1 +
>  drivers/mtd/nand/spi/core.c   |   1 +
>  drivers/mtd/nand/spi/xtx.c| 180 ++
>  include/linux/mtd/spinand.h   |   1 +
>  4 files changed, 183 insertions(+)
>  create mode 100644 drivers/mtd/nand/spi/xtx.c
> 
> diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
> index 3051de4f7e..e46cfed446 100644
> --- a/drivers/mtd/nand/spi/Makefile
> +++ b/drivers/mtd/nand/spi/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
> 
>  spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o toshiba.o 
> winbond.o
> +spinand-objs += xtx.o
>  obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 597b088ca7..0b4c067425 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
> *spinand_manufacturers[] = {
> _spinand_manufacturer,
> _spinand_manufacturer,
> _spinand_manufacturer,
> +   _spinand_manufacturer,
>  };
> 
>  static int spinand_manufacturer_match(struct spinand_device *spinand,
> diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
> new file mode 100644
> index 00..602861c77b
> --- /dev/null
> +++ b/drivers/mtd/nand/spi/xtx.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Stefan Roese 
> + *
> + * Derived from drivers/mtd/nand/spi/micron.c
> + *   Copyright (c) 2016-2017 Micron Technology, Inc.
> + */
> +
> +#ifndef __UBOOT__
> +#include 
> +#include 
> +#endif
> +#include 
> +#include 
> +
> +#define SPINAND_MFR_XTX0x0B
> +
> +#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
> +#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
> +#define XT26XXXD_STATUS_ECC_1_7_CORRECTED   (1)
> +#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
> +#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
> +
> +static SPINAND_OP_VARIANTS(read_cache_variants,
> +   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
> +   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(write_cache_variants,
> +   SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
> +   SPINAND_PROG_LOAD(true, 0, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(update_cache_variants,
> +   SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
> +   SPINAND_PROG_LOAD(false, 0, NULL, 0));
> +
> +static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *region)
> +{
> +   if (section)
> +   return -ERANGE;
> +
> +   region->offset = mtd->oobsize / 2;
> +   region->length = mtd->oobsize / 2;
> +
> +   return 0;
> +}
> +
> +static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
> +  struct mtd_oob_region *region)
> +{
> +   if (section)
> +   return -ERANGE;
> +
> +   region->offset = 2;
> +   region->length = mtd->oobsize / 2 - 2;
> +
> +   return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops xt26xxxd_ooblayout = {
> +   .ecc = xt26xxxd_ooblayout_ecc,
> +   .rfree = xt26xxxd_ooblayout_free,
> +};
> +
> +static int xt26xxxd_ecc_get_status(struct spinand_device *spinand,
> +  u8 status)
> +{
> +   switch (FIELD_GET(STATUS_ECC_MASK, status)) {
> +   case XT26XXXD_STATUS_ECC_NO_DETECTED:
> +   return 0;
> +   case XT26XXXD_STATUS_ECC_UNCOR_ERROR:
> +   return -EBADMSG;
> +   case XT26XXXD_STATUS_ECC_1_7_CORRECTED:
> +   return 4 + FIELD_GET(XT26XXXD_STATUS_ECC3_ECC2_MASK, status);
> +   case 

Re: [PATCH v1 0/4] Introduce mtdblock device

[Frieder Schrempf]

Hi Alexey,

On 27.02.24 11:04, Alexey Romanov wrote:
> Hello!
> 
> This series adds support for the mtdblock device, which
> allows to read/write data block by block. For example,
> it can now be used for BCB or Android AB command:
> 
>   $ bcb load mtd 0 part_name
> 
> Tested only on SPI NAND, so bind is made only for
> SPI NAND drivers.

I don't know much about Android, but as far as I understand you are
trying to store dynamic, boot-related information on the MTD device.

This might be acceptable if the underlying device is a NOR flash, but
for any type of NAND device it sounds like a rather bad idea.

NAND devices need some kind of FTL (flash translation layer) in order to
work reliably. Using a block filesystem directly on the NAND MTD device
will cause problems as soon as any bad blocks or bit flips occur.

People are therefore discouraged to use mtdblock on NAND and in the
kernel there is even a warning if you try to mount a NAND mtdblock
partition.

Maybe you should reconsider this and look into how to use UBIFS as a
FTL. On the other hand I'm not quite sure if the UBIFS layer in U-Boot
is really stable and maintained. So this might not be a good idea either.

Anyway, I'm against implementing mtdblock for SPI NAND (or any other NAND).

Best regards
Frieder