date:20240102

On Tue, Jan 02, 2024 at 10:29:05AM +0100, Patrick Rudolph wrote:

> Hi Tom,
> can you please clarify or point us to some documentation that explains
> the new DT setup?
> I thought the u-boot DT is only used for u-boot internal drivers.

The DT has always supposed to have been the same one as the Linux
Kernel, to make things easier for developers as they would only need one
DT, not two. For systems that use the EFI loader we pass the same DT to
the OS which can simplify life.

> Do we need to upstream the kernel DT first?

If the DT is not upstream it really should be being submitted upstream
and not just never upstreamed. I know this is more challenging in some
cases than others.

> Do we need to provide a complete "kernel DT" to u-boot as well?

That is usually easiest, yes.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 0/9] dts: Move to SoC-specific build rules

On Tue, Jan 02, 2024 at 04:51:34PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, Jan 2, 2024 at 7:55 AM Tom Rini  wrote:
> >
> > On Tue, Jan 02, 2024 at 07:06:36AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, Dec 31, 2023 at 7:01 AM Tom Rini  wrote:
> > > >
> > > > On Sun, Dec 31, 2023 at 05:45:00AM -0700, Simon Glass wrote:
> > > > > -Scott as it is bouncing
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Fri, Dec 29, 2023 at 9:46 AM Peter Robinson  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Dec 29, 2023 at 12:23 AM Tom Rini  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > U-Boot builds devicetree binaries from its source 
> > > > > > > > > > > > > > tree. As part of the
> > > > > > > > > > > > > > Kconfig conversion, the Makefiles were updated to 
> > > > > > > > > > > > > > align with how this
> > > > > > > > > > > > > > is done in Linux: a single target for each SoC is 
> > > > > > > > > > > > > > used to build all the
> > > > > > > > > > > > > > .dtb files for that SoC.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Since then, the Makefiles have devolved in some 
> > > > > > > > > > > > > > cases, resulting in
> > > > > > > > > > > > > > lots of target-specific build rules. Also Linux has 
> > > > > > > > > > > > > > moved to using
> > > > > > > > > > > > > > subdirectories for each vendor.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Recent work aims to allow U-Boot to directly use 
> > > > > > > > > > > > > > devicetree files from
> > > > > > > > > > > > > > Linux. This would be easier if the directory 
> > > > > > > > > > > > > > structure were the same.
> > > > > > > > > > > > > > Another recent discussion involved dropping the 
> > > > > > > > > > > > > > build rules altogether.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This series makes a start at cleaning up some of 
> > > > > > > > > > > > > > the build rules, to
> > > > > > > > > > > > > > reduce the amount of code and make it easier to add 
> > > > > > > > > > > > > > new boards for the
> > > > > > > > > > > > > > same SoC.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options 
> > > > > > > > > > > > > > between U-Boot and Linux
> > > > > > > > > > > > > > are not always the same. Given the large number of 
> > > > > > > > > > > > > > SoCs and boards
> > > > > > > > > > > > > > supported by U-Boot, it would be useful to align 
> > > > > > > > > > > > > > these where possible.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't know why we should start with this now, and 
> > > > > > > > > > > > > further not being on
> > > > > > > > > > > > > top of Sumit's series to remove our duplicate dts 
> > > > > > > > > > > > > files. And that's
> > > > > > > > > > > > > where we can have the conversation about for which 
> > > > > > > > > > > > > cases it even makes
> > > > > > > > > > > > > sense to build all of the dts files for a given SoC.
> > > > > > > > > > > >
> > > > > > > > > > > > This is a completely different series - there are no 
> > > > > > > > > > > > conflicts with
> > > > > > > > > > > > Sumit's series so it can be applied before or after it.
> > > > > > > > > > > >
> > > > > > > > > > > > My goal here is to clean up our build rules, rather 
> > > > > > > > > > > > than just throwing
> > > > > > > > > > > > them all away, for reasons we have discussed 
> > > > > > > > > > > > previously. I filed [1]
> > > > > > > > > > > > to track that.
> > > > > > > > > > >
> > > > > > > > > > > Yes, I'm saying we shouldn't be doing anything this 
> > > > > > > > > > > series does until
> > > > > > > > > > > after Sumit's series has landed. Along with the fact that 
> > > > > > > > > > > I don't like
> > > > > > > > > > > what's going on in this series.
> > > > > > > > > >
> > > > > > > > > > This seems to again be the disagreement over whether a 
> > > > > > > > > > single DT
> > > > > > > > > > should be build for each board, or all the DTs for an SoC?
> > > > > > > > >
> > > > > > > > > It's about the disagreement on what we should be building, 
> > >

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

On Tue, Jan 02, 2024 at 04:54:15PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, Jan 2, 2024 at 8:10 AM Tom Rini  wrote:
> >
> > On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, Jan 1, 2024 at 4:35 PM Tom Rini  wrote:
> > > >
> > > > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > > > Hi Mark, Tom,
> > > > >
> > > > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis 
> > > > >  wrote:
> > > > > >
> > > > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > > > From: Tom Rini 
> > > > > > >
> > > > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > > > Hi Sumit,
> > > > > > > >
> > > > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files 
> > > > > > > > > > > > > > > from devitree-rebasing
> > > > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > > > > > > build then along with any *-u-boot.dtsi file 
> > > > > > > > > > > > > > > present in arch/$(ARCH)/dts
> > > > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This will help easy migration for platforms which 
> > > > > > > > > > > > > > > currently are compliant
> > > > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > > > >   enables a live tree which is available 
> > > > > > > > > > > > > > > after relocation,
> > > > > > > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > > > +   bool "Enable use of devicetree imported 
> > > > > > > > > > > > > > > from Linux kernel release"
> > > > > > > > > > > > > > > +   help
> > > > > > > > > > > > > > > + Traditionally, U-Boot platforms used to 
> > > > > > > > > > > > > > > have their custom devicetree
> > > > > > > > > > > > > > > + files or copy devicetree files from 
> > > > > > > > > > > > > > > Linux kernel which are hard to
> > > > > > > > > > > > > > > + maintain and can usually get 
> > > > > > > > > > > > > > > out-of-sync from Linux kernel. This
> > > > > > > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > > > > > > + a regular sync will be maintained every 
> > > > > > > > > > > > > > > major Linux kernel release
> > > > > > > > > > > > > > > + cycle. However, platforms can still 
> > > > > > > > > > > > > > > have some custom u-boot specific
> > > > > > > > > > > > > > > + bits maintained as part of 
> > > > > > > > > > > > > >

[PATCH 19/19] sunxi: SPL pinmux: rewrite UART setup without #ifdefs

The existing SPL UART pinmux setup is using #ifdef's heavily, which
makes it hard to read and even harder to extend.

Replace the #ifdef's with proper C "if" statements, with the help of the
magic IS_ENABLED() macro.

To cover the non-configured case, which is currently handled by
an #error preprocessor directive, create a prototype for a non-existing
function. Replace that #error line with a call to that function, which
will be removed by the compiler and linker in the normal case, but will
cause a linker error otherwise.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/uart_pinmux.c | 240 --
 1 file changed, 128 insertions(+), 112 deletions(-)

diff --git a/arch/arm/mach-sunxi/uart_pinmux.c 
b/arch/arm/mach-sunxi/uart_pinmux.c
index cb4b16f0e37..ba42352fbcf 100644
--- a/arch/arm/mach-sunxi/uart_pinmux.c
+++ b/arch/arm/mach-sunxi/uart_pinmux.c
@@ -15,128 +15,144 @@
 #include 
 #include 
 
-void uart0_portf_pinmux_setup(void)
+/* Non-existing function to trigger speaking link error. */
+void Unsupported_console_number_Please_fix_UART_pin_mux_settings(void);
+
+static void uart0_portf_pinmux_setup(void)
 {
-#if defined(CONFIG_MACH_SUN4I) || \
-defined(CONFIG_MACH_SUN7I) || \
-defined(CONFIG_MACH_SUN8I_R40)
-   /* disable GPB22,23 as uart0 tx,rx to avoid conflict */
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
-#endif
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) || \
-defined(CONFIG_MACH_SUN7I) || defined(CONFIG_MACH_SUN8I_R40) || \
-defined(CONFIG_MACH_SUN9I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
-#else
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
-#endif
+   if (IS_ENABLED(CONFIG_MACH_SUN4I) || IS_ENABLED(CONFIG_MACH_SUN7I) ||
+   IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
+   /* disable GPB22,23 as uart0 tx,rx to avoid conflict */
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
+   }
+
+   if (IS_ENABLED(CONFIG_MACH_SUN4I) || IS_ENABLED(CONFIG_MACH_SUN5I) ||
+   IS_ENABLED(CONFIG_MACH_SUN7I) || IS_ENABLED(CONFIG_MACH_SUN8I_R40) 
||
+   IS_ENABLED(CONFIG_MACH_SUN9I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF_UART0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
+   } else {
+   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
+   }
sunxi_gpio_set_pull(SUNXI_GPF(4), SUNXI_GPIO_PULL_UP);
 }
 
-void uart0_pinmux_setup(void)
+static void uart0_pinmux_setup(void)
 {
-#if defined(CONFIG_MACH_SUNIV)
-   sunxi_gpio_set_cfgpin(SUNXI_GPE(0), SUNIV_GPE_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPE(1), SUNIV_GPE_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPE(1), SUNXI_GPIO_PULL_UP);
-#elif (defined(CONFIG_MACH_SUN4I) || \
-defined(CONFIG_MACH_SUN7I) || \
-defined(CONFIG_MACH_SUN8I_R40))
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUN5I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN5I_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(20), SUN5I_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(20), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUN6I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(20), SUN6I_GPH_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(21), SUN6I_GPH_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPH(21), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUN8I_A33)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_A33_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_A33_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUNXI_H3_H5)
-   sunxi_gpio_set_cfgpin(SUNXI_GPA(4), SUN8I_H3_GPA_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPA(5), SUN8I_H3_GPA_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPA(5), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUN50I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(8), SUN50I_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN50I_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(9), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUN50I_H6)
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H6_GPH_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H6_GPH_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
-#elif defined(CONFIG_MACH_SUN50I_H616)
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H616_GPH_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H616_GPH_UART0);
-

[PATCH 18/19] sunxi: SPL pinmux: split out UART pinmux per port

The UART SPL pinmux function is particularly hard to read, as it
combines per-SoC definitions with per-configuration choices (which UART
to use).

Split the existing single function into one per UART port, to reduce
the #ifdef hell and improve readability. The four cases which deal with
UARTs other than 0 or 1 are left in the main function, to reduce
clutter.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/uart_pinmux.c | 66 ---
 1 file changed, 42 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-sunxi/uart_pinmux.c 
b/arch/arm/mach-sunxi/uart_pinmux.c
index af5ecc4fb3c..cb4b16f0e37 100644
--- a/arch/arm/mach-sunxi/uart_pinmux.c
+++ b/arch/arm/mach-sunxi/uart_pinmux.c
@@ -15,9 +15,8 @@
 #include 
 #include 
 
-void uart_pinmux_setup(void)
+void uart0_portf_pinmux_setup(void)
 {
-#if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
 #if defined(CONFIG_MACH_SUN4I) || \
 defined(CONFIG_MACH_SUN7I) || \
 defined(CONFIG_MACH_SUN8I_R40)
@@ -35,68 +34,92 @@ void uart_pinmux_setup(void)
sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
 #endif
sunxi_gpio_set_pull(SUNXI_GPF(4), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUNIV)
+}
+
+void uart0_pinmux_setup(void)
+{
+#if defined(CONFIG_MACH_SUNIV)
sunxi_gpio_set_cfgpin(SUNXI_GPE(0), SUNIV_GPE_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPE(1), SUNIV_GPE_UART0);
sunxi_gpio_set_pull(SUNXI_GPE(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || \
-defined(CONFIG_MACH_SUN7I) || \
-defined(CONFIG_MACH_SUN8I_R40))
+#elif (defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40))
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN5I)
+#elif defined(CONFIG_MACH_SUN5I)
sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN5I_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(20), SUN5I_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(20), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN6I)
+#elif defined(CONFIG_MACH_SUN6I)
sunxi_gpio_set_cfgpin(SUNXI_GPH(20), SUN6I_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(21), SUN6I_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(21), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_A33)
+#elif defined(CONFIG_MACH_SUN8I_A33)
sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_A33_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_A33_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUNXI_H3_H5)
+#elif defined(CONFIG_MACH_SUNXI_H3_H5)
sunxi_gpio_set_cfgpin(SUNXI_GPA(4), SUN8I_H3_GPA_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPA(5), SUN8I_H3_GPA_UART0);
sunxi_gpio_set_pull(SUNXI_GPA(5), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I)
+#elif defined(CONFIG_MACH_SUN50I)
sunxi_gpio_set_cfgpin(SUNXI_GPB(8), SUN50I_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN50I_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(9), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I_H6)
+#elif defined(CONFIG_MACH_SUN50I_H6)
sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H6_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H6_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I_H616)
+#elif defined(CONFIG_MACH_SUN50I_H616)
sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H616_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H616_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_A83T)
+#elif defined(CONFIG_MACH_SUN8I_A83T)
sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN8I_A83T_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(10), SUN8I_A83T_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(10), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_V3S)
+#elif defined(CONFIG_MACH_SUN8I_V3S)
sunxi_gpio_set_cfgpin(SUNXI_GPB(8), SUN8I_V3S_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN8I_V3S_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(9), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN9I)
+#elif defined(CONFIG_MACH_SUN9I)
sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 &&

[PATCH 17/19] sunxi: move UART pinmux setup into separate file

The code that programs the pinmuxes for the configured UART dominates
the gpio_init() function, and is only needed by SPL code.

Move those lines into a separate function in a new file, that gets
compiled for the SPL only.

That simplifies further cleanup, and helps to separate SPL-only code
from generic code.
To help review, this only copies the code (generating some checkpatch
complaints), further cleanup will be provided in subsequent patches.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Makefile  |   1 +
 arch/arm/mach-sunxi/board.c   | 110 ++
 arch/arm/mach-sunxi/uart_pinmux.c | 124 ++
 3 files changed, 130 insertions(+), 105 deletions(-)
 create mode 100644 arch/arm/mach-sunxi/uart_pinmux.c

diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index c15ef01aaad..9a9dffc176f 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -32,6 +32,7 @@ endif
 ifdef CONFIG_SPL_BUILD
 obj-y  += clock.o
 obj-y  += spl_pinmux.o
+obj-y  += uart_pinmux.o
 obj-$(CONFIG_MACH_SUNIV)   += dram_suniv.o
 obj-$(CONFIG_DRAM_SUN4I)   += dram_sun4i.o
 obj-$(CONFIG_DRAM_SUN6I)   += dram_sun6i.o
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0140b07d32a..dd642c0d2f0 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -75,113 +75,13 @@ phys_addr_t board_get_usable_ram_top(phys_size_t 
total_size)
 #endif /* CONFIG_ARM64 */
 
 #ifdef CONFIG_SPL_BUILD
+void uart_pinmux_setup(void);
+
 static int gpio_init(void)
 {
-   __maybe_unused uint val;
-#if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
-#if defined(CONFIG_MACH_SUN4I) || \
-defined(CONFIG_MACH_SUN7I) || \
-defined(CONFIG_MACH_SUN8I_R40)
-   /* disable GPB22,23 as uart0 tx,rx to avoid conflict */
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
-#endif
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) || \
-defined(CONFIG_MACH_SUN7I) || defined(CONFIG_MACH_SUN8I_R40) || \
-defined(CONFIG_MACH_SUN9I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
-#else
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
-#endif
-   sunxi_gpio_set_pull(SUNXI_GPF(4), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUNIV)
-   sunxi_gpio_set_cfgpin(SUNXI_GPE(0), SUNIV_GPE_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPE(1), SUNIV_GPE_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPE(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || \
-defined(CONFIG_MACH_SUN7I) || \
-defined(CONFIG_MACH_SUN8I_R40))
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN5I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN5I_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(20), SUN5I_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(20), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN6I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(20), SUN6I_GPH_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(21), SUN6I_GPH_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPH(21), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_A33)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_A33_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_A33_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUNXI_H3_H5)
-   sunxi_gpio_set_cfgpin(SUNXI_GPA(4), SUN8I_H3_GPA_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPA(5), SUN8I_H3_GPA_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPA(5), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(8), SUN50I_GPB_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN50I_GPB_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPB(9), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I_H6)
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H6_GPH_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H6_GPH_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I_H616)
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H616_GPH_UART0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H616_GPH_UART0);
-   sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);

[PATCH 16/19] sunxi: SPL pinmux: rewrite without #ifdefs

At the moment the SPL functions setting up the required pinmux for the
UART, NAND and MMC controllers make heavy use of #ifdefs, which are
sometimes even nested. This makes them hard to read, and more
importantly hard to extend.

Rewrite those functions with the help of IS_ENABLED(), to use proper C
"if" statements. For the I2C case, also split the function up into one
per I2C controller, to further simplify the code layout.

The MMC function gets further simplified, by replacing the repeated direct
calls to the GPIO functions with using variables, that describe a range of
pins to handle, including skipped pins and outliers. The actual pinmux
functions are then called from one place.

One part of the NAND clock setup relies on SoC specific struct members,
so that has to keep using #ifdefs, to avoid breaking compilation for
other SoCs.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/spl_pinmux.c | 434 +++
 1 file changed, 210 insertions(+), 224 deletions(-)

diff --git a/arch/arm/mach-sunxi/spl_pinmux.c b/arch/arm/mach-sunxi/spl_pinmux.c
index 45cc2cfe2b1..18f8cd93b6a 100644
--- a/arch/arm/mach-sunxi/spl_pinmux.c
+++ b/arch/arm/mach-sunxi/spl_pinmux.c
@@ -17,95 +17,105 @@
 #include 
 #include 
 
+static void i2c0_init_board(void)
+{
+   if (IS_ENABLED(CONFIG_MACH_SUN4I) || IS_ENABLED(CONFIG_MACH_SUN5I) ||
+   IS_ENABLED(CONFIG_MACH_SUN7I) || IS_ENABLED(CONFIG_MACH_SUN8I_R40)) 
{
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN4I_GPB_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN4I_GPB_TWI0);
+   clock_twi_onoff(0, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN6I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(14), SUN6I_GPH_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(15), SUN6I_GPH_TWI0);
+   clock_twi_onoff(0, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(6), SUN8I_V3S_GPB_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(7), SUN8I_V3S_GPB_TWI0);
+   clock_twi_onoff(0, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN8I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN8I_GPH_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN8I_GPH_TWI0);
+   clock_twi_onoff(0, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN50I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_GPH_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_GPH_TWI0);
+   clock_twi_onoff(0, 1);
+   }
+}
+
+static void i2c1_init_board(void)
+{
+   if (IS_ENABLED(CONFIG_MACH_SUN4I) || IS_ENABLED(CONFIG_MACH_SUN7I) ||
+   IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(18), SUN4I_GPB_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN4I_GPB_TWI1);
+   clock_twi_onoff(1, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN5I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(15), SUN5I_GPB_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(16), SUN5I_GPB_TWI1);
+   clock_twi_onoff(1, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN6I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(16), SUN6I_GPH_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(17), SUN6I_GPH_TWI1);
+   clock_twi_onoff(1, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN8I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(4), SUN8I_GPH_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(5), SUN8I_GPH_TWI1);
+   clock_twi_onoff(1, 1);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN50I)) {
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN50I_GPH_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN50I_GPH_TWI1);
+   clock_twi_onoff(1, 1);
+   }
+}
+
+static void i2cr_init_board(void)
+{
+   if (IS_ENABLED(CONFIG_MACH_SUN50I)) {
+   clock_twi_onoff(5, 1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(8), SUN50I_GPL_R_TWI);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(9), SUN50I_GPL_R_TWI);
+   } else if (IS_ENABLED(CONFIG_MACH_SUN50I_H616)) {
+   clock_twi_onoff(5, 1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN50I_H616_GPL_R_TWI);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(1), SUN50I_H616_GPL_R_TWI);
+   } else {
+   clock_twi_onoff(5, 1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN8I_H3_GPL_R_TWI);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(1), SUN8I_H3_GPL_R_TWI);
+   }
+}
+
 void i2c_init_board(void)
 {
-#ifdef CONFIG_I2C0_ENABLE
-#if defined(CONFIG_MACH_SUN4I) || \
-defined(CONFIG_MACH_SUN5I) || \
-defined(CONFIG_MACH_SUN7I) || \
-defined(CONFIG_MACH_SUN8I_R40)
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN4I_GPB_TWI0);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN4I_GPB_TWI0);
-   clock_twi_onoff(0, 1);
-#elif defined(CONFIG_MACH_SUN6I)
-

[PATCH 15/19] sunxi: move pinmux setup into separate SPL only file

At the moment the board/sunxi/board.c file contains a number of pinmux
setup functions, that are only called by the SPL, to program the
configured pins for the UART, NAND or eMMC devices.

Move those functions into a separate file, to help keeping the board.c
file clean, and allow compiling this new file for the SPL only.

To help review, this file is as much copy as possible. This raises
some checkpatch complaints, but this will be fixed and further cleanup
will be provided in a subsequent patch.
Right now we just add some comments to some #endif's to mark nested
regions. It also removes a now redundant CONFIG_SPL_BUILD guard, and fixes
a whitespace problem for the R528 eMMC setup.

The new file is placed in arch/arm/mach-sunxi, as the plan is to keep
all (legacy) SPL code in there.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Makefile |   1 +
 arch/arm/mach-sunxi/spl_pinmux.c | 326 +++
 board/sunxi/board.c  | 309 +
 3 files changed, 328 insertions(+), 308 deletions(-)
 create mode 100644 arch/arm/mach-sunxi/spl_pinmux.c

diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 3f83c0280ef..c15ef01aaad 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -31,6 +31,7 @@ endif
 
 ifdef CONFIG_SPL_BUILD
 obj-y  += clock.o
+obj-y  += spl_pinmux.o
 obj-$(CONFIG_MACH_SUNIV)   += dram_suniv.o
 obj-$(CONFIG_DRAM_SUN4I)   += dram_sun4i.o
 obj-$(CONFIG_DRAM_SUN6I)   += dram_sun6i.o
diff --git a/arch/arm/mach-sunxi/spl_pinmux.c b/arch/arm/mach-sunxi/spl_pinmux.c
new file mode 100644
index 000..45cc2cfe2b1
--- /dev/null
+++ b/arch/arm/mach-sunxi/spl_pinmux.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 Arm Ltd.
+ * (C) Copyright 2012-2013 Henrik Nordstrom 
+ * (C) Copyright 2013 Luke Kenneth Casson Leighton 
+ * (C) Copyright 2007-2011
+ * Allwinner Technology Co., Ltd. 
+ * Tom Cubie 
+ *
+ * Code to setup pinmux configuration in the SPL, which lacks the DT to
+ * look this up properly.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void i2c_init_board(void)
+{
+#ifdef CONFIG_I2C0_ENABLE
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN5I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN4I_GPB_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN4I_GPB_TWI0);
+   clock_twi_onoff(0, 1);
+#elif defined(CONFIG_MACH_SUN6I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(14), SUN6I_GPH_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(15), SUN6I_GPH_TWI0);
+   clock_twi_onoff(0, 1);
+#elif defined(CONFIG_MACH_SUN8I_V3S)
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(6), SUN8I_V3S_GPB_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(7), SUN8I_V3S_GPB_TWI0);
+   clock_twi_onoff(0, 1);
+#elif defined(CONFIG_MACH_SUN8I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN8I_GPH_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN8I_GPH_TWI0);
+   clock_twi_onoff(0, 1);
+#elif defined(CONFIG_MACH_SUN50I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_GPH_TWI0);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_GPH_TWI0);
+   clock_twi_onoff(0, 1);
+#endif
+#endif /* CONFIG_I2C0_ENABLE */
+
+#ifdef CONFIG_I2C1_ENABLE
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(18), SUN4I_GPB_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN4I_GPB_TWI1);
+   clock_twi_onoff(1, 1);
+#elif defined(CONFIG_MACH_SUN5I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(15), SUN5I_GPB_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(16), SUN5I_GPB_TWI1);
+   clock_twi_onoff(1, 1);
+#elif defined(CONFIG_MACH_SUN6I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(16), SUN6I_GPH_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(17), SUN6I_GPH_TWI1);
+   clock_twi_onoff(1, 1);
+#elif defined(CONFIG_MACH_SUN8I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(4), SUN8I_GPH_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(5), SUN8I_GPH_TWI1);
+   clock_twi_onoff(1, 1);
+#elif defined(CONFIG_MACH_SUN50I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN50I_GPH_TWI1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN50I_GPH_TWI1);
+   clock_twi_onoff(1, 1);
+#endif
+#endif /* CONFIG_I2C1_ENABLE */
+
+#ifdef CONFIG_R_I2C_ENABLE
+#ifdef CONFIG_MACH_SUN50I
+   clock_twi_onoff(5, 1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(8), SUN50I_GPL_R_TWI);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(9), SUN50I_GPL_R_TWI);
+#elif defined(CONFIG_MACH_SUN50I_H616)
+   clock_twi_onoff(5, 1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN50I_H616_GPL_R_TWI);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(1), SUN50I_H616_GPL_R_TWI);
+#else
+   clock_twi_onoff(5, 1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN8I_H3_GPL_R_TWI);
+

[PATCH 14/19] sunxi: sun9i: make more clock functions SPL only

In clock_sun9i.c, responsible for (mostly early) clock setup on the
Allwinner A80 SoC, many functions are only needed by the SPL, and are
thus already guarded by CONFIG_SPL_BUILD.

Over the years drivers like for the UART or I2C were converted to DM, and
they care about clock setup themselves now, by using a proper DM clock
driver.

This means those devices need the clock setup functions here for the SPL
only. Move some functions around, to group all SPL-only function within
one #ifdef guard. Some functions were exported, but never used outside
of this file, so remove their prototypes from the header file and mark
them as static.

This avoids unnecessary code in U-Boot proper and helps further
refactoring. Add some comments on the way to help understanding of the
file.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/clock_sun9i.h |  3 -
 arch/arm/mach-sunxi/clock_sun9i.c | 97 +--
 2 files changed, 48 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
index fe6b8ba2732..0264bfe1c50 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
@@ -220,10 +220,7 @@ struct sunxi_ccm_reg {
 
 #ifndef __ASSEMBLY__
 void clock_set_pll1(unsigned int clk);
-void clock_set_pll2(unsigned int clk);
-void clock_set_pll4(unsigned int clk);
 void clock_set_pll6(unsigned int clk);
-void clock_set_pll12(unsigned int clk);
 unsigned int clock_get_pll4_periph0(void);
 #endif
 
diff --git a/arch/arm/mach-sunxi/clock_sun9i.c 
b/arch/arm/mach-sunxi/clock_sun9i.c
index edaff9a28ce..5913e40cb65 100644
--- a/arch/arm/mach-sunxi/clock_sun9i.c
+++ b/arch/arm/mach-sunxi/clock_sun9i.c
@@ -17,6 +17,52 @@
 
 #ifdef CONFIG_SPL_BUILD
 
+static void clock_set_pll2(unsigned int clk)
+{
+   struct sunxi_ccm_reg * const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+   const int p = 0;
+
+   /* Switch cluster 1 to 24MHz clock while changing PLL2 */
+   clrsetbits_le32(>cpu_clk_source, C1_CPUX_CLK_SRC_MASK,
+   C1_CPUX_CLK_SRC_OSC24M);
+
+   writel(CCM_PLL2_CTRL_EN | CCM_PLL2_CTRL_P(p) |
+  CCM_PLL2_CLOCK_TIME_2 | CCM_PLL2_CTRL_N(clk / 2400),
+  >pll2_c1_cfg);
+
+   sdelay(2000);
+
+   /* Switch cluster 1 back to PLL2 */
+   clrsetbits_le32(>cpu_clk_source, C1_CPUX_CLK_SRC_MASK,
+   C1_CPUX_CLK_SRC_PLL2);
+}
+
+static void clock_set_pll4(unsigned int clk)
+{
+   struct sunxi_ccm_reg * const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   writel(CCM_PLL4_CTRL_EN | CCM_PLL4_CTRL_N(clk / 2400),
+  >pll4_periph0_cfg);
+
+   sdelay(2000);
+}
+
+static void clock_set_pll12(unsigned int clk)
+{
+   struct sunxi_ccm_reg * const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   if (readl(>pll12_periph1_cfg) & CCM_PLL12_CTRL_EN)
+   return;
+
+   writel(CCM_PLL12_CTRL_EN | CCM_PLL12_CTRL_N(clk / 2400),
+  >pll12_periph1_cfg);
+
+   sdelay(2000);
+}
+
 void clock_init_safe(void)
 {
struct sunxi_ccm_reg * const ccm =
@@ -63,7 +109,6 @@ void clock_init_safe(void)
/* set enable-bit in TSTAMP_CTRL_REG */
writel(1, 0x0172);
 }
-#endif
 
 void clock_init_uart(void)
 {
@@ -80,7 +125,6 @@ void clock_init_uart(void)
   CONFIG_CONS_INDEX - 1));
 }
 
-#ifdef CONFIG_SPL_BUILD
 void clock_set_pll1(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
@@ -108,27 +152,6 @@ void clock_set_pll1(unsigned int clk)
C0_CPUX_CLK_SRC_PLL1);
 }
 
-void clock_set_pll2(unsigned int clk)
-{
-   struct sunxi_ccm_reg * const ccm =
-   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   const int p = 0;
-
-   /* Switch cluster 1 to 24MHz clock while changing PLL2 */
-   clrsetbits_le32(>cpu_clk_source, C1_CPUX_CLK_SRC_MASK,
-   C1_CPUX_CLK_SRC_OSC24M);
-
-   writel(CCM_PLL2_CTRL_EN | CCM_PLL2_CTRL_P(p) |
-  CCM_PLL2_CLOCK_TIME_2 | CCM_PLL2_CTRL_N(clk / 2400),
-  >pll2_c1_cfg);
-
-   sdelay(2000);
-
-   /* Switch cluster 1 back to PLL2 */
-   clrsetbits_le32(>cpu_clk_source, C1_CPUX_CLK_SRC_MASK,
-   C1_CPUX_CLK_SRC_PLL2);
-}
-
 void clock_set_pll6(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
@@ -143,32 +166,6 @@ void clock_set_pll6(unsigned int clk)
sdelay(2000);
 }
 
-void clock_set_pll12(unsigned int clk)
-{
-   struct sunxi_ccm_reg * const ccm =
-   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
-   if (readl(>pll12_periph1_cfg) & CCM_PLL12_CTRL_EN)
-   return;
-
-   writel(CCM_PLL12_CTRL_EN | CCM_PLL12_CTRL_N(clk / 2400),
-  >pll12_periph1_cfg);
-
-   sdelay(2000);
-}
-
-
-void clock_set_pll4(unsigned int clk)

[PATCH 13/19] sunxi: sun8i_a83t: make more clock functions SPL only

In clock_sun8i_a83t.c, responsible for (mostly early) clock setup on the
Allwinner A83T SoC, many functions are only needed by the SPL, and are
thus already guarded by CONFIG_SPL_BUILD.

Over the years drivers like for the UART or I2C were converted to DM,
so they care about clock setup themselves now, by using a proper DM clock
driver.

This means those devices need the clock setup functions here for the SPL
only. Include those functions into the existing CONFIG_SPL_BUILD guards,
so they are compiled for the SPL only.

This avoids unnecessary code in U-Boot proper and helps further
refactoring. Add some comments on the way to help understanding of the
file.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/clock_sun8i_a83t.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/clock_sun8i_a83t.c 
b/arch/arm/mach-sunxi/clock_sun8i_a83t.c
index 198fe9dbd73..9eeba084f95 100644
--- a/arch/arm/mach-sunxi/clock_sun8i_a83t.c
+++ b/arch/arm/mach-sunxi/clock_sun8i_a83t.c
@@ -46,7 +46,6 @@ void clock_init_safe(void)
/* timestamp */
writel(1, 0x0172);
 }
-#endif
 
 void clock_init_uart(void)
 {
@@ -70,7 +69,6 @@ void clock_init_uart(void)
   CONFIG_CONS_INDEX - 1));
 }
 
-#ifdef CONFIG_SPL_BUILD
 void clock_set_pll1(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
@@ -102,8 +100,9 @@ void clock_set_pll1(unsigned int clk)
CPU_CLK_SRC_PLL1 << C1_CPUX_CLK_SRC_SHIFT,
   >cpu_axi_cfg);
 }
-#endif
+#endif /* CONFIG_SPL_BUILD */
 
+/* DRAM and PLL_PERIPH0 clock (used by the MMC driver) */
 void clock_set_pll5(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
-- 
2.35.8

[PATCH 12/19] sunxi: sun50i_h6: make more clock functions SPL only

In clock_sun50i_h6.c, responsible for (mostly early) clock setup on
newer generation Allwinner SoCs, many functions are only needed by the
SPL, and are thus already guarded by CONFIG_SPL_BUILD.

Over the years drivers like for the UART or I2C were converted to DM,
so they care about clock setup themselves now, by using a proper DM clock
driver.

This means those devices need the clock setup functions here for the SPL
only. Include those functions into the existing CONFIG_SPL_BUILD guards,
so they are compiled for the SPL only. By moving the clock_get_pll6()
function to the end of the file, all SPL-only clocks can be contained
within one #ifdef guard.

This avoids unnecessary code in U-Boot proper and helps further
refactoring. Add some comments on the way to help understanding of the
file.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/clock_sun50i_h6.c | 57 +--
 1 file changed, 28 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c 
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index dac3663e1be..cc2ee336416 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -51,7 +51,6 @@ void clock_init_safe(void)
 */
writel(MBUS_CLK_SRC_PLL6X2 | MBUS_CLK_M(3), >mbus_cfg);
 }
-#endif
 
 void clock_init_uart(void)
 {
@@ -73,7 +72,6 @@ void clock_init_uart(void)
 1 << (RESET_SHIFT + CONFIG_CONS_INDEX - 1));
 }
 
-#ifdef CONFIG_SPL_BUILD
 void clock_set_pll1(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
@@ -105,33 +103,6 @@ void clock_set_pll1(unsigned int clk)
val |= CCM_CPU_AXI_MUX_PLL_CPUX;
writel(val, >cpu_axi_cfg);
 }
-#endif
-
-unsigned int clock_get_pll6(void)
-{
-   struct sunxi_ccm_reg *const ccm =
-   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   uint32_t rval = readl(>pll6_cfg);
-   int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
-   int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
-   CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
-   int div1, m;
-
-   if (IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2)) {
-   div1 = ((rval & CCM_PLL6_CTRL_P0_MASK) >>
-   CCM_PLL6_CTRL_P0_SHIFT) + 1;
-   m = 1;
-   } else {
-   div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
-   CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
-   if (IS_ENABLED(CONFIG_MACH_SUN50I_H6))
-   m = 4;
-   else
-   m = 2;
-   }
-
-   return 2400U * n / m / div1 / div2;
-}
 
 int clock_twi_onoff(int port, int state)
 {
@@ -160,3 +131,31 @@ int clock_twi_onoff(int port, int state)
 
return 0;
 }
+#endif /* CONFIG_SPL_BUILD */
+
+/* PLL_PERIPH0 clock, used by the MMC driver */
+unsigned int clock_get_pll6(void)
+{
+   struct sunxi_ccm_reg *const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+   uint32_t rval = readl(>pll6_cfg);
+   int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
+   int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
+   CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
+   int div1, m;
+
+   if (IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2)) {
+   div1 = ((rval & CCM_PLL6_CTRL_P0_MASK) >>
+   CCM_PLL6_CTRL_P0_SHIFT) + 1;
+   m = 1;
+   } else {
+   div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
+   CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
+   if (IS_ENABLED(CONFIG_MACH_SUN50I_H6))
+   m = 4;
+   else
+   m = 2;
+   }
+
+   return 2400U * n / m / div1 / div2;
+}
-- 
2.35.8

[PATCH 11/19] sunxi: sun6i: make more clock functions SPL only

In clock_sun6i.c, responsible for (mostly early) clock setup on older
generation Allwinner SoCs, many functions are only needed by the SPL,
and are thus already guarded by CONFIG_SPL_BUILD.

Over the years drivers like for the UART or I2C were converted to DM,
so they care about clock setup themselves now, by using a proper DM clock
driver.

This means those devices need the clock setup functions here for the SPL
only. Include those functions into the existing CONFIG_SPL_BUILD guards,
so they are compiled for the SPL only.

This avoids unnecessary code in U-Boot proper and helps further
refactoring. Add some comments on the way to help understanding of the
file.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/clock_sun6i.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index aad9df282ec..59f7e15ffe8 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -62,7 +62,6 @@ void clock_init_safe(void)
setbits_le32(>sata_clk_cfg, CCM_SATA_CTRL_ENABLE);
 #endif
 }
-#endif /* CONFIG_SPL_BUILD */
 
 void clock_init_sec(void)
 {
@@ -124,7 +123,6 @@ void clock_init_uart(void)
 #endif
 }
 
-#ifdef CONFIG_SPL_BUILD
 void clock_set_pll1(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
@@ -173,6 +171,7 @@ void clock_set_pll1(unsigned int clk)
 }
 #endif /* CONFIG_SPL_BUILD */
 
+/* video, DRAM, PLL_PERIPH clocks */
 void clock_set_pll3(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
-- 
2.35.8

[PATCH 10/19] sunxi: sun4i: make more clock functions SPL only

In clock_sun4i.c, responsible for (mostly early) clock setup on early
generation Allwinner SoCs, many functions are only needed by the SPL,
and are thus already guarded by CONFIG_SPL_BUILD.

Over the years drivers like for the UART or I2C were converted to DM,
so they care about clock setup themselves now, by using a proper DM clock
driver.

This means those devices need the clock setup functions here for the SPL
only. Include those functions into the existing CONFIG_SPL_BUILD guards,
so they are compiled for the SPL only.

This avoids unnecessary code in U-Boot proper and helps further
refactoring. Add some comments on the way to help understanding of the
file.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/clock_sun4i.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/clock_sun4i.c 
b/arch/arm/mach-sunxi/clock_sun4i.c
index 8f1d1b65f00..eead5a924f4 100644
--- a/arch/arm/mach-sunxi/clock_sun4i.c
+++ b/arch/arm/mach-sunxi/clock_sun4i.c
@@ -41,7 +41,6 @@ void clock_init_safe(void)
setbits_le32(>pll6_cfg, 0x1 << CCM_PLL6_CTRL_SATA_EN_SHIFT);
 #endif
 }
-#endif
 
 void clock_init_uart(void)
 {
@@ -75,7 +74,6 @@ int clock_twi_onoff(int port, int state)
return 0;
 }
 
-#ifdef CONFIG_SPL_BUILD
 #define PLL1_CFG(N, K, M, P)   ( 1 << CCM_PLL1_CFG_ENABLE_SHIFT | \
  0 << CCM_PLL1_CFG_VCO_RST_SHIFT |  \
  8 << CCM_PLL1_CFG_VCO_BIAS_SHIFT | \
@@ -175,8 +173,9 @@ void clock_set_pll1(unsigned int hz)
   >cpu_ahb_apb0_cfg);
sdelay(20);
 }
-#endif
+#endif /* CONFIG_SPL_BUILD */
 
+/* video, DRAM, PLL_PERIPH clocks */
 void clock_set_pll3(unsigned int clk)
 {
struct sunxi_ccm_reg * const ccm =
-- 
2.35.8

[PATCH 09/19] sunxi: compile clock.c for SPL only

With the clock_twi_onoff() function now being called only from the SPL,
the whole clock.c file in arch/arm/mach-sunxi is needed by SPL code
only.

Remove the redundant #ifdef from the clock_init() function, actually
this function was already only called from the SPL.
Then adjust the Makefile to compile clock.c only with CONFIG_SPL_BUILD
defined.

This avoids unnecessary code in U-Boot proper and allows further
refactoring and code-split between the SPL and U-Boot proper.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Makefile | 2 +-
 arch/arm/mach-sunxi/clock.c  | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 1d4c70ec352..3f83c0280ef 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -7,7 +7,6 @@
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
 obj-y  += board.o
-obj-y  += clock.o
 obj-y  += cpu_info.o
 obj-y  += dram_helpers.o
 obj-$(CONFIG_SUN6I_PRCM)   += prcm.o
@@ -31,6 +30,7 @@ obj-y += timer.o
 endif
 
 ifdef CONFIG_SPL_BUILD
+obj-y  += clock.o
 obj-$(CONFIG_MACH_SUNIV)   += dram_suniv.o
 obj-$(CONFIG_DRAM_SUN4I)   += dram_sun4i.o
 obj-$(CONFIG_DRAM_SUN6I)   += dram_sun6i.o
diff --git a/arch/arm/mach-sunxi/clock.c b/arch/arm/mach-sunxi/clock.c
index b6c68c94f67..5e9fa0d0748 100644
--- a/arch/arm/mach-sunxi/clock.c
+++ b/arch/arm/mach-sunxi/clock.c
@@ -23,10 +23,8 @@ __weak void gtbus_init(void)
 
 int clock_init(void)
 {
-#ifdef CONFIG_SPL_BUILD
clock_init_safe();
gtbus_init();
-#endif
clock_init_uart();
clock_init_sec();
 
-- 
2.35.8

[PATCH 08/19] sunxi: remove unneeded i2c_init_board() call for U-Boot proper

The driver used for the Allwinner I2C IP is using proper DT and DM
enablement for a while: we enable the clock gate and de-assert the reset
line in the driver's probe() routine, and the pinmux setup is taken care
of by the DM framework.

This means the explicit call to the i2c_init_board() routine is not
needed for U-Boot proper. As the board_init() function in board.c is
only called for U-Boot proper, we can remove the call, something that
the comment there hinted at already.

Fix the comment for the board_init() function on the way: we were not
really doing board specific setup there. The fact that this function
is called from U-Boot proper only is probably more helpful for reasoning
about this code.

Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 8c12c8deade..1313b01dcea 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -186,7 +186,7 @@ enum env_location env_get_location(enum env_operation op, 
int prio)
return ENVL_UNKNOWN;
 }
 
-/* add board specific code here */
+/* called only from U-Boot proper */
 int board_init(void)
 {
__maybe_unused int id_pfr1, ret;
@@ -226,13 +226,6 @@ int board_init(void)
if (ret)
return ret;
 
-#if CONFIG_IS_ENABLED(DM_I2C)
-   /*
-* Temporary workaround for enabling I2C clocks until proper sunxi DM
-* clk, reset and pinctrl drivers land.
-*/
-   i2c_init_board();
-#endif
eth_init_board();
 
return 0;
-- 
2.35.8

[PATCH 07/19] sunxi: simplify U-Boot proper only builds

At the moment every Allwinner board builds and requires an SPL, even
though we select this individually in each _defconfig file.
For experiments and for early bringup of new SoCs it would be beneficial
to only build U-Boot proper, for instance to postpone a tedious SPL port
(including DRAM support) in the initial phase.

Protect some SPL related symbols that we unconditionally select at the
moment with "if SPL", to avoid Kconfig conflicts when CONFIG_SPL is
disabled.

This alone does not cleanly build U-Boot proper only yet, but gets it
far enough so that the binary can be harvested.

Signed-off-by: Andre Przywara 
---
 arch/arm/Kconfig|  4 ++--
 arch/arm/mach-sunxi/Kconfig | 16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d812685c984..adce50c66a4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1143,14 +1143,14 @@ config ARCH_SUNXI
select SPL_SEPARATE_BSS if SPL
select SPL_STACK_R if SPL
select SPL_SYS_MALLOC_SIMPLE if SPL
-   select SPL_SYS_THUMB_BUILD if !ARM64
+   select SPL_SYS_THUMB_BUILD if SPL && !ARM64
select SUNXI_GPIO
select SYS_NS16550
select SYS_THUMB_BUILD if !ARM64
select USB if DISTRO_DEFAULTS
select USB_KEYBOARD if DISTRO_DEFAULTS && USB_HOST
select USB_STORAGE if DISTRO_DEFAULTS && USB_HOST
-   select SPL_USE_TINY_PRINTF
+   select SPL_USE_TINY_PRINTF if SPL
select USE_PREBOOT
select SYS_RELOC_GD_ENV_ADDR
imply BOARD_LATE_INIT
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index a4a8d8e9445..421a48bc357 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -182,7 +182,7 @@ config SUNXI_GEN_SUN6I
 config SUN50I_GEN_H6
bool
select FIT
-   select SPL_LOAD_FIT
+   select SPL_LOAD_FIT if SPL
select MMC_SUNXI_HAS_NEW_MODE
select SUPPORT_SPL
---help---
@@ -272,7 +272,7 @@ config MACH_SUN6I
select ARCH_SUPPORT_PSCI
select SPL_ARMV7_SET_CORTEX_SMPEN
select DRAM_SUN6I
-   select SPL_I2C
+   select SPL_I2C if SPL
select SUN6I_PRCM
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
@@ -300,7 +300,7 @@ config MACH_SUN8I_A23
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
select DRAM_SUN8I_A23
-   select SPL_I2C
+   select SPL_I2C if SPL
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
select SYS_I2C_SUN8I_RSB
@@ -313,7 +313,7 @@ config MACH_SUN8I_A33
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
select DRAM_SUN8I_A33
-   select SPL_I2C
+   select SPL_I2C if SPL
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
select SYS_I2C_SUN8I_RSB
@@ -323,7 +323,7 @@ config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7A
select DRAM_SUN8I_A83T
-   select SPL_I2C
+   select SPL_I2C if SPL
select SUNXI_GEN_SUN6I
select MMC_SUNXI_HAS_NEW_MODE
select MMC_SUNXI_HAS_MODE_SWITCH
@@ -382,7 +382,7 @@ config MACH_SUN9I
select CPU_V7A
select SPL_ARMV7_SET_CORTEX_SMPEN
select DRAM_SUN9I
-   select SPL_I2C
+   select SPL_I2C if SPL
select SUN6I_PRCM
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
@@ -398,7 +398,7 @@ config MACH_SUN50I
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_32BIT
select FIT
-   select SPL_LOAD_FIT
+   select SPL_LOAD_FIT if SPL
select SUNXI_A64_TIMER_ERRATUM
 
 config MACH_SUN50I_H5
@@ -407,7 +407,7 @@ config MACH_SUN50I_H5
select MACH_SUNXI_H3_H5
select MMC_SUNXI_HAS_NEW_MODE
select FIT
-   select SPL_LOAD_FIT
+   select SPL_LOAD_FIT if SPL
 
 config MACH_SUN50I_H6
bool "sun50i (Allwinner H6)"
-- 
2.35.8

[PATCH 06/19] sunxi: remove common.h inclusion

The usage of the common.h include file is deprecated, and has already
been removed from several files.

Get rid of all inclusions in the arch/arm/mach-sunxi directory. Most
files actually don't need the header at all, for the few others just
include the headers that we actually require.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/board.c| 1 -
 arch/arm/mach-sunxi/clock.c| 1 -
 arch/arm/mach-sunxi/clock_sun4i.c  | 1 -
 arch/arm/mach-sunxi/clock_sun50i_h6.c  | 1 -
 arch/arm/mach-sunxi/clock_sun6i.c  | 1 -
 arch/arm/mach-sunxi/clock_sun8i_a83t.c | 1 -
 arch/arm/mach-sunxi/clock_sun9i.c  | 1 -
 arch/arm/mach-sunxi/cpu_info.c | 1 -
 arch/arm/mach-sunxi/dram_helpers.c | 3 ++-
 arch/arm/mach-sunxi/dram_sun4i.c   | 1 -
 arch/arm/mach-sunxi/dram_sun50i_h6.c   | 1 -
 arch/arm/mach-sunxi/dram_sun50i_h616.c | 1 -
 arch/arm/mach-sunxi/dram_sun6i.c   | 1 -
 arch/arm/mach-sunxi/dram_sun8i_a23.c   | 1 -
 arch/arm/mach-sunxi/dram_sun8i_a33.c   | 1 -
 arch/arm/mach-sunxi/dram_sun8i_a83t.c  | 1 -
 arch/arm/mach-sunxi/dram_sun9i.c   | 1 -
 arch/arm/mach-sunxi/dram_suniv.c   | 2 +-
 arch/arm/mach-sunxi/dram_sunxi_dw.c| 1 -
 arch/arm/mach-sunxi/gtbus_sun9i.c  | 1 -
 arch/arm/mach-sunxi/pmic_bus.c | 1 -
 arch/arm/mach-sunxi/prcm.c | 1 -
 arch/arm/mach-sunxi/spl_spi_sunxi.c| 1 -
 arch/arm/mach-sunxi/timer.c| 1 -
 24 files changed, 3 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index d998149e375..0140b07d32a 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -9,7 +9,6 @@
  * Some init for sunxi platform.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock.c b/arch/arm/mach-sunxi/clock.c
index da3a0eb0584..b6c68c94f67 100644
--- a/arch/arm/mach-sunxi/clock.c
+++ b/arch/arm/mach-sunxi/clock.c
@@ -7,7 +7,6 @@
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock_sun4i.c 
b/arch/arm/mach-sunxi/clock_sun4i.c
index 471609764d2..8f1d1b65f00 100644
--- a/arch/arm/mach-sunxi/clock_sun4i.c
+++ b/arch/arm/mach-sunxi/clock_sun4i.c
@@ -9,7 +9,6 @@
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c 
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index bea91c78bc5..dac3663e1be 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -1,4 +1,3 @@
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 6bd75a15f6d..aad9df282ec 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -9,7 +9,6 @@
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock_sun8i_a83t.c 
b/arch/arm/mach-sunxi/clock_sun8i_a83t.c
index 31e4281529a..198fe9dbd73 100644
--- a/arch/arm/mach-sunxi/clock_sun8i_a83t.c
+++ b/arch/arm/mach-sunxi/clock_sun8i_a83t.c
@@ -9,7 +9,6 @@
  * (C) Copyright 2015 Vishnu Patekar 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/clock_sun9i.c 
b/arch/arm/mach-sunxi/clock_sun9i.c
index 8ba4802f3b3..edaff9a28ce 100644
--- a/arch/arm/mach-sunxi/clock_sun9i.c
+++ b/arch/arm/mach-sunxi/clock_sun9i.c
@@ -9,7 +9,6 @@
  *Philipp Tomsich 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 7fecc3b88dd..310dca06e57 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -5,7 +5,6 @@
  * Tom Cubie 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/dram_helpers.c 
b/arch/arm/mach-sunxi/dram_helpers.c
index cdf2750f1c5..4a867df7af8 100644
--- a/arch/arm/mach-sunxi/dram_helpers.c
+++ b/arch/arm/mach-sunxi/dram_helpers.c
@@ -5,8 +5,9 @@
  * (C) Copyright 2015 Hans de Goede 
  */
 
-#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/dram_sun4i.c b/arch/arm/mach-sunxi/dram_sun4i.c
index 80a6c4bc0fd..2cce381c9df 100644
--- a/arch/arm/mach-sunxi/dram_sun4i.c
+++ b/arch/arm/mach-sunxi/dram_sun4i.c
@@ -20,7 +20,6 @@
  * rather undocumented and full of magic.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index bff2e42513c..e7e2e6a06ff 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -5,7 +5,6 @@
  * (C) Copyright 2017  Icenowy Zheng 
  *
  */
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c 
b/arch/arm/mach-sunxi/dram_sun50i_h616.c
index c5c1331a4c3..68c49e85f9d

[PATCH 05/19] sunxi: move #ifdef guards around tzpc_init() to header file

Some later 32-bit SoCs require some setup of the Secure Peripherals
Controller, which is handled in tzpc_init().
At the moment this is guarded in board.c by some #ifdefs selecting the
SoCs that need it.

Move those #ifdef guards into the header file, providing an empty stub
function for all other SoCs, so that the #ifdefs can be removed from the
.c file, to improve readability.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/tzpc.h | 6 ++
 arch/arm/mach-sunxi/board.c| 2 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h 
b/arch/arm/include/asm/arch-sunxi/tzpc.h
index 7a6fcaebdb5..92696088a39 100644
--- a/arch/arm/include/asm/arch-sunxi/tzpc.h
+++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
@@ -28,6 +28,12 @@ struct sunxi_tzpc {
 #define SUN8I_H3_TZPC_DECPORT1_ALL  0xff
 #define SUN8I_H3_TZPC_DECPORT2_ALL  0x7f
 
+#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
 void tzpc_init(void);
+#else
+static inline void tzpc_init(void)
+{
+}
+#endif
 
 #endif /* _SUNXI_TZPC_H */
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 11a49418225..d998149e375 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -459,10 +459,8 @@ void board_init_f(ulong dummy)
 {
sunxi_sram_init();
 
-#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
/* Enable non-secure access to some peripherals */
tzpc_init();
-#endif
 
clock_init();
timer_init();
-- 
2.35.8

[PATCH 04/19] sunxi: sun9i: remove unneeded base addresses from header

The cpu_sun9i.h header file defined the base addresses for quite some
peripherals of the Allwinner A80 CPU, even though we now only use a
fraction of that.
Most of the addresses are now either read from the DT, or were never
used in U-Boot in the first place.

Removed the ones that are not used in the whole of the U-Boot source.
to make it clear that this file only contains addresses that are needed
for the SPL operation.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 41 -
 1 file changed, 41 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
index 2bf2675d5c1..73de4707c16 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
@@ -20,7 +20,6 @@
 
 /* AHB0 Module */
 #define SUNXI_NFC_BASE (REGS_AHB0_BASE + 0x3000)
-#define SUNXI_TSC_BASE (REGS_AHB0_BASE + 0x4000)
 
 #define SUNXI_GTBUS_BASE   (REGS_AHB0_BASE + 0x9000)
 /* SID address space starts at 0x01ce000, but e-fuse is at offset 0x200 */
@@ -32,14 +31,7 @@
 #define SUNXI_MMC3_BASE(REGS_AHB0_BASE + 0x12000)
 #define SUNXI_MMC_COMMON_BASE  (REGS_AHB0_BASE + 0x13000)
 
-#define SUNXI_SPI0_BASE(REGS_AHB0_BASE + 0x1A000)
-#define SUNXI_SPI1_BASE(REGS_AHB0_BASE + 0x1B000)
-#define SUNXI_SPI2_BASE(REGS_AHB0_BASE + 0x1C000)
-#define SUNXI_SPI3_BASE(REGS_AHB0_BASE + 0x1D000)
-
 #define SUNXI_GIC400_BASE  (REGS_AHB0_BASE + 0x4)
-#define SUNXI_ARMA9_GIC_BASE   (REGS_AHB0_BASE + 0x41000)
-#define SUNXI_ARMA9_CPUIF_BASE (REGS_AHB0_BASE + 0x42000)
 
 #define SUNXI_DRAM_COM_BASE(REGS_AHB0_BASE + 0x62000)
 #define SUNXI_DRAM_CTL0_BASE   (REGS_AHB0_BASE + 0x63000)
@@ -47,59 +39,26 @@
 #define SUNXI_DRAM_PHY0_BASE   (REGS_AHB0_BASE + 0x65000)
 #define SUNXI_DRAM_PHY1_BASE   (REGS_AHB0_BASE + 0x66000)
 
-/* AHB1 Module */
-#define SUNXI_DMA_BASE (REGS_AHB1_BASE + 0x002000)
-#define SUNXI_USBOTG_BASE  (REGS_AHB1_BASE + 0x10)
-#define SUNXI_USBEHCI0_BASE(REGS_AHB1_BASE + 0x20)
-#define SUNXI_USBEHCI1_BASE(REGS_AHB1_BASE + 0x201000)
-#define SUNXI_USBEHCI2_BASE(REGS_AHB1_BASE + 0x202000)
-
-/* AHB2 Module */
-#define SUNXI_DE_SYS_BASE  (REGS_AHB2_BASE + 0x00)
-#define SUNXI_DISP_SYS_BASE(REGS_AHB2_BASE + 0x01)
 #define SUNXI_DE_FE0_BASE  (REGS_AHB2_BASE + 0x10)
-#define SUNXI_DE_FE1_BASE  (REGS_AHB2_BASE + 0x14)
-#define SUNXI_DE_FE2_BASE  (REGS_AHB2_BASE + 0x18)
-
 #define SUNXI_DE_BE0_BASE  (REGS_AHB2_BASE + 0x20)
-#define SUNXI_DE_BE1_BASE  (REGS_AHB2_BASE + 0x24)
-#define SUNXI_DE_BE2_BASE  (REGS_AHB2_BASE + 0x28)
-
-#define SUNXI_DE_DEU0_BASE (REGS_AHB2_BASE + 0x30)
-#define SUNXI_DE_DEU1_BASE (REGS_AHB2_BASE + 0x34)
-#define SUNXI_DE_DRC0_BASE (REGS_AHB2_BASE + 0x40)
-#define SUNXI_DE_DRC1_BASE (REGS_AHB2_BASE + 0x44)
-
 #define SUNXI_LCD0_BASE(REGS_AHB2_BASE + 0xC0)
 #define SUNXI_LCD1_BASE(REGS_AHB2_BASE + 0xC1)
 #define SUNXI_LCD2_BASE(REGS_AHB2_BASE + 0xC2)
-#define SUNXI_MIPI_DSI0_BASE   (REGS_AHB2_BASE + 0xC4)
-/* Also seen as SUNXI_MIPI_DSI0_DPHY_BASE 0x01ca1000 */
-#define SUNXI_MIPI_DSI0_DPHY_BASE  (REGS_AHB2_BASE + 0xC40100)
 #define SUNXI_HDMI_BASE(REGS_AHB2_BASE + 0xD0)
 
 /* APB0 Module */
 #define SUNXI_CCM_BASE (REGS_APB0_BASE + 0x)
-#define SUNXI_CCMMODULE_BASE   (REGS_APB0_BASE + 0x0400)
 #define SUNXI_TIMER_BASE   (REGS_APB0_BASE + 0x0C00)
 #define SUNXI_PWM_BASE (REGS_APB0_BASE + 0x1400)
-#define SUNXI_LRADC_BASE   (REGS_APB0_BASE + 0x1800)
 
 /* APB1 Module */
 #define SUNXI_TWI0_BASE(REGS_APB1_BASE + 0x2800)
 #define SUNXI_TWI1_BASE(REGS_APB1_BASE + 0x2C00)
-#define SUNXI_TWI2_BASE(REGS_APB1_BASE + 0x3000)
-#define SUNXI_TWI3_BASE(REGS_APB1_BASE + 0x3400)
-#define SUNXI_TWI4_BASE(REGS_APB1_BASE + 0x3800)
 
 /* RCPUS Module */
 #define SUNXI_PRCM_BASE(REGS_RCPUS_BASE + 0x1400)
 #define SUNXI_RSB_BASE (REGS_RCPUS_BASE + 0x3400)
 
-/* Misc. */
-#define SUNXI_BROM_BASE0x /* 32K */
-#define SUNXI_CPU_CFG  (SUNXI_TIMER_BASE + 0x13c)
-
 #ifndef __ASSEMBLY__
 void sunxi_board_init(void);
 void sunxi_reset(void);
-- 
2.35.8

[PATCH 03/19] sunxi: sun4i: remove unneeded base addresses from header

The cpu_sun4i.h header file defined the base addresses for quite some
peripherals of earlier Allwinner CPUs, even though we now only use a
fraction of that.
Most of the addresses are now either read from the DT, or were never
used in U-Boot in the first place.

Removed the ones that are not used in the whole of the U-Boot source.
to make it clear that this file only contains addresses that are needed
for the SPL operation.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 47 -
 1 file changed, 47 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 3daee2f574a..f023a4cfd93 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -36,58 +36,20 @@
 
 #define SUNXI_SRAMC_BASE   0x01c0
 #define SUNXI_DRAMC_BASE   0x01c01000
-#define SUNXI_DMA_BASE 0x01c02000
 #define SUNXI_NFC_BASE 0x01c03000
-#define SUNXI_TS_BASE  0x01c04000
-#define SUNXI_SPI0_BASE0x01c05000
-#define SUNXI_SPI1_BASE0x01c06000
-#define SUNXI_MS_BASE  0x01c07000
-#define SUNXI_TVD_BASE 0x01c08000
-#define SUNXI_CSI0_BASE0x01c09000
 #ifndef CONFIG_MACH_SUNXI_H3_H5
 #define SUNXI_TVE0_BASE0x01c0a000
 #endif
-#define SUNXI_EMAC_BASE0x01c0b000
 #define SUNXI_LCD0_BASE0x01c0C000
 #define SUNXI_LCD1_BASE0x01c0d000
-#define SUNXI_VE_BASE  0x01c0e000
 #define SUNXI_MMC0_BASE0x01c0f000
 #define SUNXI_MMC1_BASE0x01c1
 #define SUNXI_MMC2_BASE0x01c11000
 #define SUNXI_MMC3_BASE0x01c12000
-#ifdef CONFIG_SUNXI_GEN_SUN4I
-#define SUNXI_USB0_BASE0x01c13000
-#define SUNXI_USB1_BASE0x01c14000
-#endif
 #define SUNXI_SS_BASE  0x01c15000
 #if !defined(CONFIG_MACH_SUNXI_H3_H5) && !defined(CONFIG_MACH_SUN50I)
 #define SUNXI_HDMI_BASE0x01c16000
 #endif
-#define SUNXI_SPI2_BASE0x01c17000
-#define SUNXI_SATA_BASE0x01c18000
-#ifdef CONFIG_SUNXI_GEN_SUN4I
-#define SUNXI_PATA_BASE0x01c19000
-#define SUNXI_ACE_BASE 0x01c1a000
-#define SUNXI_TVE1_BASE0x01c1b000
-#define SUNXI_USB2_BASE0x01c1c000
-#endif
-#ifdef CONFIG_SUNXI_GEN_SUN6I
-#if defined(CONFIG_MACH_SUNXI_H3_H5) || defined(CONFIG_MACH_SUN50I)
-#define SUNXI_USBPHY_BASE  0x01c19000
-#define SUNXI_USB0_BASESUNXI_USBPHY_BASE
-#define SUNXI_USB1_BASE0x01c1a000
-#define SUNXI_USB2_BASE0x01c1b000
-#define SUNXI_USB3_BASE0x01c1c000
-#define SUNXI_USB4_BASE0x01c1d000
-#else
-#define SUNXI_USB0_BASE0x01c19000
-#define SUNXI_USB1_BASE0x01c1a000
-#define SUNXI_USB2_BASE0x01c1b000
-#endif
-#endif
-#define SUNXI_CSI1_BASE0x01c1d000
-#define SUNXI_TZASC_BASE   0x01c1e000
-#define SUNXI_SPI3_BASE0x01c1f000
 
 #define SUNXI_CCM_BASE 0x01c2
 #define SUNXI_INTC_BASE0x01c20400
@@ -177,8 +139,6 @@ defined(CONFIG_MACH_SUN50I)
 #else
 #define SUNXI_TVE0_BASE0x01e4
 #endif
-#define SUNXI_MP_BASE  0x01e8
-#define SUNXI_AVG_BASE 0x01ea
 
 #if defined(CONFIG_MACH_SUNXI_H3_H5) || defined(CONFIG_MACH_SUN50I)
 #define SUNXI_HDMI_BASE0x01ee
@@ -197,13 +157,6 @@ defined(CONFIG_MACH_SUN50I)
 #define SUN6I_P2WI_BASE0x01f03400
 #define SUNXI_RSB_BASE 0x01f03400
 
-/* CoreSight Debug Module */
-#define SUNXI_CSDM_BASE0x3f50
-
-#define SUNXI_DDRII_DDRIII_BASE0x4000  /* 2 GiB */
-
-#define SUNXI_BROM_BASE0x  /* 32 kiB */
-
 #define SUNXI_CPU_CFG  (SUNXI_TIMER_BASE + 0x13c)
 
 /* SS bonding ids used for cpu identification */
-- 
2.35.8

[PATCH 02/19] sunxi: sun50i-h6: remove unneeded base addresses from header

The cpu_sun50i_h6.h header file defined the base addresses for quite some
peripherals of the Allwinner H6 and related CPUs, even though we now only
use a fraction of that.
Most of the addresses are now either read from the DT, or were never used
in U-Boot in the first place.

Removed the ones that are not used in the whole of the U-Boot source.
to make it clear that this file only contains addresses that are needed
for the SPL operation.

Signed-off-by: Andre Przywara 
---
 .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 21 ---
 1 file changed, 21 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
index 15ee092d358..8a3f465545a 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
@@ -7,25 +7,14 @@
 #ifndef _SUNXI_CPU_SUN50I_H6_H
 #define _SUNXI_CPU_SUN50I_H6_H
 
-#define SUNXI_SRAM_A1_BASE CONFIG_SUNXI_SRAM_ADDRESS
-#define SUNXI_SRAM_C_BASE  0x00028000
-#define SUNXI_SRAM_A2_BASE 0x0010
-
-#define SUNXI_DE3_BASE 0x0100
-#define SUNXI_SS_BASE  0x01904000
-#define SUNXI_EMCE_BASE0x01905000
-
 #define SUNXI_SRAMC_BASE   0x0300
 #define SUNXI_CCM_BASE 0x03001000
-#define SUNXI_DMA_BASE 0x03002000
 /* SID address space starts at 0x03006000, but e-fuse is at offset 0x200 */
 #define SUNXI_SIDC_BASE0x03006000
 #define SUNXI_SID_BASE 0x03006200
 #define SUNXI_TIMER_BASE   0x03009000
-#define SUNXI_PSI_BASE 0x0300C000
 
 #define SUNXI_GIC400_BASE  0x0302
-#define SUNXI_IOMMU_BASE   0x030F
 
 #ifdef CONFIG_MACH_SUN50I_H6
 #define SUNXI_DRAM_COM_BASE0x04002000
@@ -46,18 +35,8 @@
 #define SUNXI_TWI1_BASE0x05002400
 #define SUNXI_TWI2_BASE0x05002800
 #define SUNXI_TWI3_BASE0x05002C00
-#define SUNXI_SPI0_BASE0x0501
-#define SUNXI_SPI1_BASE0x05011000
-#define SUNXI_GMAC_BASE0x0502
-#define SUNXI_USB0_BASE0x0510
-#define SUNXI_XHCI_BASE0x0520
-#define SUNXI_USB3_BASE0x05311000
-#define SUNXI_PCIE_BASE0x0540
 
 #define SUNXI_HDMI_BASE0x0600
-#define SUNXI_TCON_TOP_BASE0x0651
-#define SUNXI_TCON_LCD0_BASE   0x06511000
-#define SUNXI_TCON_TV0_BASE0x06515000
 
 #define SUNXI_RTC_BASE 0x0700
 #define SUNXI_R_CPUCFG_BASE0x07000400
-- 
2.35.8

[PATCH 01/19] sunxi: cleanup sunxi-common.h

The sunxi-common.h configs header used to contain a lot of random
Allwinner platform related constants, but over the years we moved a lot
of those definitions out there.

Clean up the file to remove outdated comments which are leftovers from
the olden days. Also remove the definition of LOW_LEVEL_SRAM_STACK,
which is actually used nowhere in the whole source tree.

This also uses the opportunity to add some section comments that helps
structuring the header file and improving readability.

Signed-off-by: Andre Przywara 
---
 include/configs/sunxi-common.h | 56 --
 1 file changed, 12 insertions(+), 44 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index b8ca77d031d..b29a25d5617 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -14,8 +14,9 @@
 
 #include 
 
-/* Serial & console */
-/* ns16550 reg in the low bits of cpu reg */
+/
+ *  base addresses for the SPL UART driver  *
+ /
 #ifdef CONFIG_MACH_SUNIV
 /* suniv doesn't have apb2 and uart is connected to apb1 */
 #define CFG_SYS_NS16550_CLK1
@@ -31,8 +32,9 @@
 # define CFG_SYS_NS16550_COM5  SUNXI_R_UART_BASE
 #endif
 
-/* CPU */
-
+/
+ * DRAM base address*
+ /
 /*
  * The DRAM Base differs between some models. We cannot use macros for the
  * CONFIG_FOO defines which contain the DRAM base address since they end
@@ -52,16 +54,6 @@
 /* V3s do not have enough memory to place code at 0x4a00 */
 #endif
 
-/*
- * The A80's A1 sram starts at 0x0001 rather then at 0x and is
- * slightly bigger. Note that it is possible to map the first 32 KiB of the
- * A1 at 0x like with older SoCs by writing 0x16aa0001 to the
- * undocumented 0x008000e0 SYS_CTRL register. Where the 16aa is a key and
- * the 1 actually activates the mapping of the first 32 KiB to 0x.
- * A64 and H5 also has SRAM A1 at 0x0001, but no magic remap register
- * is known yet.
- * H6 has SRAM A1 at 0x0002.
- */
 #define CFG_SYS_INIT_RAM_ADDR  CONFIG_SUNXI_SRAM_ADDRESS
 /* FIXME: this may be larger on some SoCs */
 #define CFG_SYS_INIT_RAM_SIZE  0x8000 /* 32 KiB */
@@ -69,36 +61,13 @@
 #define PHYS_SDRAM_0   CFG_SYS_SDRAM_BASE
 #define PHYS_SDRAM_0_SIZE  0x8000 /* 2 GiB */
 
-/*
- * Miscellaneous configurable options
- */
-
-/* FLASH and environment organization */
-
+/
+ *   environment variables holding default load addresses   *
+ /
 /*
  * We cannot use expressions here, because expressions won't be evaluated in
  * autoconf.mk.
  */
-#if CONFIG_SUNXI_SRAM_ADDRESS == 0x1
-#ifdef CONFIG_ARM64
-/* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
-#define LOW_LEVEL_SRAM_STACK   0x00054000
-#else
-#define LOW_LEVEL_SRAM_STACK   0x00018000
-#endif /* !CONFIG_ARM64 */
-#elif CONFIG_SUNXI_SRAM_ADDRESS == 0x2
-#ifdef CONFIG_MACH_SUN50I_H616
-#define LOW_LEVEL_SRAM_STACK   0x52a00 /* below FEL buffers */
-#else
-/* end of SRAM A2 on H6 for now */
-#define LOW_LEVEL_SRAM_STACK   0x00118000
-#endif
-#else
-#define LOW_LEVEL_SRAM_STACK   0x8000  /* End of sram */
-#endif
-
-/* Ethernet support */
-
 #ifdef CONFIG_ARM64
 /*
  * Boards seem to come with at least 512MB of DRAM.
@@ -174,15 +143,11 @@
"ramdisk_addr_r=" RAMDISK_ADDR_R "\0"
 
 #ifdef CONFIG_ARM64
-
 #define MEM_LAYOUT_ENV_EXTRA_SETTINGS \
"kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \
"kernel_comp_size=" KERNEL_COMP_SIZE "\0"
-
 #else
-
 #define MEM_LAYOUT_ENV_EXTRA_SETTINGS ""
-
 #endif
 
 #define DFU_ALT_INFO_RAM \
@@ -191,6 +156,9 @@
"fdt ram " FDT_ADDR_R " 0x10;" \
"ramdisk ram " RAMDISK_ADDR_R " 0x400\0"
 
+/
+ *  definitions for the distro boot system  *
+ /
 #ifdef CONFIG_MMC
 #if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
 #define BOOTENV_DEV_MMC_AUTO(devtypeu, devtypel, instance) \
-- 
2.35.8

[PATCH 00/19] sunxi: SPL cleanup part 1

This is the first part of a series to clean up the Allwinner SPL a bit.
One big driver for this whole clean up is to eventually accommodate the
RISC-V chips, which share most platform devices, but cannot use any code
that currently lives under arch/arm. So the idea is to disentangle the
code, to get a cleaner separation between ARM specific and platform
specific code. Another related reason is that the RISC-V port aims to
use a DM SPL, so we want to split off code bits that won't be needed when
we have the DM framework in the SPL.

This first part of the series is mostly preparation, and some smaller
cleanups, of code that was around for a long time and missed some
updates.
We start with some removal of no longer needed definitions, in the first
seven patches. The next seven patches tighten the SPL clock code: quite
some functions were compiled for U-Boot proper, however were not needed
there. Sorting this out helps to identify legacy code.
The final five patches move the SPL pinmux setup code into separate
functions and files, and convert the #ifdef hell into proper C "if"
statements.

It would be great if Samuel can have a look and say whether this is
helpful or not. For instance I don't really know how much of the SPL
clock code will be needed for the RISC-V port, since we don't really
model the bus clocks in the DT at all, and currently don't support PLLs
in the DM clock code.

Much of this first series should be good regardless, for instance the
replacement of #ifdef's with C "if" statements, since that became
tedious to expand for new SoCs and boards. But if some parts should live
in a different directory, or should be grouped differently, this can
certainly be factored in.

Please have a look, review and test!

Cheers,
Andre

Andre Przywara (19):
  sunxi: cleanup sunxi-common.h
  sunxi: sun50i-h6: remove unneeded base addresses from header
  sunxi: sun4i: remove unneeded base addresses from header
  sunxi: sun9i: remove unneeded base addresses from header
  sunxi: move #ifdef guards around tzpc_init() to header file
  sunxi: remove common.h inclusion
  sunxi: simplify U-Boot proper only builds
  sunxi: remove unneeded i2c_init_board() call for U-Boot proper
  sunxi: compile clock.c for SPL only
  sunxi: sun4i: make more clock functions SPL only
  sunxi: sun6i: make more clock functions SPL only
  sunxi: sun50i_h6: make more clock functions SPL only
  sunxi: sun8i_a83t: make more clock functions SPL only
  sunxi: sun9i: make more clock functions SPL only
  sunxi: move pinmux setup into separate SPL only file
  sunxi: SPL pinmux: rewrite without #ifdefs
  sunxi: move UART pinmux setup into separate file
  sunxi: SPL pinmux: split out UART pinmux per port
  sunxi: SPL pinmux: rewrite UART setup without #ifdefs

 arch/arm/Kconfig  |   4 +-
 arch/arm/include/asm/arch-sunxi/clock_sun9i.h |   3 -
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |  47 ---
 .../include/asm/arch-sunxi/cpu_sun50i_h6.h|  21 --
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |  41 ---
 arch/arm/include/asm/arch-sunxi/tzpc.h|   6 +
 arch/arm/mach-sunxi/Kconfig   |  16 +-
 arch/arm/mach-sunxi/Makefile  |   4 +-
 arch/arm/mach-sunxi/board.c   | 113 +--
 arch/arm/mach-sunxi/clock.c   |   3 -
 arch/arm/mach-sunxi/clock_sun4i.c |   6 +-
 arch/arm/mach-sunxi/clock_sun50i_h6.c |  58 ++--
 arch/arm/mach-sunxi/clock_sun6i.c |   4 +-
 arch/arm/mach-sunxi/clock_sun8i_a83t.c|   6 +-
 arch/arm/mach-sunxi/clock_sun9i.c |  98 +++---
 arch/arm/mach-sunxi/cpu_info.c|   1 -
 arch/arm/mach-sunxi/dram_helpers.c|   3 +-
 arch/arm/mach-sunxi/dram_sun4i.c  |   1 -
 arch/arm/mach-sunxi/dram_sun50i_h6.c  |   1 -
 arch/arm/mach-sunxi/dram_sun50i_h616.c|   1 -
 arch/arm/mach-sunxi/dram_sun6i.c  |   1 -
 arch/arm/mach-sunxi/dram_sun8i_a23.c  |   1 -
 arch/arm/mach-sunxi/dram_sun8i_a33.c  |   1 -
 arch/arm/mach-sunxi/dram_sun8i_a83t.c |   1 -
 arch/arm/mach-sunxi/dram_sun9i.c  |   1 -
 arch/arm/mach-sunxi/dram_suniv.c  |   2 +-
 arch/arm/mach-sunxi/dram_sunxi_dw.c   |   1 -
 arch/arm/mach-sunxi/gtbus_sun9i.c |   1 -
 arch/arm/mach-sunxi/pmic_bus.c|   1 -
 arch/arm/mach-sunxi/prcm.c|   1 -
 arch/arm/mach-sunxi/spl_pinmux.c  | 312 +
 arch/arm/mach-sunxi/spl_spi_sunxi.c   |   1 -
 arch/arm/mach-sunxi/timer.c   |   1 -
 arch/arm/mach-sunxi/uart_pinmux.c | 158 +
 board/sunxi/board.c   | 318 +-
 include/configs/sunxi-common.h|  56 +--
 36 files changed, 592 insertions(+), 702 deletions(-)
 create mode 100644 arch/arm/mach-sunxi/spl_pinmux.c
 create mode 100644 arch/arm/mach-sunxi/uart_pinmux.c

-- 
2.35.8

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

Hi Tom,

On Tue, Jan 2, 2024 at 8:10 AM Tom Rini  wrote:
>
> On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, Jan 1, 2024 at 4:35 PM Tom Rini  wrote:
> > >
> > > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > > Hi Mark, Tom,
> > > >
> > > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > > From: Tom Rini 
> > > > > >
> > > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > > Hi Sumit,
> > > > > > >
> > > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote:
> > > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Allow platform owners to mirror devicetree files 
> > > > > > > > > > > > > > from devitree-rebasing
> > > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > > > > > build then along with any *-u-boot.dtsi file 
> > > > > > > > > > > > > > present in arch/$(ARCH)/dts
> > > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This will help easy migration for platforms which 
> > > > > > > > > > > > > > currently are compliant
> > > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > > >   enables a live tree which is available 
> > > > > > > > > > > > > > after relocation,
> > > > > > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > > +   bool "Enable use of devicetree imported 
> > > > > > > > > > > > > > from Linux kernel release"
> > > > > > > > > > > > > > +   help
> > > > > > > > > > > > > > + Traditionally, U-Boot platforms used to 
> > > > > > > > > > > > > > have their custom devicetree
> > > > > > > > > > > > > > + files or copy devicetree files from Linux 
> > > > > > > > > > > > > > kernel which are hard to
> > > > > > > > > > > > > > + maintain and can usually get out-of-sync 
> > > > > > > > > > > > > > from Linux kernel. This
> > > > > > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > > > > > + a regular sync will be maintained every 
> > > > > > > > > > > > > > major Linux kernel release
> > > > > > > > > > > > > > + cycle. However, platforms can still have 
> > > > > > > > > > > > > > some custom u-boot specific
> > > > > > > > > > > > > > + bits maintained as part of *-u-boot.dtsi 
> > > > > > > > > > > > > > files.
> > > > > > > > > > > > >
> > > > > > > > > > > > > My only other suggestion here is to mention that this 
> > > > > > > > > > > > > should be set in
> > > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that 
> > > > > > > > > > > > > means

Re: [PATCH 0/9] dts: Move to SoC-specific build rules

Hi Tom,

On Tue, Jan 2, 2024 at 7:55 AM Tom Rini  wrote:
>
> On Tue, Jan 02, 2024 at 07:06:36AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, Dec 31, 2023 at 7:01 AM Tom Rini  wrote:
> > >
> > > On Sun, Dec 31, 2023 at 05:45:00AM -0700, Simon Glass wrote:
> > > > -Scott as it is bouncing
> > > >
> > > > Hi,
> > > >
> > > > On Fri, Dec 29, 2023 at 9:46 AM Peter Robinson  
> > > > wrote:
> > > > >
> > > > > On Fri, Dec 29, 2023 at 12:23 AM Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > U-Boot builds devicetree binaries from its source 
> > > > > > > > > > > > > tree. As part of the
> > > > > > > > > > > > > Kconfig conversion, the Makefiles were updated to 
> > > > > > > > > > > > > align with how this
> > > > > > > > > > > > > is done in Linux: a single target for each SoC is 
> > > > > > > > > > > > > used to build all the
> > > > > > > > > > > > > .dtb files for that SoC.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Since then, the Makefiles have devolved in some 
> > > > > > > > > > > > > cases, resulting in
> > > > > > > > > > > > > lots of target-specific build rules. Also Linux has 
> > > > > > > > > > > > > moved to using
> > > > > > > > > > > > > subdirectories for each vendor.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Recent work aims to allow U-Boot to directly use 
> > > > > > > > > > > > > devicetree files from
> > > > > > > > > > > > > Linux. This would be easier if the directory 
> > > > > > > > > > > > > structure were the same.
> > > > > > > > > > > > > Another recent discussion involved dropping the build 
> > > > > > > > > > > > > rules altogether.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This series makes a start at cleaning up some of the 
> > > > > > > > > > > > > build rules, to
> > > > > > > > > > > > > reduce the amount of code and make it easier to add 
> > > > > > > > > > > > > new boards for the
> > > > > > > > > > > > > same SoC.
> > > > > > > > > > > > >
> > > > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options 
> > > > > > > > > > > > > between U-Boot and Linux
> > > > > > > > > > > > > are not always the same. Given the large number of 
> > > > > > > > > > > > > SoCs and boards
> > > > > > > > > > > > > supported by U-Boot, it would be useful to align 
> > > > > > > > > > > > > these where possible.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't know why we should start with this now, and 
> > > > > > > > > > > > further not being on
> > > > > > > > > > > > top of Sumit's series to remove our duplicate dts 
> > > > > > > > > > > > files. And that's
> > > > > > > > > > > > where we can have the conversation about for which 
> > > > > > > > > > > > cases it even makes
> > > > > > > > > > > > sense to build all of the dts files for a given SoC.
> > > > > > > > > > >
> > > > > > > > > > > This is a completely different series - there are no 
> > > > > > > > > > > conflicts with
> > > > > > > > > > > Sumit's series so it can be applied before or after it.
> > > > > > > > > > >
> > > > > > > > > > > My goal here is to clean up our build rules, rather than 
> > > > > > > > > > > just throwing
> > > > > > > > > > > them all away, for reasons we have discussed previously. 
> > > > > > > > > > > I filed [1]
> > > > > > > > > > > to track that.
> > > > > > > > > >
> > > > > > > > > > Yes, I'm saying we shouldn't be doing anything this series 
> > > > > > > > > > does until
> > > > > > > > > > after Sumit's series has landed. Along with the fact that I 
> > > > > > > > > > don't like
> > > > > > > > > > what's going on in this series.
> > > > > > > > >
> > > > > > > > > This seems to again be the disagreement over whether a single 
> > > > > > > > > DT
> > > > > > > > > should be build for each board, or all the DTs for an SoC?
> > > > > > > >
> > > > > > > > It's about the disagreement on what we should be building, and 
> > > > > > > > what that
> > > > > > > > infrastructure looks like. I do not like adding extra rules for
> > > > > > > > "clarity" because they don't make things clearer, they lead to 
> > > > > > > > the
> > > > > > > > unclear mess we have today getting worse. Most instructions are 
> > > > > > > >

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

Hi Masahiro,

On Wed, Dec 13, 2023 at 5:14 AM Will Deacon  wrote:
>
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v9:
> > - Move the compression control into Makefile.lib
> >
> > Changes in v8:
> > - Drop compatible string in FDT node
> > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > - Turn compress part of the make_fit.py comment in to a sentence
> > - Add two blank lines before parse_args() and setup_fit()
> > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > - Use '$( > - Add 'mkimage' details Documentation/process/changes.rst
> > - Allow changing the compression used
> > - Tweak cover letter since there is only one clean-up patch
> >
> > Changes in v7:
> > - Add Image as a dependency of image.fit
> > - Drop kbuild tag
> > - Add dependency on dtbs
> > - Drop unnecessary path separator for dtbs
> > - Rebase to -next
> >
> > Changes in v5:
> > - Drop patch previously applied
> > - Correct compression rule which was broken in v4
> >
> > Changes in v4:
> > - Use single quotes for UIMAGE_NAME
> >
> > Changes in v3:
> > - Drop temporary file image.itk
> > - Drop patch 'Use double quotes for image name'
> > - Drop double quotes in use of UIMAGE_NAME
> > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > - Avoid hard-coding "arm64" for the DT architecture
> >
> > Changes in v2:
> > - Drop patch previously applied
> > - Add .gitignore file
> > - Move fit rule to Makefile.lib using an intermediate file
> > - Drop dependency on CONFIG_EFI_ZBOOT
> > - Pick up .dtb files separately from the kernel
> > - Correct pylint too-many-args warning for write_kernel()
> > - Include the kernel image in the file count
> > - Add a pointer to the FIT spec and mention of its wide industry usage
> > - Mention the kernel version in the FIT description
> >
> >  Documentation/process/changes.rst |   9 +
> >  MAINTAINERS   |   7 +
> >  arch/arm64/Makefile   |   7 +-
> >  arch/arm64/boot/.gitignore|   1 +
> >  arch/arm64/boot/Makefile  |   6 +-
> >  scripts/Makefile.lib  |  16 ++
> >  scripts/make_fit.py   | 291 ++
> >  7 files changed, 334 insertions(+), 3 deletions(-)
> >  create mode 100755 scripts/make_fit.py
>
> I'll need Masahiro's Ack on the scripts/ changes before I can take this
> one.

Any thoughts on this request, please?

Regards,
Simon

[PATCH v4 9/9] fdt: get FDT from bloblist

Get devicetree from a bloblist if it exists.
If not, fallback to get FDT from the board custom function.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Refactor of board_fdt_blob_setup().
Changes in v4
- Move the logics from board custom function to fdt library.

 lib/fdtdec.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 7a69167648..02a0504fad 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -8,6 +8,7 @@
 
 #ifndef USE_HOSTCC
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1676,7 +1677,13 @@ int fdtdec_setup(void)
 
/* Allow the board to override the fdt address. */
if (IS_ENABLED(CONFIG_OF_BOARD)) {
-   gd->fdt_blob = board_fdt_blob_setup();
+   void *fdt = NULL;
+
+   /* Check if a fdt exists in bloblist */
+   if (IS_ENABLED(CONFIG_BLOBLIST) && !bloblist_maybe_init())
+   fdt = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
+
+   gd->fdt_blob = fdt ? fdt : board_fdt_blob_setup();
if (ret)
return ret;
gd->fdt_src = FDTSRC_BOARD;
-- 
2.25.1

[PATCH v4 8/9] fdt: update the document and Kconfig description

Update the document and Kconfig to describe the behavior of board
specific custom functions when CONFIG_OF_BOARD is defined.

Signed-off-by: Raymond Mao 
---
Changes in v4
- Refine the description.

 doc/develop/devicetree/control.rst | 6 +++---
 dts/Kconfig| 7 +--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/doc/develop/devicetree/control.rst 
b/doc/develop/devicetree/control.rst
index cbb65c9b17..2b968a6b01 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -104,9 +104,9 @@ in u-boot.bin so you can still just flash u-boot.bin onto 
your board. If you are
 using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
 tree binary.
 
-If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
-devicetree at runtime, for example if an earlier bootloader stage creates
-it and passes it to U-Boot.
+If CONFIG_OF_BOARD is defined, arch-specific routine and board-specific routine
+will provide the bloblist and devicetree respectively at runtime, for example 
if
+an earlier bootloader stage creates it and passes it to U-Boot.
 
 If CONFIG_SANDBOX is defined, then it will be read from a file on
 startup. Use the -d flag to U-Boot to specify the file to read, -D for the
diff --git a/dts/Kconfig b/dts/Kconfig
index 00c0aeff89..ac6e1752bb 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -110,8 +110,11 @@ config OF_BOARD
default y if SANDBOX || OF_HAS_PRIOR_STAGE
help
  If this option is enabled, the device tree is provided at runtime by
- a custom function called board_fdt_blob_setup(). The board must
- implement this function if it wishes to provide special behaviour.
+ a board custom function called board_fdt_blob_setup().
+ If this option is enabled, bloblist is provided at runtime by an
+ arch custom function called xferlist_from_boot_arg().
+ An arch or board must implement these functions if it wishes to
+ provide special behaviours.
 
  With this option, the device tree build by U-Boot may be overridden or
  ignored. See OF_HAS_PRIOR_STAGE.
-- 
2.25.1

[PATCH v4 7/9] bloblist: Load the bloblist from the previous loader

During bloblist initialization, when OF_BOARD is defined, load the
bloblist via boot arguments from the previous loader.
If a valid bloblist exists in boot arguments, relocate it into the
fixed bloblist memory region.
If not, fallback to support BLOBLIST_ADDR or BLOBLIST_ALLOC.

Signed-off-by: Raymond Mao 
---
Changes in v4
- Add weak default function.
- Add comments for BLOBLIST_ALLOC.
- Add local debug macro.
- Refine the commit message.

 common/bloblist.c  | 66 +-
 include/bloblist.h | 10 +++
 2 files changed, 58 insertions(+), 18 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 4e76975627..65c3c031d0 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -17,6 +17,9 @@
 #include 
 #include 
 
+/* local debug macro */
+#undef BLOBLIST_DEBUG
+
 /*
  * A bloblist is a single contiguous chunk of memory with a header
  * (struct bloblist_hdr) and a number of blobs in it.
@@ -487,37 +490,58 @@ int bloblist_reloc(void *to, uint to_size)
return 0;
 }
 
+/*
+ * Weak default function for getting bloblist from boot args.
+ */
+int __weak xferlist_from_boot_arg(ulong __always_unused addr,
+ ulong __always_unused size)
+{
+   return -ENOENT;
+}
+
 int bloblist_init(void)
 {
bool fixed = IS_ENABLED(CONFIG_BLOBLIST_FIXED);
int ret = -ENOENT;
ulong addr, size;
-   bool expected;
-
-   /**
-* We don't expect to find an existing bloblist in the first phase of
-* U-Boot that runs. Also we have no way to receive the address of an
-* allocated bloblist from a previous stage, so it must be at a fixed
+   /*
+* If U-Boot is not in the first phase, an existing bloblist must be
+* at a fixed address.
+*/
+   bool from_addr = fixed && !u_boot_first_phase();
+   /*
+* If U-Boot is in the first phase that a board specific routine should
+* install the bloblist passed from previous loader to this fixed
 * address.
 */
-   expected = fixed && !u_boot_first_phase();
+   bool from_board = fixed && IS_ENABLED(CONFIG_OF_BOARD) &&
+ u_boot_first_phase();
+
if (spl_prev_phase() == PHASE_TPL && !IS_ENABLED(CONFIG_TPL_BLOBLIST))
-   expected = false;
+   from_addr = false;
if (fixed)
addr = IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED,
  CONFIG_BLOBLIST_ADDR);
size = CONFIG_BLOBLIST_SIZE;
-   if (expected) {
+
+   if (from_board)
+   ret = xferlist_from_boot_arg(addr, size);
+   else if (from_addr)
ret = bloblist_check(addr, size);
-   if (ret) {
-   log_warning("Expected bloblist at %lx not found 
(err=%d)\n",
-   addr, ret);
-   } else {
-   /* Get the real size, if it is not what we expected */
-   size = gd->bloblist->total_size;
-   }
-   }
+
+   if (ret)
+   log_warning("Bloblist at %lx not found (err=%d)\n",
+   addr, ret);
+   else
+   /* Get the real size */
+   size = gd->bloblist->total_size;
+
if (ret) {
+   /*
+* If we don't have a bloblist from a fixed address, or the one
+* in the fixed address is not valid. we must allocate the
+* memory for it now.
+*/
if (CONFIG_IS_ENABLED(BLOBLIST_ALLOC)) {
void *ptr = memalign(BLOBLIST_ALIGN, size);
 
@@ -525,7 +549,8 @@ int bloblist_init(void)
return log_msg_ret("alloc", -ENOMEM);
addr = map_to_sysmem(ptr);
} else if (!fixed) {
-   return log_msg_ret("!fixed", ret);
+   return log_msg_ret("BLOBLIST_FIXED is not enabled",
+  ret);
}
log_debug("Creating new bloblist size %lx at %lx\n", size,
  addr);
@@ -538,6 +563,11 @@ int bloblist_init(void)
return log_msg_ret("ini", ret);
gd->flags |= GD_FLG_BLOBLIST_READY;
 
+#ifdef BLOBLIST_DEBUG
+   bloblist_show_stats();
+   bloblist_show_list();
+#endif
+
return 0;
 }
 
diff --git a/include/bloblist.h b/include/bloblist.h
index 81f1dfa027..af215932bc 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -482,4 +482,14 @@ static inline int bloblist_maybe_init(void)
  */
 int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig);
 
+/**
+ * xferlist_from_boot_arg() - Get bloblist from the boot args and relocate it
+ *   to the specified address.
+ *
+ * @addr: Address for the bloblist
+ * @size: Size of space reserved for the bloblist
+ * Return: 0 if

[PATCH v4 6/9] arm: Get bloblist from boot arguments

Add arch custom function to get bloblist from boot arguments.
Check whether boot arguments aligns with the register conventions
defined in FW Handoff spec v0.9.
Add bloblist related options into qemu-arm default config.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Remove low level code for copying boot arguments.
- Refactor board_fdt_blob_setup() and remove direct access of gd->bloblist.
Changes in v3
- Optimize board_bloblist_from_boot_arg().
Changes in v4
- Move the function as an Arm-arch library instead of a board-specific one.

 arch/arm/lib/xferlist.c  | 38 
 configs/qemu_arm64_defconfig |  3 +++
 3 files changed, 45 insertions(+)
 create mode 100644 arch/arm/lib/xferlist.c

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index b1bcd37466..0023c55d0d 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -85,6 +85,10 @@ obj-y+= psci-dt.o
 
 obj-$(CONFIG_DEBUG_LL) += debug.o
 
+ifdef CONFIG_BLOBLIST
+obj-$(CONFIG_OF_BOARD)  += xferlist.o
+endif
+
 # For EABI conformant tool chains, provide eabi_compat()
 ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS)))
 extra-y+= eabi_compat.o
diff --git a/arch/arm/lib/xferlist.c b/arch/arm/lib/xferlist.c
new file mode 100644
index 00..163d20c11c
--- /dev/null
+++ b/arch/arm/lib/xferlist.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Linaro Limited
+ * Author: Raymond Mao 
+ */
+#include 
+#include 
+#include 
+
+/*
+ * Boot parameters saved from start.S
+ * saved_args[0]: FDT base address
+ * saved_args[1]: Bloblist signature
+ * saved_args[2]: must be 0
+ * saved_args[3]: Bloblist base address
+ */
+extern unsigned long saved_args[];
+
+int xferlist_from_boot_arg(ulong addr, ulong size)
+{
+   int ret = -ENOENT;
+
+   if (!IS_ENABLED(CONFIG_OF_BOARD) || !IS_ENABLED(CONFIG_BLOBLIST))
+   return -ENOENT;
+
+   ret = bloblist_check(saved_args[3], size);
+   if (ret)
+   return ret;
+
+   /* Check the register conventions */
+   ret = bloblist_check_reg_conv(saved_args[0], saved_args[2],
+ saved_args[1]);
+   if (!ret)
+   /* Relocate the bloblist to the fixed address */
+   ret = bloblist_reloc((void *)addr, size);
+
+   return ret;
+}
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index c010c25a92..418f48001c 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -69,3 +69,6 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_PCI=y
 CONFIG_SEMIHOSTING=y
 CONFIG_TPM=y
+CONFIG_BLOBLIST=y
+CONFIG_BLOBLIST_ADDR=0x40004000
+CONFIG_BLOBLIST_SIZE=0x4000
-- 
2.25.1

[PATCH v4 5/9] arm: armv8: save boot arguments

Save boot arguments x[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao 
Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- New patch file created for v2.

 arch/arm/cpu/armv8/start.S | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 6cc1d26e5e..8e704f590e 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -370,5 +370,19 @@ ENTRY(c_runtime_cpu_setup)
 ENDPROC(c_runtime_cpu_setup)
 
 WEAK(save_boot_params)
+#if (IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST))
+   adr x9, saved_args
+   stp x0, x1, [x9]
+   /* Increment the address by 16 bytes for the next pair of values */
+   stp x2, x3, [x9, #16]
+#endif
b   save_boot_params_ret/* back to my caller */
 ENDPROC(save_boot_params)
+
+.section .data
+.global saved_args
+saved_args:
+   .rept 4
+   .xword 0
+   .endr
+END(saved_args)
-- 
2.25.1

[PATCH v4 4/9] arm: armv7: save boot arguments

Save boot arguments r[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch file created for v2.
Changes in v3
- Swap value of r0 with r2.
Changes in v4
- Fix a bug when saving the boot args.

 arch/arm/cpu/armv7/start.S | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 69e281b086..66372e4c68 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -152,9 +152,28 @@ ENDPROC(c_runtime_cpu_setup)
  *
  */
 WEAK(save_boot_params)
+#if (IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST))
+   ldr r12, =saved_args
+   /*
+* Intentionally swapping r0 with r2 in order to simplify the C
+* function we use later.
+*/
+   str r2, [r12]
+   str r1, [r12, #4]
+   str r0, [r12, #8]
+   str r3, [r12, #12]
+#endif
b   save_boot_params_ret@ back to my caller
 ENDPROC(save_boot_params)
 
+.section .data
+.global saved_args
+saved_args:
+   .rept 4
+   .word 0
+   .endr
+END(saved_args)
+
 #ifdef CONFIG_ARMV7_LPAE
 WEAK(switch_to_hypervisor)
b   switch_to_hypervisor_ret
-- 
2.25.1

[PATCH v4 3/9] bloblist: refactor of bloblist_reloc()

The current bloblist pointer and size can be retrieved from global
data, so we don't need to pass them from the function arguments.
This change also help to remove all external access of gd->bloblist
outside of bloblist module.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch file created for v2.
Changes in v3
- Check the space size before copying the bloblist.
- Add return code of bloblist_reloc().
Changes in v4
- return error code from bloblist_reloc().

 common/bloblist.c  | 10 --
 common/board_f.c   |  9 +++--
 include/bloblist.h |  8 
 test/bloblist.c|  6 ++
 4 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 4039eb3a03..4e76975627 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -472,13 +472,19 @@ void bloblist_show_list(void)
}
 }
 
-void bloblist_reloc(void *to, uint to_size, void *from, uint from_size)
+int bloblist_reloc(void *to, uint to_size)
 {
struct bloblist_hdr *hdr;
 
-   memcpy(to, from, from_size);
+   if (to_size < gd->bloblist->total_size)
+   return -ENOSPC;
+
+   memcpy(to, gd->bloblist, gd->bloblist->total_size);
hdr = to;
hdr->total_size = to_size;
+   gd->bloblist = to;
+
+   return 0;
 }
 
 int bloblist_init(void)
diff --git a/common/board_f.c b/common/board_f.c
index d4d7d01f8f..f4145a2698 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -676,13 +676,10 @@ static int reloc_bloblist(void)
return 0;
}
if (gd->new_bloblist) {
-   int size = CONFIG_BLOBLIST_SIZE;
-
debug("Copying bloblist from %p to %p, size %x\n",
- gd->bloblist, gd->new_bloblist, size);
-   bloblist_reloc(gd->new_bloblist, CONFIG_BLOBLIST_SIZE_RELOC,
-  gd->bloblist, size);
-   gd->bloblist = gd->new_bloblist;
+ gd->bloblist, gd->new_bloblist, gd->bloblist->total_size);
+   return bloblist_reloc(gd->new_bloblist,
+ CONFIG_BLOBLIST_SIZE_RELOC);
}
 #endif
 
diff --git a/include/bloblist.h b/include/bloblist.h
index 1906847c15..81f1dfa027 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -426,11 +426,11 @@ const char *bloblist_tag_name(enum bloblist_tag_t tag);
  * bloblist_reloc() - Relocate the bloblist and optionally resize it
  *
  * @to: Pointer to new bloblist location (must not overlap old location)
- * @to_size: New size for bloblist (must be larger than from_size)
- * @from: Pointer to bloblist to relocate
- * @from_size: Size of bloblist to relocate
+ * @to_size: New size for bloblist
+ * Return: 0 if OK, -ENOSPC if the new size is small than the bloblist total
+ *size.
  */
-void bloblist_reloc(void *to, uint to_size, void *from, uint from_size);
+int bloblist_reloc(void *to, uint to_size);
 
 /**
  * bloblist_init() - Init the bloblist system with a single bloblist
diff --git a/test/bloblist.c b/test/bloblist.c
index 7dab9addf8..1c60bbac36 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -376,13 +376,12 @@ static int bloblist_test_reloc(struct unit_test_state 
*uts)
 {
const uint large_size = TEST_BLOBLIST_SIZE;
const uint small_size = 0x20;
-   void *old_ptr, *new_ptr;
+   void *new_ptr;
void *blob1, *blob2;
ulong new_addr;
ulong new_size;
 
ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0, 0));
-   old_ptr = map_sysmem(TEST_ADDR, TEST_BLOBLIST_SIZE);
 
/* Add one blob and then one that won't fit */
blob1 = bloblist_add(TEST_TAG, small_size, 0);
@@ -394,8 +393,7 @@ static int bloblist_test_reloc(struct unit_test_state *uts)
new_addr = TEST_ADDR + TEST_BLOBLIST_SIZE;
new_size = TEST_BLOBLIST_SIZE + 0x100;
new_ptr = map_sysmem(new_addr, TEST_BLOBLIST_SIZE);
-   bloblist_reloc(new_ptr, new_size, old_ptr, TEST_BLOBLIST_SIZE);
-   gd->bloblist = new_ptr;
+   ut_assertok(bloblist_reloc(new_ptr, new_size));
 
/* Check the old blob is there and that we can now add the bigger one */
ut_assertnonnull(bloblist_find(TEST_TAG, small_size));
-- 
2.25.1

[PATCH v4 2/9] bloblist: check bloblist with specified buffer size

Instead of expecting the bloblist total size to be the same as the
pre-allocated buffer size, practically we are more interested in
whether the pre-allocated buffer size is bigger than the bloblist
total size.

Signed-off-by: Raymond Mao 
---
Changes in v2
- New patch file created for v2.
Changes in v4
- Update function header of bloblist_check().

 common/bloblist.c  | 2 +-
 include/bloblist.h | 9 +
 test/bloblist.c| 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index acf67304d0..4039eb3a03 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -384,7 +384,7 @@ int bloblist_check(ulong addr, uint size)
return log_msg_ret("Bad magic", -ENOENT);
if (hdr->version != BLOBLIST_VERSION)
return log_msg_ret("Bad version", -EPROTONOSUPPORT);
-   if (!hdr->total_size || (size && hdr->total_size != size))
+   if (!hdr->total_size || (size && hdr->total_size > size))
return log_msg_ret("Bad total size", -EFBIG);
if (hdr->used_size > hdr->total_size)
return log_msg_ret("Bad used size", -ENOENT);
diff --git a/include/bloblist.h b/include/bloblist.h
index bf9e12ebf8..1906847c15 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -348,12 +348,13 @@ int bloblist_new(ulong addr, uint size, uint flags, uint 
align_log2);
  * bloblist_check() - Check if a bloblist exists
  *
  * @addr: Address of bloblist
- * @size: Expected size of blobsize, or 0 to detect the size
+ * @size: Reserved space size for blobsize, or 0 to use the total size
  * Return: 0 if OK, -ENOENT if the magic number doesn't match (indicating that
- * there problem is no bloblist at the given address), -EPROTONOSUPPORT
+ * there problem is no bloblist at the given address) or any fields for header
+ * size, used size and total size do not match, -EPROTONOSUPPORT
  * if the version does not match, -EIO if the checksum does not match,
- * -EFBIG if the expected size does not match the detected size, -ENOSPC
- * if the size is not large enough to hold the headers
+ * -EFBIG if the reserved space size is small than the total size or total size
+ * is 0
  */
 int bloblist_check(ulong addr, uint size);
 
diff --git a/test/bloblist.c b/test/bloblist.c
index 17d9dd03d0..7dab9addf8 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -207,7 +207,7 @@ static int bloblist_test_checksum(struct unit_test_state 
*uts)
hdr->flags++;
 
hdr->total_size--;
-   ut_asserteq(-EFBIG, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
+   ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
hdr->total_size++;
 
hdr->spare++;
-- 
2.25.1

[PATCH v4 1/9] bloblist: add API to check the register conventions

Add bloblist_check_reg_conv() to check whether the bloblist is compliant
to the register conventions defined in Firmware Handoff specification.
This API can be used for all Arm platforms.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Refactor of bloblist_check_reg_conv().
Changes in v3
- bloblist_check_reg_conv() returns -ENOENT if OF_BOARD is disabled.
Changes in v4
- Add checking of signature register.

 common/bloblist.c  | 14 ++
 include/bloblist.h | 20 
 2 files changed, 34 insertions(+)

diff --git a/common/bloblist.c b/common/bloblist.c
index 9daf0d2b13..acf67304d0 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -542,3 +542,17 @@ int bloblist_maybe_init(void)
 
return 0;
 }
+
+int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig)
+{
+   if (!IS_ENABLED(CONFIG_OF_BOARD))
+   return -ENOENT;
+
+   if (rzero || rsig != (BLOBLIST_MAGIC | BLOBLIST_REGCONV_VER) ||
+   rfdt != (ulong)bloblist_find(BLOBLISTT_CONTROL_FDT, 0)) {
+   gd->bloblist = NULL;  /* Reset the gd bloblist pointer */
+   return -EIO;
+   }
+
+   return 0;
+}
diff --git a/include/bloblist.h b/include/bloblist.h
index 84fc943819..bf9e12ebf8 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -78,6 +78,13 @@ enum {
BLOBLIST_VERSION= 1,
BLOBLIST_MAGIC  = 0x4a0fb10b,
 
+   /*
+* FIXME:
+* Register convention version should be placed into a higher byte
+* https://github.com/FirmwareHandoff/firmware_handoff/issues/32
+*/
+   BLOBLIST_REGCONV_VER= 1 << 24,
+
BLOBLIST_BLOB_ALIGN_LOG2 = 3,
BLOBLIST_BLOB_ALIGN  = 1 << BLOBLIST_BLOB_ALIGN_LOG2,
 
@@ -461,4 +468,17 @@ static inline int bloblist_maybe_init(void)
 }
 #endif /* BLOBLIST */
 
+/**
+ * bloblist_check_reg_conv() - Check whether the bloblist is compliant to
+ *the register conventions according to the
+ *Firmware Handoff spec.
+ *
+ * @rfdt:  Register that holds the FDT base address.
+ * @rzero: Register that must be zero.
+ * @rsig:  Register that holds signature and register conventions version.
+ * Return: 0 if OK, -EIO if the bloblist is not compliant to the register
+ *conventions, -ENOENT if OF_BOARD is disabled.
+ */
+int bloblist_check_reg_conv(ulong rfdt, ulong rzero, ulong rsig);
+
 #endif /* __BLOBLIST_H */
-- 
2.25.1

[PATCH v4 0/9] Handoff bloblist from previous boot stage

This patch set depends on another series:
"[PATCH v5 00/11] Support Firmware Handoff spec via bloblist".

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 OF_BOARD option is enabled and
all boot arguments are compliant to the register conventions defined
in the Firmware Handoff spec v0.9.

FDT library function will load the FDT from the bloblist if it exists.
Otherwise it fallbacks to get the FDT from the board custom function.

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().

Raymond Mao (9):
  bloblist: add API to check the register conventions
  bloblist: check bloblist with specified buffer size
  bloblist: refactor of bloblist_reloc()
  arm: armv7: save boot arguments
  arm: armv8: save boot arguments
  arm: Get bloblist from boot arguments
  bloblist: Load the bloblist from the previous loader
  fdt: update the document and Kconfig description
  fdt: get FDT from bloblist

 arch/arm/cpu/armv7/start.S | 19 ++
 arch/arm/cpu/armv8/start.S | 14 +
 arch/arm/lib/Makefile  |  4 ++
 arch/arm/lib/xferlist.c| 38 
 common/bloblist.c  | 92 +++---
 common/board_f.c   |  9 +--
 configs/qemu_arm64_defconfig   |  3 +
 doc/develop/devicetree/control.rst |  6 +-
 dts/Kconfig|  7 ++-
 include/bloblist.h | 47 ---
 lib/fdtdec.c   |  9 ++-
 test/bloblist.c|  8 +--
 12 files changed, 210 insertions(+), 46 deletions(-)
 create mode 100644 arch/arm/lib/xferlist.c

-- 
2.25.1

Re: [PATCH v2 26/26] arm: dts: k3-am654: convert bootph-pre-ram to bootph-all

On 11:47-20231229, Bryan Brattlof wrote:
> Many nodes are reused between WKUP SPL, MAIN SPL, and U-Boot. Using
> bootph-pre-ram is causing these nodes to be present in SPL builds but
> pruned away during the U-Boot build. Convert these nodes to bootph-all
> so they will remain no matter which dtb build is happening.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 25/26] arm: dts: k3-am654: remove duplicate mcu secure proxy node

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate mcu secure proxy node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 24/26] arm: dts: k3-am654: move dummy_clock to root node

On 11:47-20231229, Bryan Brattlof wrote:
> The dummy_clock node is used to help the drivers probe the IO needed to
> setup consoles and boot media to load firmware into the SoC.
> 
> This dummy_clock isn't a device that exists nor does it exist in the
> mcu domain. So move it from cbass_mcu to the root node to avoid any
> confusion.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 23/26] arm: dts: k3-am654: remove un-needed aliases

On 11:47-20231229, Bryan Brattlof wrote:
> These aliases are not needed in U-Boot. Remove them
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 22/26] arm: dts: k3-am654: remove duplicate root properties

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we have duplicate
> properties in the root node. Remove them
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 21/26] arm: dts: k3-am654: remove duplicate vtt pinmux

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate vtt_pinmux node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 20/26] arm: dts: k3-am654: remove duplicate mdio

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate mdio node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 19/26] arm: dts: k3-am654: remove usb0

On 11:47-20231229, Bryan Brattlof wrote:
> The pinmux for usb0 is missing from the Linux board dtb file. Remove it
> until we can introduce it in Linux
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 18/26] arm: dts: k3-am654: remove duplicate ospi0 node

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate ospi0 node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 17/26] arm: dts: k3-am654: remove duplicate wkup_i2c0

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate wkup_i2c0 node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 16/26] arm: dts: k3-am654: remove duplicate sdhci1 pinmux node

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate sdhci1 pinmux node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 15/26] arm: dts: k3-am654: remove duplicate sdhci0 pinmux node

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have
> a duplicate sdhci0 pinmux node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 14/26] arm: dts: k3-am654: remove duplicate main_uart0

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate main_uart0 node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 13/26] arm: dts: k3-am654: remove duplicate mcu_uart0 node

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified we now have a
> duplicate mcu_uart0 node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 12/26] arm: dts: k3-am654: add needed regs to udmap nodes

On 11:47-20231229, Bryan Brattlof wrote:
> Ethernet is one of a few IPs in U-Boot that depend on DMA to operate.
> However there are a few missing registers ranges in the udmap nodes
> need to properly setup DMA for the am65x.
> 
> A fix has been added to the Linux kernel[0] to add these ranges however
> they have not made it to a Linux tag. To keep DMA operational until the
> next DT sync from Linux, add these ranges to the *-u-boot.dtsi with a
> note for our future selves.
> 
> [0] https://lore.kernel.org/r/20231213135138.929517-2-vigne...@ti.com
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 34 
>  1 file changed, 34 insertions(+)
> 
> diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
> b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> index a008af5b4a047..a24cb895e5578 100644
> --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> @@ -252,3 +252,37 @@
>  _r5fss0 {
>   ti,cluster-mode = <0>;
>  };
> +
> +/*
> + * The DMA driver requires a few extra register ranges
> + * which are missing for the am65x. A patch has been
> + * sent and will be synced after the v6.8-rc1 linux
> + * tag is published
> + */
> +_udmap {
> + reg = <0x0 0x3115 0x0 0x100>,
> +   <0x0 0x3400 0x0 0x10>,
> +   <0x0 0x3500 0x0 0x10>,
> +   <0x0 0x30b0 0x0 0x1>,
> +   <0x0 0x30c0 0x0 0x1>,
> +   <0x0 0x30d0 0x0 0x8000>;
> + reg-names = "gcfg", "rchanrt", "tchanrt",
> + "tchan", "rchan", "rflow";
> +};
> +
> +/*
> + * The DMA driver requires a few extra register ranges
> + * which are missing for the am65x. A patch has been
> + * sent and will be synced after the v6.8-rc1 linux
> + * tag is published
> + */
> +_udmap {
> + reg = <0x0 0x285c 0x0 0x100>,
> +   <0x0 0x2a80 0x0 0x4>,
> +   <0x0 0x2aa0 0x0 0x4>,
> +   <0x0 0x284a 0x0 0x4000>,
> +   <0x0 0x284c 0x0 0x4000>,
> +   <0x0 0x2840 0x0 0x2000>;
> + reg-names = "gcfg", "rchanrt", "tchanrt",
> + "tchan", "rchan", "rflow";
> +};

Hopefully we can get rid of this in 6.8-rc1 sync.

[...]
Reviewed-by: Nishanth Menon 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 11/26] arm: dts: k3-am654: remove duplicate mcu_udmap

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate mcu_udmap node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-r5-base-board.dts | 13 -
>  1 file changed, 13 deletions(-)
> 
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 10/26] arm: dts: k3-am654: remove duplicate mcu_ringacc

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified, we now have a
> duplicate mcu_ringacc node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-r5-base-board.dts | 10 --
>  1 file changed, 10 deletions(-)
> 
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 09/26] arm: dts: k3-am654: remove duplicate timer

On 11:47-20231229, Bryan Brattlof wrote:
> timer1 is really just the mcu_timer0 node redefined for the WKUP SPL.
> Remove the timer1 and replace it with the mcu_timer0 from the Linux
> device tree we imported into U-Boot.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 08/26] arm: dts: k3-am654: remove duplicate wkup_uart0

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board files unified, we now have a duplicate
> wkup_uart0 node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-r5-base-board.dts | 12 
>  1 file changed, 12 deletions(-)
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 07/26] arm: dts: k3-am654: remove duplicate vtt_supply

On 11:47-20231229, Bryan Brattlof wrote:
> With the Linux and U-Boot board dtb files unified we now have a
> duplicate vtt_supply node. Remove it
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-r5-base-board.dts | 9 -
>  1 file changed, 9 deletions(-)
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 06/26] arm: dts: k3-am654: include a53 board dtb for r5 build

On 11:47-20231229, Bryan Brattlof wrote:
> To make things as organized as possible, start from the Linux board dtbs
> and apply all properties needed for U-Boot in our *-u-boot.dtsi file for
> the MAIN SPL and U-Boot builds.
> 
> We can then include these files for the WKUP SPL build making further
> edits to the needed properties and nodes for the WKUP SPL bootloader's
> view of the am65x.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-r5-base-board.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts 
> b/arch/arm/dts/k3-am654-r5-base-board.dts
> index 8f55dab508ee6..79ca6387c22bb 100644
> --- a/arch/arm/dts/k3-am654-r5-base-board.dts
> +++ b/arch/arm/dts/k3-am654-r5-base-board.dts
> @@ -5,7 +5,8 @@
>  
>  /dts-v1/;
>  
> -#include "k3-am654.dtsi"
> +#include "k3-am654-base-board.dts"
> +#include "k3-am654-base-board-u-boot.dtsi"
>  #include "k3-am654-base-board-ddr4-1600MTs.dtsi"
>  #include "k3-am654-ddr.dtsi"
[...]
Reviewed-by: Nishanth Menon 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 05/26] arm: dts: k3-am654: copy bootph properties to a53 dts

On 11:47-20231229, Bryan Brattlof wrote:
> In order to unify the R5 board dtb file with the Linux board dtb file,
> we will need to copy all bootph-pre-ram properties to the *-u-boot.dtsi
> overlay.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 160 +++
>  arch/arm/dts/k3-am654-r5-base-board.dts  |  85 +-
>  2 files changed, 162 insertions(+), 83 deletions(-)
> 
> diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
> b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> index f29cecf870bcd..4b1e8ce2c920c 100644
> --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> @@ -5,6 +5,166 @@
>  
>  #include "k3-am65x-binman.dtsi"
>  
> +_supply {
> + bootph-pre-ram;
> +};
> +
> +_main {
> + bootph-pre-ram;
> +};

I understand this in an intermediate state and the final dts looks fine.
So,
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 04/26] arm: dts: k3-am654: pull in dtb update from Linux

On 11:47-20231229, Bryan Brattlof wrote:
> Pull in dtb updates for the am654 base board from v6.7-rc1 of Linux
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  arch/arm/dts/k3-am65-main.dtsi   | 342 ++-
>  arch/arm/dts/k3-am65-mcu.dtsi| 156 ++--
>  arch/arm/dts/k3-am65-wakeup.dtsi |  10 +-
>  arch/arm/dts/k3-am65.dtsi|  19 +-
>  arch/arm/dts/k3-am654-base-board.dts | 301 ++-
>  arch/arm/dts/k3-am654.dtsi   |   7 +
>  6 files changed, 626 insertions(+), 209 deletions(-)
> 
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 03/26] arm: dts: k3-am654-r5: Merge board file and U-Boot overlay

On 11:47-20231229, Bryan Brattlof wrote:
> The R5 board file for U-Boot should be the same as the board file copied
> from Linux with a few alterations to work with the R5's view of the SoC.
> 
> First we need to unify the R5 board file and it's U-Boot overlay before
> we can unify the Linux board file with this one.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 02/26] configs: am65x_evm_a53: disable CONSOLE_MUX

On 11:46-20231229, Bryan Brattlof wrote:
> We do not have a need to share a single console with the evaluation
> board and disabling this option reduces the complexity of configuring
> the consoles. Disable CONSOLE_MUX
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  configs/am65x_evm_a53_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 

[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 01/26] configs: am65x_evm_r5: enable driver for fixed regulators

On 11:46-20231229, Bryan Brattlof wrote:
> Some of the regulators we need to successfully boot are fixed
> regulators. Enable the driver to properly probe them.
> 
> Tested-by: Tom Rini 
> Signed-off-by: Bryan Brattlof 
> ---
>  configs/am65x_evm_r5_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
[...]
Reviewed-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
> On Tue, 2 Jan 2024 at 19:36, Simon Glass  wrote:
[snip]
> > 2. Choose a directory target for devicetree-rebasing. I see that
> > 'barebox' uses 'dts' which seems better to me than
> > 'devicetree-rebasing/src/'.
> 
> Actually as part of this patch-set we try to reuse the U-Boot 'dts'
> directory (via dts/arch/arm64/ soft links) since it was
> already taken for U-Boot specific DT Makefile. However, I am open to
> renaming 'devicetree-rebasing' but to me that sounds more clear that
> we maintain a specific subtree within U-Boot.

Looking at what little is in dts/ here today could we just use subtree
and pop the contents under there, and basically ignore the
project-provided Makefile? Or is that not really worth it?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 00/26] sync am65x device tree with Linux v6.7-rc1

On Tue, Jan 02, 2024 at 08:27:34AM +0100, Jan Kiszka wrote:
> On 27.12.23 13:39, Nishanth Menon wrote:
> > On 15:00-20231221, Tom Rini wrote:
> >> On Thu, Dec 21, 2023 at 11:43:46AM -0600, Bryan Brattlof wrote:
> >>
> >>> Hello Everyone!
> >>>
> >>> This series gets the am65x booting again along with syncing the device
> >>> tree files with v6.7-rc1 Linux.
> >>>
> >>> The bulk of these patches unify the WKUP SPL board file with the arm64
> >>> files to make future syncs from Linux much easier. In the end the DTBs
> >>> should look a lot like what the DTBs look like for the am64x which
> >>> is fairly similar to the am65x.
> >>>
> >>> For those interested in what UART boot looks like:
> >>>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc
> >>>
> >>> Thanks for reviewing and happy holidays
> >>> ~Bryan
> >>
> >> For the series,
> >> Tested-by: Tom Rini 
> >>
> >> Nishanth, does this path work for you?
> >>
> > 
> > Other than the minor comments provided in the relevant patches,
> > 
> > The following files also need sync up with v6.7-rc1.
> > 
> > k3-am65-iot2050-common-pg2.dtsi
> > k3-am65-iot2050-common.dtsi
> > k3-am6528-iot2050-basic-common.dtsi
> > k3-am6548-iot2050-advanced-common.dtsi
> > k3-am6548-iot2050-advanced-m2.dts
> > 
> > Jan - could you look at syncing those once an update to this series is
> > posted? We could probably have a smoother v6.8-rc1 from then on.
> > 
> 
> We currently plan to sync once support for the new SM variant is in the
> upstream DT. Do you see other changes that would benefit from an earlier
> sync?

So this sync is because the ref platforms at least do not boot, is
iot2050 currently booting?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack

2024-01-02 Thread Maxim Uvarov

Small update here. I made changes without any board limit size changes.
Reordered patches to make them compile in sequence. I think I will do one
more clean up and more testing,
and after that will be able to send an updated version.
Working tree is here: https://github.com/u-boot/u-boot/pull/434

SPL might have a very limited network stack (current code for tftp and
bootp). While later stage bootloader can have complete protocol (lwip).
That model fits all current boards limits.

'ethrotate' variable is more likely to go away and be replaced with routing
tables and command line arguments ('dhcp all', "ping -i eth0 IP" ).

However, I have a strange issue with mips malta. Work around:
https://github.com/u-boot/u-boot/pull/434/commits/14717056115944f67eeb22571330d551a1b1ecb7
Issue is that if LWIP_TCP=0 generated code for network stack is less on few
kilobytes. In that case
qemu is unable to start and does not even print hello messages. I followed
this documentation ./doc/board/emulation/qemu-mips.rst
for qemu run. While if image size is bigger and TCP for example compiled
then qemu boots and operates fine. For now
this issue is a little bit strange for me. And more strange how that
related to lwip code, because the network works on much later
stage then initial messages print.

Thanks,
Maxim.

On Tue, 19 Dec 2023 at 16:12, Alexander Dahl  wrote:

> Hello Maxim,
>
> Am Mon, Nov 27, 2023 at 06:56:43PM +0600 schrieb Maxim Uvarov:
> > Hello,
> >
> > Please find updated version of lwip patches. Changes are in the
> > changelog bellow.
> >
> > Thank you,
> > Maxim.
> >
> > changelog:
> >   v11: - v11 is mosly respin of v10 patches with CI error fixes.
> > Gitlab CI:
> >
> https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/18368
> > Azure CI:
> >
> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=7366=results
> > (Azure CI, which is connected to github. Sometime I can
> see
> >  tftp timeout after some part of download there, but
> that can not be
> >  reproduced locally. While Gitblab CI is stable. Because
> of num tries in
> >  CI I suspect this CI was not always reliable.)
> > Azure and Gitlab also have different toolchains and I
> > would say Gitlab generates bigger code then Azure CI.
> >
> > Also many boards have a binary limit size of 800k (even
> > qemu has limits). And increased limits to fit all the
> code. Specially did it
> > patch by board config to show which boards are failing
> to build. There I have
> > a question if we really want to support new
> functionality for old boards (mips,
> > arm32 and etc...). I hope board owners can help me if
> > it's valid to increase these limits.
>
> In general one can not simply increase that limit without knowing
> details on where U-Boot binary is supposed to be stored on a
> particular board.  For example there are boards where U-Boot is stored
> on NAND flash with fixed sized (mtd) partitions.  Changing the
> partition layout on a running board is quite risky from my point of
> view, so you can assume that partition sizes fixed at all times.
> Those sizes determine the limit however.  That said: it has to be
> checked board by board if such a limit can be increased at all.
>
> Greets
> Alex
>
> >
> >   In this version I used git submodules and friend CI with
> >   submodules. But I don't mind if you decide to maintain it
> in a different
> >   way.
> >
> >
> >   v10: - fix ping with following tftp command issue with incorrect
> >   ping timeout clear.
> >- Makefile on make will init submodules and if needed will
> >  do git clone.
> >- wget - some minor code style changes.
> >   v9: - added first patch describing git submodule for lwip. So
> > the build procedure is:
> >   git submodule init
> >   git submodule update
> >   make
> >   - reworked a little bit dhcp cmd state polling
> >   - fixed review comments for v8
> >   v8: - comments for previous review
> >   - removed lwip timeout callback pointer
> >   - made lwip timeouts works, that also allowed to remove
> > static vars.
> >   - setenv for filesize tftp and wget has to be in hex.
> >   - Makefile changes always compile it tftp,dns,wget,ping due
> > to it can be used not only by CONFIG_CMD_.
> >   - Kconfig changes - simplify lwIP settings and support only
> > one configuration.
> >   - tested with mini debian.iso load over http or tftp, mount
> > and boot it (qemu, arm64).
> >   v7: - more review fixes.
> >   - support of multiply eth devices, were "ethact" selects the
> >

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-02 Thread Ahmad Fatoum

Hello Yamada-san,

On 14.12.23 08:33, Masahiro Yamada wrote:
>> The FIT spec allows the "fdt" property to list
>> multiple image nodes.
>>
>>
>> o config-1
>>  |- description = "configuration description"
>>  |- kernel = "kernel sub-node unit name"
>>  |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
>>  |- loadables = "loadables sub-node unit-name"
>>  |- script = "
>>  |- compatible = "vendor
> 
> 
> 
> 
> 
> This is a question for U-Boot (and barebox).
> 
> 
> 
> 
>images {
>   base {
> ...
>   };
> 
>   addon1 {
> ...
>   };
> 
>   addon2 {
> ...
>   };
> };
> 
> configurations {
>   ...
>   fdt = "base", "addon1", "addon2";
> };
> 
> 
> 
> 
> Is U-Boot's "bootm" command able to dynamically construct
> the full DTB from "base" + "addon1" + "addon2"
> and pass to the kernel?

barebox can apply overlays to the DT, but doesn't do so yet from
the extra entries in configuration fdt properties.

This should be straight-forward to add though, if the need arises.

> Is U-Boot able to handle FIT (includes kernel + DTs)
> and a separate initrd?
> 
>   # bootm  :  

This is possible in barebox, provided that the FIT image doesn't
already have a ramdisk and that CONFIG_BOOTM_FORCE_SIGNED_IMAGES=n:

  bootm -r /mnt/nfs/ramdisk.gz /mnt/nfs/image.fit

(Or the equivalent variables if not wanting to use the shell.)

> Presumably, it would be difficult to inject initramdisk
> into image.fit later, so I am hoping bootm would work like that,
> but I did not delve into U-Boot code.
> 
> 
> 
> If it works, is it possible to verify the integrity of initrd?
> The kernel and DTs inside FIT will be verified, but not sure
> if it is possible for ramdisk.

If one wants to preclude mix & match attacks, the configuration needs
to be verified fully, so if signing is required, it's probably better to
amend the FIT later on with the new configuration instead of signing
the initrd separately and combining them at runtime.

Cheers,
Ahmad

> 
> 
> 
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH V4 7/7] doc: board: anbernic: Update rgxx3 to add new boards

From: Chris Morgan 

Update the RGxx3 documentation to note that it now supports the
RG-ARC-D, RG-ARC-S, Powkiddy RK2023, and Powkiddy RGB30. Also update
verbiage around panel detection to note that it is no longer hard coded
to the RG503.

Signed-off-by: Chris Morgan 
---
 doc/board/anbernic/rgxx3.rst | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/doc/board/anbernic/rgxx3.rst b/doc/board/anbernic/rgxx3.rst
index 7d1beb423c..d159ed2f76 100644
--- a/doc/board/anbernic/rgxx3.rst
+++ b/doc/board/anbernic/rgxx3.rst
@@ -5,6 +5,8 @@ U-Boot for Anbernic RGxx3 Devices
 
 This allows U-Boot to boot the following Anbernic devices:
 
+ - Anbernic RG-ARC-D
+ - Anbernic RG-ARC-S
  - Anbernic RG353M
  - Anbernic RG353P
  - Anbernic RG353PS
@@ -12,18 +14,24 @@ This allows U-Boot to boot the following Anbernic devices:
  - Anbernic RG353VS
  - Anbernic RG503
 
+Additionally, the following very similar non-Anbernic devices are also
+supported:
+
+ - Powkiddy RGB30
+ - Powkiddy RK2023
+
 The correct device is detected automatically by comparing ADC values
 from ADC channel 1. In the event of an RG353V or RG353P, an attempt
 is then made to probe for an eMMC and if it fails the device is assumed
 to be an RG353VS or RG353PS. Based on the detected device, the
 environment variables "board", "board_name", and "fdtfile" are set to
 the correct values corresponding to the board which can be read by a
-boot script to boot with the correct device tree. If the board detected
-is not of type RG503 (which currently has only 1 panel revision) a
-panel detect is then performed by probing a "dummy" display on the DSI
-bus and then querying the display ID. The display ID is then compared
-to a table to get the known compatible string for use in Linux, and
-this string is saved as an environment variable of "panel".
+boot script to boot with the correct device tree. If a board is defined
+as requiring panel detection, a panel detect is then performed by
+probing a "dummy" display on the DSI bus and then querying the display
+ID. The display ID is then compared to a table to get the known
+compatible string for use in Linux, and this string is saved as an
+environment variable of "panel".
 
 FDT fixups are performed in the event of an RG353M to change the device
 name, or in the event the panel detected does not match the devicetree.
-- 
2.34.1

[PATCH V4 6/7] board: rockchip: Add support for new boards to RGxx3

From: Chris Morgan 

Add support for the Anbernic RG-ARC-D, Anbernic RG-ARC-S, Powkiddy
RK2023, and Powkiddy RGB30 to the Anbernic RGxx3. While the Powkiddy
devices are manufactured by Powkiddy instead of Anbernic,
the hardware is so similar they can all use the same bootloader.

Signed-off-by: Chris Morgan 
---
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 44 +++---
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 7bef5a53f0..e12a85a02a 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -48,9 +48,13 @@ enum rgxx3_device_id {
RG353P,
RG353V,
RG503,
+   RGB30,
+   RK2023,
+   RGARCD,
/* Devices with duplicate ADC value */
RG353PS,
RG353VS,
+   RGARCS,
 };
 
 static const struct rg3xx_model rg3xx_model_details[] = {
@@ -83,6 +87,27 @@ static const struct rg3xx_model rg3xx_model_details[] = {
.fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
.detect_panel = 0,
},
+   [RGB30] = {
+   .adc_value = 383, /* Gathered from second hand information */
+   .board = "rk3566-powkiddy-rgb30",
+   .board_name = "RGB30",
+   .fdtfile = DTB_DIR "rk3566-powkiddy-rgb30.dtb",
+   .detect_panel = 0,
+   },
+   [RK2023] = {
+   .adc_value = 635, /* Observed average from device */
+   .board = "rk3566-powkiddy-rk2023",
+   .board_name = "RK2023",
+   .fdtfile = DTB_DIR "rk3566-powkiddy-rk2023.dtb",
+   .detect_panel = 0,
+   },
+   [RGARCD] = {
+   .adc_value = 183, /* Observed average from device */
+   .board = "rk3566-anbernic-rg-arc-d",
+   .board_name = "Anbernic RG ARC-D",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg-arc-d.dtb",
+   .detect_panel = 0,
+   },
/* Devices with duplicate ADC value */
[RG353PS] = {
.adc_value = 860, /* Observed average from device */
@@ -98,6 +123,13 @@ static const struct rg3xx_model rg3xx_model_details[] = {
.fdtfile = DTB_DIR "rk3566-anbernic-rg353vs.dtb",
.detect_panel = 1,
},
+   [RGARCS] = {
+   .adc_value = 183, /* Observed average from device */
+   .board = "rk3566-anbernic-rg-arc-s",
+   .board_name = "Anbernic RG ARC-S",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg-arc-s.dtb",
+   .detect_panel = 0,
+   },
 };
 
 struct rg353_panel {
@@ -332,19 +364,21 @@ int rgxx3_detect_device(void)
}
 
/*
-* Try to access the eMMC on an RG353V or RG353P. If it's
-* missing, it's an RG353VS or RG353PS. Note we could also
-* check for a touchscreen at 0x1a on i2c2.
+* Try to access the eMMC on an RG353V, RG353P, or RG Arc D.
+* If it's missing, it's an RG353VS, RG353PS, or RG Arc S.
+* Note we could also check for a touchscreen at 0x1a on i2c2.
 */
-   if (board_id == RG353V || board_id == RG353P) {
+   if (board_id == RG353V || board_id == RG353P || board_id == RGARCD) {
mmc = find_mmc_device(0);
if (mmc) {
ret = mmc_init(mmc);
if (ret) {
if (board_id == RG353V)
board_id = RG353VS;
-   else
+   else if (board_id == RG353P)
board_id = RG353PS;
+   else
+   board_id = RGARCS;
}
}
}
-- 
2.34.1

[PATCH V4 5/7] rockchip: board: Add board_rng_seed() for all Rockchip devices

From: Chris Morgan 

Allow all rockchip devices to use the hardware RNG to seed Linux
RNG.

Signed-off-by: Chris Morgan 
---
 arch/arm/mach-rockchip/board.c | 32 ++
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 29 
 2 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 57f08e0be0..77145524ea 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -348,3 +348,35 @@ __weak int misc_init_r(void)
return ret;
 }
 #endif
+
+#if IS_ENABLED(CONFIG_BOARD_RNG_SEED) && IS_ENABLED(CONFIG_RNG_ROCKCHIP)
+#include 
+
+/* Use hardware rng to seed Linux random. */
+__weak int board_rng_seed(struct abuf *buf)
+{
+   struct udevice *dev;
+   size_t len = 0x8;
+   u64 *data;
+
+   data = malloc(len);
+   if (!data) {
+   printf("Out of memory\n");
+   return -ENOMEM;
+   }
+
+   if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
+   printf("No RNG device\n");
+   return -ENODEV;
+   }
+
+   if (dm_rng_read(dev, data, len)) {
+   printf("Reading RNG failed\n");
+   return -EIO;
+   }
+
+   abuf_init_set(buf, data, len);
+
+   return 0;
+}
+#endif
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 45854709f5..7bef5a53f0 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -137,34 +136,6 @@ void spl_board_init(void)
   (GPIO0_BASE + GPIO_SWPORT_DR_H));
 }
 
-/* Use hardware rng to seed Linux random. */
-int board_rng_seed(struct abuf *buf)
-{
-   struct udevice *dev;
-   size_t len = 0x8;
-   u64 *data;
-
-   data = malloc(len);
-   if (!data) {
-   printf("Out of memory\n");
-   return -ENOMEM;
-   }
-
-   if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
-   printf("No RNG device\n");
-   return -ENODEV;
-   }
-
-   if (dm_rng_read(dev, data, len)) {
-   printf("Reading RNG failed\n");
-   return -EIO;
-   }
-
-   abuf_init_set(buf, data, len);
-
-   return 0;
-}
-
 /*
  * Buzz the buzzer so the user knows something is going on. Make it
  * optional in case PWM is disabled.
-- 
2.34.1

[PATCH V4 4/7] board: rockchip: Add Recovery Button for Anbernic RGxx3

From: Chris Morgan 

Add support for users to enter recovery mode by holding the function
button when they power up the device.

Since the device has soldered eMMC and sometimes does not expose a clk
pin on the mainboard there is a small chance that a user who flashes a
bad bootloader may not be able to recover if the headers themselves
are valid. As a result this check is done during spl_early_init() to
ensure that it runs as early as possible, and it does so by directly
manipulating the ADC hardware in lieu of loading the ADC driver.

Signed-off-by: Chris Morgan 
---
 arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi | 11 +++
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c |  6 +-
 configs/anbernic-rgxx3-rk3566_defconfig| 16 
 include/configs/anbernic-rgxx3-rk3566.h|  2 ++
 4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi 
b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
index f986e1941e..e3ab196d22 100644
--- a/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
+++ b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
@@ -76,6 +76,12 @@
/delete-property/ clock-names;
 };
 
+ {
+   bootph-all;
+   vref-supply = <_sys>;
+   status = "okay";
+};
+
  {
pinctrl-0 = <_bus8>, <_clk>, <_cmd>,
<_datastrobe>, <_rstnout>;
@@ -94,3 +100,8 @@
bootph-all;
status = "okay";
 };
+
+_sys {
+   bootph-all;
+   status = "okay";
+};
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3d0c614623..45854709f5 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -119,11 +120,14 @@ static const struct rg353_panel rg353_panel_details[] = {
 };
 
 /*
- * Start LED very early so user knows device is on. Set color
+ * Check if rockchip_dnl button is pressed and reboot into rockusb if
+ * true. Start LED very early so user knows device is on. Set color
  * to red.
  */
 void spl_board_init(void)
 {
+   setup_boot_mode();
+
/* Set GPIO0_C5, GPIO0_C6, and GPIO0_C7 to output. */
writel(GPIO_WRITEMASK(GPIO_C7 | GPIO_C6 | GPIO_C5) | \
   (GPIO_C7 | GPIO_C6 | GPIO_C5),
diff --git a/configs/anbernic-rgxx3-rk3566_defconfig 
b/configs/anbernic-rgxx3-rk3566_defconfig
index ed6643d9d4..4e72f75815 100644
--- a/configs/anbernic-rgxx3-rk3566_defconfig
+++ b/configs/anbernic-rgxx3-rk3566_defconfig
@@ -3,6 +3,7 @@ CONFIG_SKIP_LOWLEVEL_INIT=y
 CONFIG_COUNTER_FREQUENCY=2400
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_TEXT_BASE=0x00a0
+CONFIG_SPL_GPIO=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
@@ -24,7 +25,9 @@ CONFIG_SYS_LOAD_ADDR=0xc00800
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3566-anbernic-rgxx3.dtb"
@@ -32,7 +35,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3566-anbernic-rgxx3.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_RNG_SEED=y
-CONFIG_SPL_MAX_SIZE=0x2
+CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x400
@@ -41,6 +44,8 @@ CONFIG_SPL_BOARD_INIT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_ADC=y
+CONFIG_SPL_POWER=y
 CONFIG_SPL_ATF=y
 CONFIG_CMD_PWM=y
 CONFIG_CMD_GPT=y
@@ -50,8 +55,10 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_DOS_PARTITION is not set
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 # CONFIG_NET is not set
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
 CONFIG_SPL_CLK=y
@@ -67,13 +74,13 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
 CONFIG_PHY_ROCKCHIP_INNO_DSIDPHY=y
+CONFIG_SPL_PINCTRL=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_PMIC_FAN53555=y
 CONFIG_PMIC_RK8XX=y
-CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_SPL_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
-CONFIG_DM_REGULATOR_SCMI=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_SPL_RAM=y
 # CONFIG_RAM_ROCKCHIP_DEBUG is not set
@@ -89,5 +96,6 @@ CONFIG_VIDEO_ROCKCHIP=y
 CONFIG_DISPLAY_ROCKCHIP_DW_MIPI=y
 CONFIG_VIDEO_BRIDGE=y
 CONFIG_REGEX=y
+# CONFIG_RSA is not set
 CONFIG_ERRNO_STR=y
 # CONFIG_EFI_LOADER is not set
diff --git a/include/configs/anbernic-rgxx3-rk3566.h 
b/include/configs/anbernic-rgxx3-rk3566.h
index 3c4ea4e7d8..2aaac55c06 100644
--- a/include/configs/anbernic-rgxx3-rk3566.h
+++ b/include/configs/anbernic-rgxx3-rk3566.h
@@ -9,4 +9,6 @@

[PATCH V4 3/7] rockchip: boot_mode: Allow rockchip_dnl_key_pressed() in SPL

From: Chris Morgan 

Update the rockchip_dnl_key_pressed() so that it can run in
SPL. Also change the ADC channel to a define that can be
overridden by a board specific option.

Signed-off-by: Chris Morgan 
---
 arch/arm/mach-rockchip/Makefile|  4 ++--
 arch/arm/mach-rockchip/boot_mode.c | 11 ++-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 1dc92066bb..ff089ae949 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
 
 obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
 
-ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
-
 # Always include boot_mode.o, as we bypass it (i.e. turn it off)
 # inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0.  This way,
 # we can have the preprocessor correctly recognise both 0x0 and 0
 # meaning "turn it off".
 obj-y += boot_mode.o
+
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
 obj-$(CONFIG_MISC_INIT_R) += misc.o
 endif
diff --git a/arch/arm/mach-rockchip/boot_mode.c 
b/arch/arm/mach-rockchip/boot_mode.c
index eb8f65ae4e..d2308768be 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -38,6 +38,10 @@ void set_back_to_bootrom_dnl_flag(void)
 #define KEY_DOWN_MIN_VAL   0
 #define KEY_DOWN_MAX_VAL   30
 
+#ifndef RK_DNL_ADC_CHAN
+#define RK_DNL_ADC_CHAN1
+#endif
+
 __weak int rockchip_dnl_key_pressed(void)
 {
unsigned int val;
@@ -52,7 +56,8 @@ __weak int rockchip_dnl_key_pressed(void)
ret = -ENODEV;
uclass_foreach_dev(dev, uc) {
if (!strncmp(dev->name, "saradc", 6)) {
-   ret = adc_channel_single_shot(dev->name, 1, );
+   ret = adc_channel_single_shot(dev->name,
+ RK_DNL_ADC_CHAN, );
break;
}
}
@@ -73,11 +78,13 @@ __weak int rockchip_dnl_key_pressed(void)
 
 void rockchip_dnl_mode_check(void)
 {
+#if CONFIG_IS_ENABLED(ADC)
if (rockchip_dnl_key_pressed()) {
printf("download key pressed, entering download mode...");
set_back_to_bootrom_dnl_flag();
do_reset(NULL, 0, 0, NULL);
}
+#endif
 }
 
 int setup_boot_mode(void)
@@ -90,6 +97,7 @@ int setup_boot_mode(void)
boot_mode = readl(reg);
debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
 
+#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
/* Clear boot mode */
writel(BOOT_NORMAL, reg);
 
@@ -103,6 +111,7 @@ int setup_boot_mode(void)
env_set("preboot", "setenv preboot; ums mmc 0");
break;
}
+#endif
 
return 0;
 }
-- 
2.34.1

[PATCH V4 2/7] spl: Add Kconfig options for ADC

From: Chris Morgan 

Add kconfig options to enable ADC in SPL

Signed-off-by: Chris Morgan 
---
 common/spl/Kconfig   | 7 +++
 drivers/Makefile | 1 +
 drivers/adc/Makefile | 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index c521b02f4a..ada9dcea5c 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -579,6 +579,13 @@ config SPL_FIT_IMAGE_TINY
  ensure this information is available to the next image
  invoked).
 
+config SPL_ADC
+   bool "Support ADC drivers"
+   help
+ Enable ADC drivers in SPL. These drivers can allow the reading of
+ analog values from one or more channels. Enable this option to
+ build the drivers in drivers/adc as part of an SPL build.
+
 config SPL_CACHE
bool "Support CACHE drivers"
help
diff --git a/drivers/Makefile b/drivers/Makefile
index bf73b7718c..81ba2c534e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+obj-$(CONFIG_$(SPL_)ADC) += adc/
 obj-$(CONFIG_$(SPL_TPL_)BIOSEMU) += bios_emulator/
 obj-$(CONFIG_$(SPL_TPL_)BLK) += block/
 obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index 5336c82097..9eb07769b0 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -4,7 +4,7 @@
 # Przemyslaw Marczak 
 #
 
-obj-$(CONFIG_ADC) += adc-uclass.o
+obj-$(CONFIG_$(SPL_)ADC) += adc-uclass.o
 obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
 obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
 obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o
-- 
2.34.1

[PATCH V4 1/7] board: rockchip: Refactor panel auto-detect code

From: Chris Morgan 

Make the inability to detect a panel using the auto detection code not
fail the entire boot process. This means that if the panel ID cannot
be read we don't set an environment variable for the panel, and if an
environment variable for the panel is not set we don't attempt to
update the compatible string. Changes to the code also ensure that
when there are multiple compatible strings required for the panel
we use them both, which solves some issues that will pop up soon
for the Linux driver.

Signed-off-by: Chris Morgan 
---
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 115 +
 1 file changed, 74 insertions(+), 41 deletions(-)

diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3f1a42d184..3d0c614623 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -40,6 +40,7 @@ struct rg3xx_model {
const char *board;
const char *board_name;
const char *fdtfile;
+   const bool detect_panel;
 };
 
 enum rgxx3_device_id {
@@ -54,52 +55,67 @@ enum rgxx3_device_id {
 
 static const struct rg3xx_model rg3xx_model_details[] = {
[RG353M] = {
-   517, /* Observed average from device */
-   "rk3566-anbernic-rg353m",
-   "RG353M",
-   DTB_DIR "rk3566-anbernic-rg353p.dtb", /* Identical devices */
+   .adc_value = 517, /* Observed average from device */
+   .board = "rk3566-anbernic-rg353m",
+   .board_name = "RG353M",
+   /* Device is identical to RG353P. */
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb",
+   .detect_panel = 1,
},
[RG353P] = {
-   860, /* Documented value of 860 */
-   "rk3566-anbernic-rg353p",
-   "RG353P",
-   DTB_DIR "rk3566-anbernic-rg353p.dtb",
+   .adc_value = 860, /* Documented value of 860 */
+   .board = "rk3566-anbernic-rg353p",
+   .board_name = "RG353P",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb",
+   .detect_panel = 1,
},
[RG353V] = {
-   695, /* Observed average from device */
-   "rk3566-anbernic-rg353v",
-   "RG353V",
-   DTB_DIR "rk3566-anbernic-rg353v.dtb",
+   .adc_value = 695, /* Observed average from device */
+   .board = "rk3566-anbernic-rg353v",
+   .board_name = "RG353V",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353v.dtb",
+   .detect_panel = 1,
},
[RG503] = {
-   1023, /* Observed average from device */
-   "rk3566-anbernic-rg503",
-   "RG503",
-   DTB_DIR "rk3566-anbernic-rg503.dtb",
+   .adc_value = 1023, /* Observed average from device */
+   .board = "rk3566-anbernic-rg503",
+   .board_name = "RG503",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
+   .detect_panel = 0,
},
/* Devices with duplicate ADC value */
[RG353PS] = {
-   860, /* Observed average from device */
-   "rk3566-anbernic-rg353ps",
-   "RG353PS",
-   DTB_DIR "rk3566-anbernic-rg353ps.dtb",
+   .adc_value = 860, /* Observed average from device */
+   .board = "rk3566-anbernic-rg353ps",
+   .board_name = "RG353PS",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353ps.dtb",
+   .detect_panel = 1,
},
[RG353VS] = {
-   695, /* Gathered from second hand information */
-   "rk3566-anbernic-rg353vs",
-   "RG353VS",
-   DTB_DIR "rk3566-anbernic-rg353vs.dtb",
+   .adc_value = 695, /* Gathered from second hand information */
+   .board = "rk3566-anbernic-rg353vs",
+   .board_name = "RG353VS",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353vs.dtb",
+   .detect_panel = 1,
},
 };
 
 struct rg353_panel {
const u16 id;
-   const char *panel_compat;
+   const char *panel_compat[2];
 };
 
 static const struct rg353_panel rg353_panel_details[] = {
-   { .id = 0x3052, .panel_compat = "newvision,nv3051d"},
-   { .id = 0x3821, .panel_compat = "anbernic,rg353v-panel-v2"},
+   {
+   .id = 0x3052,
+   .panel_compat[0] = "anbernic,rg353p-panel",
+   .panel_compat[1] = "newvision,nv3051d",
+   },
+   {
+   .id = 0x3821,
+   .panel_compat[0] = "anbernic,rg353v-panel-v2",
+   .panel_compat[1] = NULL,
+   },
 };
 
 /*
@@ -298,11 +314,10 @@ int rgxx3_detect_display(void)
if (!panel) {
printf("Unable to identify panel_id %x\n",
   (panel_id[0] << 8) |

[PATCH V4 0/7] Add Additional Boards and Features to RGxx3

From: Chris Morgan 

The RGxx3 is a pseudo-device for U-Boot that works for every Anbernic
RGxx3 series device on the market. Add support for another series of
very similar devices from Powkiddy.

Changes since V3:
 - Fixed a bug with else/else if logic for board detection (changed
   a second incorrect "if" to the proper "else if").

Changes since V2:
 - Modify the mach-rockchip level rockchip_dnl_key_pressed() so that
   we can also call it in SPL mode and eliminate the board specific
   function. This requires adding ADC support to SPL. Additionally,
   I had to change the regulator for the saradc to a fixed regulator
   and add GPIO and regulator support to SPL.
 - Move the board specific board_rng_seed to the mach-rockchip level
   board file so that other rockchip boards with a hardware RNG can
   benefit. This should only be called if both the Rockchip
   hardware RNG as well as the rng seed functions are enabled.
 - Add two new boards (the RG-ARC-D and RG-ARC-S). I removed the
   previous code review due to the extensive changes made.

Changes since V1:
 - Update verbiage around function button to say "recovery" mode
   instead of calling it "maskrom" mode, which has a specific
   meaning. Also note that recovery function was done in a board
   specific manner to ensure it can run early.
 - Update board level documentation for the RGxx3.

Chris Morgan (7):
  board: rockchip: Refactor panel auto-detect code
  spl: Add Kconfig options for ADC
  rockchip: boot_mode: Allow rockchip_dnl_key_pressed() in SPL
  board: rockchip: Add Recovery Button for Anbernic RGxx3
  rockchip: board: Add board_rng_seed() for all Rockchip devices
  board: rockchip: Add support for new boards to RGxx3
  doc: board: anbernic: Update rgxx3 to add new boards

 .../arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi |  11 +
 arch/arm/mach-rockchip/Makefile   |   4 +-
 arch/arm/mach-rockchip/board.c|  32 +++
 arch/arm/mach-rockchip/boot_mode.c|  11 +-
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c| 194 +++---
 common/spl/Kconfig|   7 +
 configs/anbernic-rgxx3-rk3566_defconfig   |  16 +-
 doc/board/anbernic/rgxx3.rst  |  20 +-
 drivers/Makefile  |   1 +
 drivers/adc/Makefile  |   2 +-
 include/configs/anbernic-rgxx3-rk3566.h   |   2 +
 11 files changed, 210 insertions(+), 90 deletions(-)

-- 
2.34.1

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

2024-01-02 Thread Sumit Garg

On Tue, 2 Jan 2024 at 19:36, Simon Glass  wrote:
>
> Hi Tom,
>
> On Mon, Jan 1, 2024 at 4:35 PM Tom Rini  wrote:
> >
> > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > Hi Mark, Tom,
> > >
> > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis  
> > > wrote:
> > > >
> > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > From: Tom Rini 
> > > > >
> > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > Hi Sumit,
> > > > > >
> > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote:
> > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Allow platform owners to mirror devicetree files from 
> > > > > > > > > > > > > devitree-rebasing
> > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present 
> > > > > > > > > > > > > in arch/$(ARCH)/dts
> > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This will help easy migration for platforms which 
> > > > > > > > > > > > > currently are compliant
> > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > --
> > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > --
> > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > >
> > > > > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > >   enables a live tree which is available 
> > > > > > > > > > > > > after relocation,
> > > > > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > +   bool "Enable use of devicetree imported from 
> > > > > > > > > > > > > Linux kernel release"
> > > > > > > > > > > > > +   help
> > > > > > > > > > > > > + Traditionally, U-Boot platforms used to 
> > > > > > > > > > > > > have their custom devicetree
> > > > > > > > > > > > > + files or copy devicetree files from Linux 
> > > > > > > > > > > > > kernel which are hard to
> > > > > > > > > > > > > + maintain and can usually get out-of-sync 
> > > > > > > > > > > > > from Linux kernel. This
> > > > > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > > > > + a regular sync will be maintained every 
> > > > > > > > > > > > > major Linux kernel release
> > > > > > > > > > > > > + cycle. However, platforms can still have 
> > > > > > > > > > > > > some custom u-boot specific
> > > > > > > > > > > > > + bits maintained as part of *-u-boot.dtsi 
> > > > > > > > > > > > > files.
> > > > > > > > > > > >
> > > > > > > > > > > > My only other suggestion here is to mention that this 
> > > > > > > > > > > > should be set in
> > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that 
> > > > > > > > > > > > means that it
> > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > >
> > > > > > > > > > > >   bool  # Enable use of devicetree imported from 
> > > > > > > > > > > > Linux kernel release
> > > > > > > > > > >
> > > > > > > > > > > I

Re: [PATCH v7 4/9] arm: dts: k3-binman: Add k3-security.h and include it in k3-binman.dtsi

2024-01-02 Thread Andrew Davis


On 12/29/23 4:46 AM, Manorit Chawdhry wrote:

For readability during configuring firewalls, adding k3-security.h file
and including it in k3-binman.dtsi to be accessible across K3 SoCs

Reviewed-by: Simon Glass 
Signed-off-by: Manorit Chawdhry 
---
  arch/arm/dts/k3-binman.dtsi | 49 ++
  arch/arm/dts/k3-security.h  | 58 +
  2 files changed, 107 insertions(+)

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index cd9926a01696..758c8bf6ea16 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -3,6 +3,8 @@
   * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
https://www.ti.com/
   */
  
+#include "k3-security.h"

+
  / {
binman: binman {
multiple-images;
@@ -437,6 +439,53 @@
};
};
};
+   firewall_bg_1: template-5 {
+   control = <(FWCTRL_EN | FWCTRL_LOCK |
+   FWCTRL_BG | FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>;
+   start_address = <0x0 0x0>;
+   end_address = <0xff 0x>;
+   };
+   firewall_bg_3: template-6 {
+   insert-template = <_bg_1>;
+   permissions = <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>,
+ <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>,
+ <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>;
+   };
+   firewall_armv8_atf_fg: template-7 {
+   control = <(FWCTRL_EN | FWCTRL_LOCK |
+   FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ARMV8 << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD)>;
+   start_address = <0x0 0x7000>;


Still don't like hardcoding the ATF firewall location here, especially
since it is dynamic and we have a var for this: CONFIG_K3_ATF_LOAD_ADDR.

Not a blocker, for now..,

Reviewed-by: Andrew Davis 


+   end_address = <0x0 0x7001>;
+   };
+   firewall_armv8_optee_fg: template-8 {
+   control = <(FWCTRL_EN | FWCTRL_LOCK |
+   FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ARMV8 << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD)>;
+   start_address = <0x0 0x9e80>;
+   end_address = <0x0 0x9fff>;
+   };
  
  };
  
diff --git a/arch/arm/dts/k3-security.h b/arch/arm/dts/k3-security.h

new file mode 100644
index ..33609caa8fb5
--- /dev/null
+++ b/arch/arm/dts/k3-security.h
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef DTS_ARM64_TI_K3_FIREWALL_H
+#define DTS_ARM64_TI_K3_FIREWALL_H
+
+#define FWPRIVID_ALL0xc3
+#define FWPRIVID_ARMV8  1
+#define FWPRIVID_SHIFT  16
+
+#define FWCTRL_EN 0xA
+#define FWCTRL_LOCK   (1 << 4)
+#define FWCTRL_BG (1 << 8)
+#define FWCTRL_CACHE  (1 << 9)
+
+#define FWPERM_SECURE_PRIV_WRITE  (1 << 0)
+#define FWPERM_SECURE_PRIV_READ   (1 << 1)
+#define FWPERM_SECURE_PRIV_CACHEABLE  (1 << 2)
+#define FWPERM_SECURE_PRIV_DEBUG  (1 << 3)
+
+#define FWPERM_SECURE_PRIV_RWCD   (FWPERM_SECURE_PRIV_READ | \
+  
FWPERM_SECURE_PRIV_WRITE | \
+

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, Jan 1, 2024 at 4:35 PM Tom Rini  wrote:
> >
> > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > Hi Mark, Tom,
> > >
> > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis  
> > > wrote:
> > > >
> > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > From: Tom Rini 
> > > > >
> > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > Hi Sumit,
> > > > > >
> > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote:
> > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Allow platform owners to mirror devicetree files from 
> > > > > > > > > > > > > devitree-rebasing
> > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present 
> > > > > > > > > > > > > in arch/$(ARCH)/dts
> > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This will help easy migration for platforms which 
> > > > > > > > > > > > > currently are compliant
> > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > --
> > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > --
> > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > >
> > > > > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > >   enables a live tree which is available 
> > > > > > > > > > > > > after relocation,
> > > > > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > +   bool "Enable use of devicetree imported from 
> > > > > > > > > > > > > Linux kernel release"
> > > > > > > > > > > > > +   help
> > > > > > > > > > > > > + Traditionally, U-Boot platforms used to 
> > > > > > > > > > > > > have their custom devicetree
> > > > > > > > > > > > > + files or copy devicetree files from Linux 
> > > > > > > > > > > > > kernel which are hard to
> > > > > > > > > > > > > + maintain and can usually get out-of-sync 
> > > > > > > > > > > > > from Linux kernel. This
> > > > > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > > > > + a regular sync will be maintained every 
> > > > > > > > > > > > > major Linux kernel release
> > > > > > > > > > > > > + cycle. However, platforms can still have 
> > > > > > > > > > > > > some custom u-boot specific
> > > > > > > > > > > > > + bits maintained as part of *-u-boot.dtsi 
> > > > > > > > > > > > > files.
> > > > > > > > > > > >
> > > > > > > > > > > > My only other suggestion here is to mention that this 
> > > > > > > > > > > > should be set in
> > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that 
> > > > > > > > > > > > means that it
> > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > >
> > > > > > > > > > > >   bool  # Enable use of devicetree imported from 
> > > > > > > > > > > > Linux kernel release
> > > > > > > > > > >
> > > > > > >

Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets

2024-01-02 Thread Andrew Davis

On 12/31/23 6:48 AM, Simon Glass wrote:

Hi,

On Wed, Nov 29, 2023 at 7:48 PM Simon Glass wrote:

Hi Andrew,

On Mon, 6 Nov 2023 at 11:05, Andrew Davis wrote:

On 11/6/23 11:47 AM, Simon Glass wrote:

Hi Andrew,

On Mon, 6 Nov 2023 at 10:27, Andrew Davis wrote:

On 11/6/23 9:31 AM, Tom Rini wrote:

On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:

Hi Simon,

On 11:22-20231005, Simon Glass wrote:

Hi Nishanth,

On Thu, 5 Oct 2023 at 11:16, Nishanth Menon wrote:

On 12:10-20231005, Nishanth Menon wrote:

On 12:36-20231005, Tom Rini wrote:

On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:

On 10/4/23 8:54 AM, Nishanth Menon wrote:

On 08:48-20231004, Andrew Davis wrote:

On 10/4/23 8:23 AM, Roger Quadros wrote:

ti_mmc is not a valid boot_target for standard boot flow so

Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?

envboot takes care of uEnv.txt file (see
https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)

Early remote proc loading and FIT image is a question for stdboot itself.

If stdboot is missing these features then we shouldn't switch until it
has them. I'm all for switching to this, but only if it is complete.

Depends on what you mean? Did you mean an option to run scripts
(exists) or an option to do what TI needs done, via
boot/bootmeth_something.c ? If the latter, someone from TI needs to
figure out what that should be and do (but plumbing-wise everything it
needs should exist).

Andrew is generalizing here (on the wrong patch though).

On am62x platforms, there is nothing regressing with this series. The
challenge is early remote_proc loading which is done for J7* platforms.

How that is initiated as part of bootmethods is something of a gap.

The other gap has been support for uEnv.txt -> which we can workaround
at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
-lb" in defconfig (This series from Roger already does that - hence I am
saying that Andrew is complaining on the wrong series).

Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan-lb" and
uEnv.txt remoteproc loads and the various standard bootmethods should
"just work".

I forgot to add: FIT image authenticated boot flow. That is really what
ti_mmc distroboot method was trying to solve.

Maybe Simon or someone know how the stdboot flow handles authenticated
kernel image and dtb boot flow with FIT image?

Yes you can use FIT configuration verification and things should work as normal.

Could you give any reference documentation for this?

I suspect you should start with doc/usage/fit/beaglebone_vboot.rst

From that doc:

```
Boot the board using the commands below::

setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro
rootfstype=ext4 rootwait
ext2load mmc 0:2 8200 /boot/image.fit
bootm 8200
```

This is very much not stdboot :( This doc has some good and current info on
building
a secure FIT image, but much of it is showing its age. Stdboot is still missing

* ability to limit boot mode search to only one image (FIT)

What does this mean? Can you please be more specific or give an example?

Sure, for instance with secure boot we only want to search for FIT images
and if for each media this fails we do not want to fall back to other
image types or boot modes (like UART boot or net boot which would bypass
the signature checks).

We could have something like:

bootstd {
image-types = "fit", "uimage";
}

to limit the supported types.

Something similar is needed for searching for EFI compatible boot across
each enabled boot media first, before trying other methods on each media.
Basically breadth-first search on each media type not depth-first.

How about:

bootstd {
scan-order = "bootmeth,bootdev"; // instead of default "bootdev,bootmeth";
};

This along with the image-types above seem reasonable. Might also help with
our EFI search order issue (we need to search all boot media for EFI parts
first before trying all the other types of boot on each media, basically
breadth-first search vs depth for EFI). We should be able to describe that
pattern here if we think this through.

* fetching and applying FIT overlay/config strings

Re overlays, is this the 'extension' command? What are config strings?

When we have DT overlays in our FIT image, we build a string to pass to
bootm to apply all the selected overlays[0]. If there is now another
mechanism for this please let me know (building this string today is messy).

https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/ti_common.env?ref_type=heads#L18

My proposal for this is to implement extensions in FIT. This would
have a new extensions nodes, so you can specify what extensions are
available for each FIT configuration.

configurations {
conf-1 {
compatible = ...
extensions = "ext1",

Re: [PATCH 0/9] dts: Move to SoC-specific build rules

On Tue, Jan 02, 2024 at 07:06:36AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, Dec 31, 2023 at 7:01 AM Tom Rini  wrote:
> >
> > On Sun, Dec 31, 2023 at 05:45:00AM -0700, Simon Glass wrote:
> > > -Scott as it is bouncing
> > >
> > > Hi,
> > >
> > > On Fri, Dec 29, 2023 at 9:46 AM Peter Robinson  
> > > wrote:
> > > >
> > > > On Fri, Dec 29, 2023 at 12:23 AM Tom Rini  wrote:
> > > > >
> > > > > On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini  wrote:
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > U-Boot builds devicetree binaries from its source tree. 
> > > > > > > > > > > > As part of the
> > > > > > > > > > > > Kconfig conversion, the Makefiles were updated to align 
> > > > > > > > > > > > with how this
> > > > > > > > > > > > is done in Linux: a single target for each SoC is used 
> > > > > > > > > > > > to build all the
> > > > > > > > > > > > .dtb files for that SoC.
> > > > > > > > > > > >
> > > > > > > > > > > > Since then, the Makefiles have devolved in some cases, 
> > > > > > > > > > > > resulting in
> > > > > > > > > > > > lots of target-specific build rules. Also Linux has 
> > > > > > > > > > > > moved to using
> > > > > > > > > > > > subdirectories for each vendor.
> > > > > > > > > > > >
> > > > > > > > > > > > Recent work aims to allow U-Boot to directly use 
> > > > > > > > > > > > devicetree files from
> > > > > > > > > > > > Linux. This would be easier if the directory structure 
> > > > > > > > > > > > were the same.
> > > > > > > > > > > > Another recent discussion involved dropping the build 
> > > > > > > > > > > > rules altogether.
> > > > > > > > > > > >
> > > > > > > > > > > > This series makes a start at cleaning up some of the 
> > > > > > > > > > > > build rules, to
> > > > > > > > > > > > reduce the amount of code and make it easier to add new 
> > > > > > > > > > > > boards for the
> > > > > > > > > > > > same SoC.
> > > > > > > > > > > >
> > > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options between 
> > > > > > > > > > > > U-Boot and Linux
> > > > > > > > > > > > are not always the same. Given the large number of SoCs 
> > > > > > > > > > > > and boards
> > > > > > > > > > > > supported by U-Boot, it would be useful to align these 
> > > > > > > > > > > > where possible.
> > > > > > > > > > >
> > > > > > > > > > > I don't know why we should start with this now, and 
> > > > > > > > > > > further not being on
> > > > > > > > > > > top of Sumit's series to remove our duplicate dts files. 
> > > > > > > > > > > And that's
> > > > > > > > > > > where we can have the conversation about for which cases 
> > > > > > > > > > > it even makes
> > > > > > > > > > > sense to build all of the dts files for a given SoC.
> > > > > > > > > >
> > > > > > > > > > This is a completely different series - there are no 
> > > > > > > > > > conflicts with
> > > > > > > > > > Sumit's series so it can be applied before or after it.
> > > > > > > > > >
> > > > > > > > > > My goal here is to clean up our build rules, rather than 
> > > > > > > > > > just throwing
> > > > > > > > > > them all away, for reasons we have discussed previously. I 
> > > > > > > > > > filed [1]
> > > > > > > > > > to track that.
> > > > > > > > >
> > > > > > > > > Yes, I'm saying we shouldn't be doing anything this series 
> > > > > > > > > does until
> > > > > > > > > after Sumit's series has landed. Along with the fact that I 
> > > > > > > > > don't like
> > > > > > > > > what's going on in this series.
> > > > > > > >
> > > > > > > > This seems to again be the disagreement over whether a single DT
> > > > > > > > should be build for each board, or all the DTs for an SoC?
> > > > > > >
> > > > > > > It's about the disagreement on what we should be building, and 
> > > > > > > what that
> > > > > > > infrastructure looks like. I do not like adding extra rules for
> > > > > > > "clarity" because they don't make things clearer, they lead to the
> > > > > > > unclear mess we have today getting worse. Most instructions are 
> > > > > > > _not_
> > > > > > > "now take this dtb and this binary and .." but just "take this 
> > > > > > > binary",
> > > > > > > because we already have the rules and logic to ensure we build the
> > > > > > > required dtbs. I also don't like the parts of this series that 
> > > > > > > amount
> > > > > > > to deck

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

2024-01-02 Thread Chen-Yu Tsai

On Fri, Dec 29, 2023 at 2:39 PM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  wrote:
> >
> > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > >  wrote:
> > > > >
> > > > > Hi Laurent,
> > > > >
> > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > >  wrote:
> > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > >  wrote:
> > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > wrote:
> > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > single file
> > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > files.
> > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > of size and
> > > > > > > > > > > performance.
> > > > > > > > > > >
> > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > approach.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be used by bootloaders which support it, such 
> > > > > > > > > > > as U-Boot
> > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > correct
> > > > > > > > > > > devicetree, matching the compatible string of the running 
> > > > > > > > > > > board with
> > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > need for
> > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > >
> > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > Use
> > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > >
> > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > used. Supported
> > > > > > > > > > > compression options are the same as the Image.xxx files. 
> > > > > > > > > > > For now there
> > > > > > > > > > > is no way to change the compression other than by editing 
> > > > > > > > > > > the rule for
> > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > >
> > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made 
> > > > > > > > > > > to support
> > > > > > > > > > > this here, since it must be built separately from the 
> > > > > > > > > > > Linux build.
> > > > > > > > > >
> > > > > > > > > > FIT images are very useful, so I think this is a very 
> > > > > > > > > > welcome addition
> > > > > > > > > > to the kernel build system. It can get tricky though: given 
> > > > > > > > > > the
> > > > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > > > one-size-fits-them-all solution to build them, and striking 
> > > > > > > > > > the right
> > > > > > > > > > balance between what makes sense for the kernel and the 
> > > > > > > > > > features that
> > > > > > > > > > users may request will probably lead to bikeshedding. As we 
> > > > > > > > > > all love
> > > > > > > > > > bikeshedding, I thought I would start selfishly, with a 
> > > > > > > > > > personal use
> > > > > > > > > > case :-) This isn't a yak-shaving request though, I don't 
> > > > > > > > > > see any reason
> > > > > > > > > > to delay merging this series.
> > > > > > > > > >
> > > > > > > > > > Have you envisioned building FIT images with a subset of 
> > > > > > > > > > DTBs, or adding
> > > > > > > > > > DTBOs ? Both would be fairly trivial extensions to this 
> > > > > > > > > > script by
> > > > > > > > > > extending the supported command line arguments. It would 
> > > > > > > > > > perhaps be more
> > > > > > > > > > difficult to integrate in the kernel build system though. 
> > > > > > > > > > This leads me
> > > > > > > > > > to a second question: would you consider merging extensions 
> > > > > > > > > > to this
> > > > > > > > > > script if they are not used by the kernel build system, but 
> > > > > > > > > > meant for
> > > > > > > > > > users who manually invoke the script ? More generally, is 
> > > > > > > > > > the script
> > > > > > > > >
> > > > > > > > > We'd also be interested in some customization, though in a 
> > > > > > > > > different way.
> > > > > > > > > We imagine having a rule file that says X compatible string 
> > > > > > > > > should map
> > > > > > > > > to A base DTB, plus B and C DTBO for the configuration 
> > > > > > > > >

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

Hi Tom,

On Mon, Jan 1, 2024 at 4:35 PM Tom Rini  wrote:
>
> On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > Hi Mark, Tom,
> >
> > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis  
> > wrote:
> > >
> > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > From: Tom Rini 
> > > >
> > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > Hi Sumit,
> > > > >
> > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote:
> > > > > > > > > Hi Tom, Sumit,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote:
> > > > > > > > > > > Hi Sumit,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Allow platform owners to mirror devicetree files from 
> > > > > > > > > > > > devitree-rebasing
> > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in 
> > > > > > > > > > > > arch/$(ARCH)/dts
> > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > >
> > > > > > > > > > > > This will help easy migration for platforms which 
> > > > > > > > > > > > currently are compliant
> > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > > > ---
> > > > > > > > > > > >
> > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > --
> > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > >
> > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > --
> > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > >
> > > > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > >   enables a live tree which is available after 
> > > > > > > > > > > > relocation,
> > > > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > > > >
> > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > +   bool "Enable use of devicetree imported from 
> > > > > > > > > > > > Linux kernel release"
> > > > > > > > > > > > +   help
> > > > > > > > > > > > + Traditionally, U-Boot platforms used to have 
> > > > > > > > > > > > their custom devicetree
> > > > > > > > > > > > + files or copy devicetree files from Linux 
> > > > > > > > > > > > kernel which are hard to
> > > > > > > > > > > > + maintain and can usually get out-of-sync from 
> > > > > > > > > > > > Linux kernel. This
> > > > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > > > + a regular sync will be maintained every major 
> > > > > > > > > > > > Linux kernel release
> > > > > > > > > > > > + cycle. However, platforms can still have some 
> > > > > > > > > > > > custom u-boot specific
> > > > > > > > > > > > + bits maintained as part of *-u-boot.dtsi 
> > > > > > > > > > > > files.
> > > > > > > > > > >
> > > > > > > > > > > My only other suggestion here is to mention that this 
> > > > > > > > > > > should be set in
> > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means 
> > > > > > > > > > > that it
> > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > >
> > > > > > > > > > >   bool  # Enable use of devicetree imported from 
> > > > > > > > > > > Linux kernel release
> > > > > > > > > >
> > > > > > > > > > I think we can just keep prompting for it now, to make the 
> > > > > > > > > > transition
> > > > > > > > > > easier, before this option just goes away in time, 
> > > > > > > > > > hopefully.
> > > > > > > > > >
> > > > > > > > > > > Also, this doesn't seem to work for me. Before this 
> > > > > >

Re: [PATCH 0/9] dts: Move to SoC-specific build rules

Hi Tom,

On Sun, Dec 31, 2023 at 7:01 AM Tom Rini  wrote:
>
> On Sun, Dec 31, 2023 at 05:45:00AM -0700, Simon Glass wrote:
> > -Scott as it is bouncing
> >
> > Hi,
> >
> > On Fri, Dec 29, 2023 at 9:46 AM Peter Robinson  wrote:
> > >
> > > On Fri, Dec 29, 2023 at 12:23 AM Tom Rini  wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass wrote:
> > > > > > > > > >
> > > > > > > > > > > U-Boot builds devicetree binaries from its source tree. 
> > > > > > > > > > > As part of the
> > > > > > > > > > > Kconfig conversion, the Makefiles were updated to align 
> > > > > > > > > > > with how this
> > > > > > > > > > > is done in Linux: a single target for each SoC is used to 
> > > > > > > > > > > build all the
> > > > > > > > > > > .dtb files for that SoC.
> > > > > > > > > > >
> > > > > > > > > > > Since then, the Makefiles have devolved in some cases, 
> > > > > > > > > > > resulting in
> > > > > > > > > > > lots of target-specific build rules. Also Linux has moved 
> > > > > > > > > > > to using
> > > > > > > > > > > subdirectories for each vendor.
> > > > > > > > > > >
> > > > > > > > > > > Recent work aims to allow U-Boot to directly use 
> > > > > > > > > > > devicetree files from
> > > > > > > > > > > Linux. This would be easier if the directory structure 
> > > > > > > > > > > were the same.
> > > > > > > > > > > Another recent discussion involved dropping the build 
> > > > > > > > > > > rules altogether.
> > > > > > > > > > >
> > > > > > > > > > > This series makes a start at cleaning up some of the 
> > > > > > > > > > > build rules, to
> > > > > > > > > > > reduce the amount of code and make it easier to add new 
> > > > > > > > > > > boards for the
> > > > > > > > > > > same SoC.
> > > > > > > > > > >
> > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options between 
> > > > > > > > > > > U-Boot and Linux
> > > > > > > > > > > are not always the same. Given the large number of SoCs 
> > > > > > > > > > > and boards
> > > > > > > > > > > supported by U-Boot, it would be useful to align these 
> > > > > > > > > > > where possible.
> > > > > > > > > >
> > > > > > > > > > I don't know why we should start with this now, and further 
> > > > > > > > > > not being on
> > > > > > > > > > top of Sumit's series to remove our duplicate dts files. 
> > > > > > > > > > And that's
> > > > > > > > > > where we can have the conversation about for which cases it 
> > > > > > > > > > even makes
> > > > > > > > > > sense to build all of the dts files for a given SoC.
> > > > > > > > >
> > > > > > > > > This is a completely different series - there are no 
> > > > > > > > > conflicts with
> > > > > > > > > Sumit's series so it can be applied before or after it.
> > > > > > > > >
> > > > > > > > > My goal here is to clean up our build rules, rather than just 
> > > > > > > > > throwing
> > > > > > > > > them all away, for reasons we have discussed previously. I 
> > > > > > > > > filed [1]
> > > > > > > > > to track that.
> > > > > > > >
> > > > > > > > Yes, I'm saying we shouldn't be doing anything this series does 
> > > > > > > > until
> > > > > > > > after Sumit's series has landed. Along with the fact that I 
> > > > > > > > don't like
> > > > > > > > what's going on in this series.
> > > > > > >
> > > > > > > This seems to again be the disagreement over whether a single DT
> > > > > > > should be build for each board, or all the DTs for an SoC?
> > > > > >
> > > > > > It's about the disagreement on what we should be building, and what 
> > > > > > that
> > > > > > infrastructure looks like. I do not like adding extra rules for
> > > > > > "clarity" because they don't make things clearer, they lead to the
> > > > > > unclear mess we have today getting worse. Most instructions are 
> > > > > > _not_
> > > > > > "now take this dtb and this binary and .." but just "take this 
> > > > > > binary",
> > > > > > because we already have the rules and logic to ensure we build the
> > > > > > required dtbs. I also don't like the parts of this series that 
> > > > > > amount
> > > > > > to deck shuffling when we should just be taking the chairs away. 
> > > > > > There's
> > > > > > just not nor will there be a case for omap3/4/5 platforms of 
> > > > > > "change the
> > > > > > dtb", so building more is pointless. For other SoCs, there may be 
> > > > > > some
> > > > > > cases of "this could

Re: [PATCH v2 2/2] efi_loader: provide tool to dump SMBIOS table

Hi Heinrich,

On Mon, Jan 1, 2024 at 4:23 PM Heinrich Schuchardt
 wrote:
>
> On 1/1/24 23:41, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, Jan 1, 2024 at 11:50 AM Heinrich Schuchardt
> >  wrote:
> >>
> >> An EFI binary dmidump.efi is provided that can be used to check the SMBIOS
> >> table for consistency and to dump it as a file.
> >>
> >> The tool provides the following commands:
> >>
> >> check
> >>  Check the SMBIOS table for consistency.
> >>
> >> exit
> >>  Leave the tool.
> >>
> >> help
> >>  Show available commands.
> >>
> >> save
> >>  Save the SMBIOS table to a file on the EFI system partition. The file
> >>  can be further analyzed with the dmidecode command line tool::
> >>
> >>  dmidecode --from-dump 
> >>
> >> Specifying 'nocolor' as load option data suppresses colored output and
> >> clearing of the screen.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >> v2:
> >>  fix an incorrect variable usage when checking the result of memcmp
> >> ---
> >>   lib/efi_loader/Makefile  |   7 +
> >>   lib/efi_loader/dmidump.c | 595 +++
> >>   2 files changed, 602 insertions(+)
> >>   create mode 100644 lib/efi_loader/dmidump.c
> >
> > Does this tool need tests?
>
> Once we have all the SMBIOS stuff in, we could use the tool in a test to
> verify that the SMBIOS tables are correctly installed.

Yes that is useful for the EFI side of things, along with your new
test for smbios within U-Boot.

>
> >
> > Can you please split up do_save() a bit and also move the command loop
> > into its own function? Otherwise it looks good to me.
> >
> >>
> >> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> >> index 24d33d5409..71880d330e 100644
> >> --- a/lib/efi_loader/Makefile
> >> +++ b/lib/efi_loader/Makefile
> >> @@ -16,6 +16,8 @@ CFLAGS_boothart.o := $(CFLAGS_EFI) -Os -ffreestanding
> >>   CFLAGS_REMOVE_boothart.o := $(CFLAGS_NON_EFI)
> >>   CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
> >>   CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
> >> +CFLAGS_dmidump.o := $(CFLAGS_EFI) -Os -ffreestanding
> >> +CFLAGS_REMOVE_dmidump.o := $(CFLAGS_NON_EFI)
> >>   CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
> >>   CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
> >>   CFLAGS_initrddump.o := $(CFLAGS_EFI) -Os -ffreestanding
> >
> > Is there a way to have a list of these tools such that the flags stuff
> > is done automatically and doesn't need to be repeated each time?
>
> Looking at
>
> scripts/Makefile.lib:102:
> _c_flags = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags))
>
> this is not possible.

Not with that rule, but perhaps another could be added. Anyway, I
suppose we can put up with it for now.

>
> >
> >> @@ -31,6 +33,11 @@ always += helloworld.efi
> >>   targets += helloworld.o
> >>   endif
> >>
> >> +ifneq ($(CONFIG_GENERATE_SMBIOS_TABLE),)
> >> +always += dmidump.efi
> >> +targets += dmidump.o
> >
> > How about smbios_tool ? I think 'dmi' is a bit of an obfuscation.
>
> We can call it smbiosdump.efi.

Yes that is better.


>
> Thanks for reviewing.
>
> Best regards
>
> Heinrich
>
> >
> >> +endif
> >> +
> >>   ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
> >>   always += dtbdump.efi
> >>   targets += dtbdump.o
> >
> > [..]

Regards,
Simon

Re: Setting up boot chain ACPI on ARM with STM32MPU

Hi Ba,

On Mon, Dec 4, 2023 at 2:47 AM Ba Gia Bao Phan
 wrote:
>>
>> Sort-of...the refactoring to allow ACPI tables on ARM is completed,
>> but I don't think any U-Boot board uses this.
>
> Hello, could you tell me more details about this topic? Which platform ARM 
> are ACPI tables enabled for?

There are some patches to enable it for qemu on ARM here:

http://patchwork.ozlabs.org/project/uboot/list/?series=388154

Regards,
Simon


>
> Le mer. 29 nov. 2023 à 20:28, Simon Glass  a écrit :
>>
>> +Heinrich Schuchardt
>>
>> Hi,
>>
>> On Wed, 29 Nov 2023 at 08:29, Ba Gia Bao Phan
>>  wrote:
>> >
>> > Hello everyone,
>> >
>> > I am a trainee at STMicroelectronics France. I am working on a project 
>> > "Setting up a boot chain ACPI" for STM32MPU, which is based on ARM 
>> > Cortex-A . The objective of my project is to add a way of booting (with 
>> > ACPI) besides Device Tree available on STM32MPU.
>> >
>> > I found that ACPI was enabled on some x86 platforms but I don't know 
>> > whether it was set up on ARM or not. I found a PATCH that discussed 
>> > Enabling ACPI booting on ARM with Raspberry Pi 4 but I don't know if it 
>> > functioned or not. Did anyone here succeed in setting up ACPI on ARM by 
>> > U-boot?
>>
>> Sort-of...the refactoring to allow ACPI tables on ARM is completed,
>> but I don't think any U-Boot board uses this.
>>
>> >
>> > What are the differences between x86 and ARM platforms when enabling ACPI? 
>> > The architecture of my board STM32PMU is ARM so can I apply the technique 
>> > used on platform x86 for my board?
>>
>> Firstly I wonder why you want ACPI?
>>
>> Secondly, if you have the tables somewhere it should be easy enough to
>> build them, building on the series you pointed to. Heinrich is
>> interested in this, I think. I can help with advice. I have been
>> toying with going back to that rpi series but have not done so yet.
>>
>> Regards,
>> Simon
>
>
>
> --
> PHAN Ba Gia Bao
> Etudiant en 5A STI - INSA Centre Val de Loire

Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

Hi Caleb,

On Tue, Jan 2, 2024 at 5:51 AM Caleb Connolly  wrote:
>
> [snip]
> >>>
> > However, I am very much in favour of having a generalized U-Boot
> > image. This might become true in some cases like U-Boot acts as a
> > second stage bootloader for a particular SoC which is a unified image
> > where the prior stage passes the DT to it. The Qcom effort in this
> > direction can be an example here.
> 
>  Not relevant to the topic at hand, perhaps, but Qualcomm uses a
>  closed-source blob to jump to U-Boot and is certainly not an example
>  we should emulate. But yes, passing a DT to U-Boot proper can be
>  useful.
>
> Just to chime in here, this limitation is true for production Qualcomm
> devices where all of the bootloader blobs are signed by the OEM (true
> for most phones). But for development platforms we can do better. I
> expect this is a topic we will keep on coming back to, so I'd like to
> just take the time to explain some of the technical details on Qualcomm
> platforms, as there is a lot more nuance than you might be aware of.
>
> The modern Qualcomm boot chain is (roughly) PBL (bootrom) -> TZ/el3 ->
> sbl1 (secondary bootloader) -> hypervisor -> XBL_Core (UEFI impl) -> ABL
> (LinuxLoader.efi app) -> Linux
>
> On production devices the best we can do is replace "Linux" with U-Boot,
> and if we're lucky then we can leverage features of ABL to simplify
> things like DTB selection (it supports picking from a bunch of
> concatenated DTBs, but we can just as easily implement some similar
> feature in U-Boot ourselves).
>
> On a development board I have been successful in replacing the
> hypervisor with a stub and replacing XBL_Core with U-Boot - giving us
> EL2 and removing the entire proprietary UEFI stack. There is no reason
> that we can't go further than this.
>
> The Qualcomm Chromebooks all run Coreboot, for sure on those it would be
> possible to use U-Boot much earlier (although there is still the
> proprietary XBL_Sec TZ blob).
>
> The Dragonboard410c (and MSM8916 SoC overall) has been pretty much
> entirely ripped open thanks to Stephan Gerhold and the msm8916-mainline
> project. On these devices it is easily possible to run U-Boot as a
> first-stage bootloader (at least to the same extent one can on the more
> open ARM platforms, or even more open if you wish). Although the
> bootloader of choice for most of these devices is a home-grown fork of lk.
>
> For new SoCs, with the number of Qualcomm devices out there, and
> communities like postmarketOS enabling support on so many of them... My
> hope is that we will quickly see phones being the most common Qualcomm
> devices supported by U-Boot. While it is indeed extremely unfortunate
> that we can't replace the bootloader entirely, using U-Boot as a fresh
> slate is still extremely liberating (EFI! Firmware updates! No need for
> distro hacks to update the kernel! Multi-boot! etc...). I wish we could
> focus more on how U-Boot will make supporting Linux on these devices SO
> SO much easier, and less on how broken the (usually impossible to
> modify) bootloader they shipped with is.
>
> While almost all of the boot chain I explained above is proprietary, the
> ABL source code is publicly available (although most device vendors
> don't publish their modified production version, I suppose for fear of
> embarrassment). The statement "Qualcomm uses a closed-source blob to
> jump to U-Boot" is at the very least an oversimplification.
>
> To be contrarian, here is an example of a phone vendor who do publish
> their ABL source code, here is the code that runs Linux (or U-Boot in
> our case).
>
> https://github.com/SHIFTPHONES/android_bootable_bootloader_edk2/blob/sos-3.x/QcomModulePkg/Library/BootLib/BootLinux.c#L1039
>
> My point is, there is a lot of nuance and complexity here, and we need
> to be careful about what exactly we're referring to.

Thank you very much for the information, it is a great read. Yes my
comment was wide of the mark and I am pleased to hear it.

BTW, I would very much like to see Linaro ensuring that new 96boards
have open source firmware before they are released. Before release
seems to be the only time that the vendor can devote time to it.

Regards,
Simon

Re: [PATCH v6 4/6] common: console: record console from the beginning

Hi Mattijs,

On Tue, Jan 2, 2024 at 2:52 AM Mattijs Korpershoek
 wrote:
>
> Hi Simon, Svyatoslav,
>
> On Thu, Dec 28, 2023 at 21:52, Svyatoslav Ryhel  wrote:
>
> > чт, 28 груд. 2023 р. о 21:48 Simon Glass  пише:
> >>
> >> On Thu, Dec 28, 2023 at 6:02 PM Svyatoslav Ryhel  
> >> wrote:
> >> >
> >> > From: Ion Agorria 
> >> >
> >> > Set flag to enable console record on console_record_init
> >> > and not only on console_record_reset_enable. This fixes
> >> > missing start of U-Boot log for fastboot oem console
> >> > command.
> >> >
> >> > Signed-off-by: Ion Agorria 
> >> > Signed-off-by: Svyatoslav Ryhel 
> >> > Reviewed-by: Mattijs Korpershoek 
> >> > ---
> >> >  common/console.c | 3 +++
> >> >  1 file changed, 3 insertions(+)
> >>
> >> Reviewed-by: Simon Glass 
> >>
> >> OK, I can see the use of this...but I wonder if we can now get rid of
> >> the same line of code from console_record_reset_enable() ?
> >>
> >
> > Interesting question but let's leave it to a dedicated patch :)
>
> I've looked a little more into to this, and I'm not so sure we can get
> rid of the gd->flags |= GD_FLG_RECORD; in console_record_reset_enable().
>
> Removing the flag seems to break quite some tests in
> test/py/tests/test_ut.py.
>
> The breakage can be explained that various unit tests clear the
> GD_FLG_RECORD with:
>
> gd->flags &= ~GD_FLG_RECORD;
>
> Therefore, I would suggest we keep the flag in
> console_record_reset_enable().

>From my look all of those are not needed in tests, i.e. are bugs. If
you are able to do a patch to remove those lines, it would avoid the
confusion.

Also, by setting UT_TESTF_CONSOLE_REC for a test, console recording is
set up automatically, so the console_record_reset_enable() is not
needed at the start of the test.

Regards,
Simon

Re: [PATCH v3] test/py: i2c: Add tests for i2c command