[PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Andre Przywara]

So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
setup in board.c. That combination of &&, || and negations is very hard
to read, maintain and especially to extend.

Fortunately we have those same conditions already modelled in the
Kconfig file, so they are actually redundant. On top of that the real
reason we have those preprocessor guards in the first place is about the
symbols that are *conditionally* defined: without #ifdefs the build
would break because of them being undefined for many boards.

To simplify this, just change the guards to actually look at the symbols
needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
This drastically improves the readability of this code, and makes adding
PMIC support a pure Kconfig matter.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 board/sunxi/board.c   | 32 ++++++++++++++------------------
 drivers/power/Kconfig |  2 +-
 2 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index ebaa9431984..65d79a02c25 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -597,50 +597,46 @@ void sunxi_board_init(void)
 		}
 	}
 
-#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
-	defined CONFIG_AXP818_POWER
+#ifdef CONFIG_AXP_DCDC1_VOLT
 	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
+	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
 #endif
-#if !defined(CONFIG_AXP305_POWER)
+#ifdef CONFIG_AXP_DCDC2_VOLT
 	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
 	power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
 #endif
-#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
+#ifdef CONFIG_AXP_DCDC4_VOLT
 	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
 #endif
-#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
-	defined CONFIG_AXP818_POWER
-	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
-#endif
 
-#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
-	defined CONFIG_AXP818_POWER
+#ifdef CONFIG_AXP_ALDO1_VOLT
 	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
 #endif
-#if !defined(CONFIG_AXP305_POWER)
+#ifdef CONFIG_AXP_ALDO2_VOLT
 	power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
 #endif
-#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
+#ifdef CONFIG_AXP_ALDO3_VOLT
 	power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
 #endif
-#ifdef CONFIG_AXP209_POWER
+#ifdef CONFIG_AXP_ALDO4_VOLT
 	power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
 #endif
 
-#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
-	defined(CONFIG_AXP818_POWER)
+#ifdef CONFIG_AXP_DLDO1_VOLT
 	power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
 	power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
-#if !defined CONFIG_AXP809_POWER
+#endif
+#ifdef CONFIG_AXP_DLDO3_VOLT
 	power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
 	power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
 #endif
+#ifdef CONFIG_AXP_ELDO1_VOLT
 	power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
 	power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
 	power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
 #endif
 
-#ifdef CONFIG_AXP818_POWER
+#ifdef CONFIG_AXP_FLDO1_VOLT
 	power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
 	power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
 	power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
@@ -649,7 +645,7 @@ void sunxi_board_init(void)
 #if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
 	power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
 #endif
-#endif
+#endif	/* CONFIG_AXPxxx_POWER */
 	printf("DRAM:");
 	gd->ram_size = sunxi_dram_init();
 	printf(" %d MiB\n", (int)(gd->ram_size >> 20));
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 7f3b990d231..83cb31c937a 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
 
 config AXP_DCDC4_VOLT
 	int "axp pmic dcdc4 voltage"
-	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || AXP818_POWER || AXP305_POWER
+	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || AXP305_POWER
 	default 1250 if AXP152_POWER
 	default 1200 if MACH_SUN6I
 	default 0 if MACH_SUN8I
-- 
2.25.1

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Jernej Škrabec]

On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote:
> So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
> setup in board.c. That combination of &&, || and negations is very hard
> to read, maintain and especially to extend.
> 
> Fortunately we have those same conditions already modelled in the
> Kconfig file, so they are actually redundant. On top of that the real
> reason we have those preprocessor guards in the first place is about the
> symbols that are *conditionally* defined: without #ifdefs the build
> would break because of them being undefined for many boards.
> 
> To simplify this, just change the guards to actually look at the symbols
> needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
> This drastically improves the readability of this code, and makes adding
> PMIC support a pure Kconfig matter.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  board/sunxi/board.c   | 32 ++++++++++++++------------------
>  drivers/power/Kconfig |  2 +-
>  2 files changed, 15 insertions(+), 19 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ebaa9431984..65d79a02c25 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -597,50 +597,46 @@ void sunxi_board_init(void)
>  		}
>  	}
> 
> -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> -	defined CONFIG_AXP818_POWER
> +#ifdef CONFIG_AXP_DCDC1_VOLT
>  	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
> +	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
>  #endif
> -#if !defined(CONFIG_AXP305_POWER)
> +#ifdef CONFIG_AXP_DCDC2_VOLT
>  	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
>  	power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
>  #endif
> -#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
> +#ifdef CONFIG_AXP_DCDC4_VOLT
>  	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
>  #endif
> -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> -	defined CONFIG_AXP818_POWER
> -	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> -#endif
> 
> -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> -	defined CONFIG_AXP818_POWER
> +#ifdef CONFIG_AXP_ALDO1_VOLT
>  	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
>  #endif
> -#if !defined(CONFIG_AXP305_POWER)
> +#ifdef CONFIG_AXP_ALDO2_VOLT
>  	power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
>  #endif
> -#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
> +#ifdef CONFIG_AXP_ALDO3_VOLT
>  	power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
>  #endif
> -#ifdef CONFIG_AXP209_POWER
> +#ifdef CONFIG_AXP_ALDO4_VOLT
>  	power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
>  #endif
> 
> -#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
> -	defined(CONFIG_AXP818_POWER)
> +#ifdef CONFIG_AXP_DLDO1_VOLT
>  	power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
>  	power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
> -#if !defined CONFIG_AXP809_POWER
> +#endif
> +#ifdef CONFIG_AXP_DLDO3_VOLT
>  	power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
>  	power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
>  #endif
> +#ifdef CONFIG_AXP_ELDO1_VOLT
>  	power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
>  	power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
>  	power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
>  #endif
> 
> -#ifdef CONFIG_AXP818_POWER
> +#ifdef CONFIG_AXP_FLDO1_VOLT
>  	power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
>  	power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
>  	power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
> @@ -649,7 +645,7 @@ void sunxi_board_init(void)
>  #if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
>  	power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
>  #endif
> -#endif
> +#endif	/* CONFIG_AXPxxx_POWER */
>  	printf("DRAM:");
>  	gd->ram_size = sunxi_dram_init();
>  	printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 7f3b990d231..83cb31c937a 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
> 
>  config AXP_DCDC4_VOLT
>  	int "axp pmic dcdc4 voltage"
> -	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || 
AXP818_POWER ||
> AXP305_POWER +	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER 
||
> AXP305_POWER default 1250 if AXP152_POWER
>  	default 1200 if MACH_SUN6I
>  	default 0 if MACH_SUN8I

This patch is great, but this last change doesn't seem to be directly 
connected?

Best regards,
Jernej

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Andre Przywara]

On Sat, 21 Oct 2023 08:34:06 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:

> On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote:
> > So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
> > setup in board.c. That combination of &&, || and negations is very hard
> > to read, maintain and especially to extend.
> > 
> > Fortunately we have those same conditions already modelled in the
> > Kconfig file, so they are actually redundant. On top of that the real
> > reason we have those preprocessor guards in the first place is about the
> > symbols that are *conditionally* defined: without #ifdefs the build
> > would break because of them being undefined for many boards.
> > 
> > To simplify this, just change the guards to actually look at the symbols
> > needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
> > This drastically improves the readability of this code, and makes adding
> > PMIC support a pure Kconfig matter.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  board/sunxi/board.c   | 32 ++++++++++++++------------------
> >  drivers/power/Kconfig |  2 +-
> >  2 files changed, 15 insertions(+), 19 deletions(-)
> > 
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index ebaa9431984..65d79a02c25 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -597,50 +597,46 @@ void sunxi_board_init(void)
> >  		}
> >  	}
> > 
> > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > -	defined CONFIG_AXP818_POWER
> > +#ifdef CONFIG_AXP_DCDC1_VOLT
> >  	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
> > +	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> >  #endif
> > -#if !defined(CONFIG_AXP305_POWER)
> > +#ifdef CONFIG_AXP_DCDC2_VOLT
> >  	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
> >  	power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
> >  #endif
> > -#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
> > +#ifdef CONFIG_AXP_DCDC4_VOLT
> >  	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
> >  #endif
> > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > -	defined CONFIG_AXP818_POWER
> > -	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> > -#endif
> > 
> > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > -	defined CONFIG_AXP818_POWER
> > +#ifdef CONFIG_AXP_ALDO1_VOLT
> >  	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
> >  #endif
> > -#if !defined(CONFIG_AXP305_POWER)
> > +#ifdef CONFIG_AXP_ALDO2_VOLT
> >  	power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
> >  #endif
> > -#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
> > +#ifdef CONFIG_AXP_ALDO3_VOLT
> >  	power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
> >  #endif
> > -#ifdef CONFIG_AXP209_POWER
> > +#ifdef CONFIG_AXP_ALDO4_VOLT
> >  	power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
> >  #endif
> > 
> > -#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
> > -	defined(CONFIG_AXP818_POWER)
> > +#ifdef CONFIG_AXP_DLDO1_VOLT
> >  	power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
> >  	power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
> > -#if !defined CONFIG_AXP809_POWER
> > +#endif
> > +#ifdef CONFIG_AXP_DLDO3_VOLT
> >  	power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
> >  	power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
> >  #endif
> > +#ifdef CONFIG_AXP_ELDO1_VOLT
> >  	power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
> >  	power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
> >  	power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
> >  #endif
> > 
> > -#ifdef CONFIG_AXP818_POWER
> > +#ifdef CONFIG_AXP_FLDO1_VOLT
> >  	power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
> >  	power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
> >  	power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
> > @@ -649,7 +645,7 @@ void sunxi_board_init(void)
> >  #if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
> >  	power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
> >  #endif
> > -#endif
> > +#endif	/* CONFIG_AXPxxx_POWER */
> >  	printf("DRAM:");
> >  	gd->ram_size = sunxi_dram_init();
> >  	printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> > index 7f3b990d231..83cb31c937a 100644
> > --- a/drivers/power/Kconfig
> > +++ b/drivers/power/Kconfig
> > @@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
> > 
> >  config AXP_DCDC4_VOLT
> >  	int "axp pmic dcdc4 voltage"
> > -	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER ||   
> AXP818_POWER ||
> > AXP305_POWER +	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER   
> ||
> > AXP305_POWER default 1250 if AXP152_POWER
> >  	default 1200 if MACH_SUN6I
> >  	default 0 if MACH_SUN8I  
> 
> This patch is great, but this last change doesn't seem to be directly 
> connected?

It is an existing bug: there is no axp_set_dcdc4() for the AXP818, but
since the AXP818 is not included in the guards at the calling site
in board.c above, we didn't notice.
So without this change, all A83T boards (the only ones using AXP818)
would fail compilation.
I just forgot to mention it in the commit message, will add it.

Cheers,
Andre

RE: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Jaehoon Chung]

Hi,

> -----Original Message-----
> From: Andre Przywara <andre.przywara@arm.com>
> Sent: Sunday, October 22, 2023 6:19 AM
> To: Jernej Škrabec <jernej.skrabec@gmail.com>
> Cc: Jagan Teki <jagan@amarulasolutions.com>; Jaehoon Chung <jh80.chung@samsung.com>; Samuel Holland
> <samuel@sholland.org>; SASANO Takayoshi <uaa@mx5.nisiq.net>; Mikhail Kalashnikov <iuncuim@gmail.com>;
> Piotr Oniszczuk <piotr.oniszczuk@gmail.com>; u-boot@lists.denx.de; linux-sunxi@lists.linux.dev
> Subject: Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions
> 
> On Sat, 21 Oct 2023 08:34:06 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> 
> > On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote:
> > > So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
> > > setup in board.c. That combination of &&, || and negations is very hard
> > > to read, maintain and especially to extend.
> > >
> > > Fortunately we have those same conditions already modelled in the
> > > Kconfig file, so they are actually redundant. On top of that the real
> > > reason we have those preprocessor guards in the first place is about the
> > > symbols that are *conditionally* defined: without #ifdefs the build
> > > would break because of them being undefined for many boards.
> > >
> > > To simplify this, just change the guards to actually look at the symbols
> > > needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
> > > This drastically improves the readability of this code, and makes adding
> > > PMIC support a pure Kconfig matter.
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > >  board/sunxi/board.c   | 32 ++++++++++++++------------------
> > >  drivers/power/Kconfig |  2 +-
> > >  2 files changed, 15 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > > index ebaa9431984..65d79a02c25 100644
> > > --- a/board/sunxi/board.c
> > > +++ b/board/sunxi/board.c
> > > @@ -597,50 +597,46 @@ void sunxi_board_init(void)
> > >  		}
> > >  	}
> > >
> > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > > -	defined CONFIG_AXP818_POWER
> > > +#ifdef CONFIG_AXP_DCDC1_VOLT
> > >  	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
> > > +	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> > >  #endif
> > > -#if !defined(CONFIG_AXP305_POWER)
> > > +#ifdef CONFIG_AXP_DCDC2_VOLT
> > >  	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
> > >  	power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
> > >  #endif
> > > -#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
> > > +#ifdef CONFIG_AXP_DCDC4_VOLT
> > >  	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
> > >  #endif
> > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > > -	defined CONFIG_AXP818_POWER
> > > -	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> > > -#endif
> > >
> > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > > -	defined CONFIG_AXP818_POWER
> > > +#ifdef CONFIG_AXP_ALDO1_VOLT
> > >  	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
> > >  #endif
> > > -#if !defined(CONFIG_AXP305_POWER)
> > > +#ifdef CONFIG_AXP_ALDO2_VOLT
> > >  	power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
> > >  #endif
> > > -#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
> > > +#ifdef CONFIG_AXP_ALDO3_VOLT
> > >  	power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
> > >  #endif
> > > -#ifdef CONFIG_AXP209_POWER
> > > +#ifdef CONFIG_AXP_ALDO4_VOLT
> > >  	power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
> > >  #endif
> > >
> > > -#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
> > > -	defined(CONFIG_AXP818_POWER)
> > > +#ifdef CONFIG_AXP_DLDO1_VOLT
> > >  	power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
> > >  	power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
> > > -#if !defined CONFIG_AXP809_POWER
> > > +#endif
> > > +#ifdef CONFIG_AXP_DLDO3_VOLT
> > >  	power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
> > >  	power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
> > >  #endif
> > > +#ifdef CONFIG_AXP_ELDO1_VOLT
> > >  	power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
> > >  	power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
> > >  	power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
> > >  #endif
> > >
> > > -#ifdef CONFIG_AXP818_POWER
> > > +#ifdef CONFIG_AXP_FLDO1_VOLT
> > >  	power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
> > >  	power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
> > >  	power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
> > > @@ -649,7 +645,7 @@ void sunxi_board_init(void)
> > >  #if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
> > >  	power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
> > >  #endif
> > > -#endif
> > > +#endif	/* CONFIG_AXPxxx_POWER */
> > >  	printf("DRAM:");
> > >  	gd->ram_size = sunxi_dram_init();
> > >  	printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> > > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> > > index 7f3b990d231..83cb31c937a 100644
> > > --- a/drivers/power/Kconfig
> > > +++ b/drivers/power/Kconfig
> > > @@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
> > >
> > >  config AXP_DCDC4_VOLT
> > >  	int "axp pmic dcdc4 voltage"
> > > -	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER ||
> > AXP818_POWER ||
> > > AXP305_POWER +	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER
> > ||
> > > AXP305_POWER default 1250 if AXP152_POWER
> > >  	default 1200 if MACH_SUN6I
> > >  	default 0 if MACH_SUN8I
> >
> > This patch is great, but this last change doesn't seem to be directly
> > connected?
> 
> It is an existing bug: there is no axp_set_dcdc4() for the AXP818, but
> since the AXP818 is not included in the guards at the calling site
> in board.c above, we didn't notice.
> So without this change, all A83T boards (the only ones using AXP818)
> would fail compilation.
> I just forgot to mention it in the commit message, will add it.

Will you resend this patch after updating the commit message?

Best Regards,
Jaehoon Chung

> 
> Cheers,
> Andre

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Andre Przywara]

On Tue, 31 Oct 2023 15:42:54 +0900
"Jaehoon Chung" <jh80.chung@samsung.com> wrote:

Hi Jaehoon,

> Hi,
> 
> > -----Original Message-----
> > From: Andre Przywara <andre.przywara@arm.com>
> > Sent: Sunday, October 22, 2023 6:19 AM
> > To: Jernej Škrabec <jernej.skrabec@gmail.com>
> > Cc: Jagan Teki <jagan@amarulasolutions.com>; Jaehoon Chung <jh80.chung@samsung.com>; Samuel Holland
> > <samuel@sholland.org>; SASANO Takayoshi <uaa@mx5.nisiq.net>; Mikhail Kalashnikov <iuncuim@gmail.com>;
> > Piotr Oniszczuk <piotr.oniszczuk@gmail.com>; u-boot@lists.denx.de; linux-sunxi@lists.linux.dev
> > Subject: Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions
> > 
> > On Sat, 21 Oct 2023 08:34:06 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >   
> > > On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote:  
> > > > So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
> > > > setup in board.c. That combination of &&, || and negations is very hard
> > > > to read, maintain and especially to extend.
> > > >
> > > > Fortunately we have those same conditions already modelled in the
> > > > Kconfig file, so they are actually redundant. On top of that the real
> > > > reason we have those preprocessor guards in the first place is about the
> > > > symbols that are *conditionally* defined: without #ifdefs the build
> > > > would break because of them being undefined for many boards.
> > > >
> > > > To simplify this, just change the guards to actually look at the symbols
> > > > needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
> > > > This drastically improves the readability of this code, and makes adding
> > > > PMIC support a pure Kconfig matter.
> > > >
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > ---
> > > >  board/sunxi/board.c   | 32 ++++++++++++++------------------
> > > >  drivers/power/Kconfig |  2 +-
> > > >  2 files changed, 15 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > > > index ebaa9431984..65d79a02c25 100644
> > > > --- a/board/sunxi/board.c
> > > > +++ b/board/sunxi/board.c
> > > > @@ -597,50 +597,46 @@ void sunxi_board_init(void)
> > > >  		}
> > > >  	}
> > > >
> > > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > > > -	defined CONFIG_AXP818_POWER
> > > > +#ifdef CONFIG_AXP_DCDC1_VOLT
> > > >  	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
> > > > +	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> > > >  #endif
> > > > -#if !defined(CONFIG_AXP305_POWER)
> > > > +#ifdef CONFIG_AXP_DCDC2_VOLT
> > > >  	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
> > > >  	power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
> > > >  #endif
> > > > -#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
> > > > +#ifdef CONFIG_AXP_DCDC4_VOLT
> > > >  	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
> > > >  #endif
> > > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > > > -	defined CONFIG_AXP818_POWER
> > > > -	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> > > > -#endif
> > > >
> > > > -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> > > > -	defined CONFIG_AXP818_POWER
> > > > +#ifdef CONFIG_AXP_ALDO1_VOLT
> > > >  	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
> > > >  #endif
> > > > -#if !defined(CONFIG_AXP305_POWER)
> > > > +#ifdef CONFIG_AXP_ALDO2_VOLT
> > > >  	power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
> > > >  #endif
> > > > -#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
> > > > +#ifdef CONFIG_AXP_ALDO3_VOLT
> > > >  	power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
> > > >  #endif
> > > > -#ifdef CONFIG_AXP209_POWER
> > > > +#ifdef CONFIG_AXP_ALDO4_VOLT
> > > >  	power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
> > > >  #endif
> > > >
> > > > -#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
> > > > -	defined(CONFIG_AXP818_POWER)
> > > > +#ifdef CONFIG_AXP_DLDO1_VOLT
> > > >  	power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
> > > >  	power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
> > > > -#if !defined CONFIG_AXP809_POWER
> > > > +#endif
> > > > +#ifdef CONFIG_AXP_DLDO3_VOLT
> > > >  	power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
> > > >  	power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
> > > >  #endif
> > > > +#ifdef CONFIG_AXP_ELDO1_VOLT
> > > >  	power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
> > > >  	power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
> > > >  	power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
> > > >  #endif
> > > >
> > > > -#ifdef CONFIG_AXP818_POWER
> > > > +#ifdef CONFIG_AXP_FLDO1_VOLT
> > > >  	power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
> > > >  	power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
> > > >  	power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
> > > > @@ -649,7 +645,7 @@ void sunxi_board_init(void)
> > > >  #if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
> > > >  	power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
> > > >  #endif
> > > > -#endif
> > > > +#endif	/* CONFIG_AXPxxx_POWER */
> > > >  	printf("DRAM:");
> > > >  	gd->ram_size = sunxi_dram_init();
> > > >  	printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> > > > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> > > > index 7f3b990d231..83cb31c937a 100644
> > > > --- a/drivers/power/Kconfig
> > > > +++ b/drivers/power/Kconfig
> > > > @@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
> > > >
> > > >  config AXP_DCDC4_VOLT
> > > >  	int "axp pmic dcdc4 voltage"
> > > > -	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER ||  
> > > AXP818_POWER ||  
> > > > AXP305_POWER +	depends on AXP152_POWER || AXP221_POWER || AXP809_POWER  
> > > ||  
> > > > AXP305_POWER default 1250 if AXP152_POWER
> > > >  	default 1200 if MACH_SUN6I
> > > >  	default 0 if MACH_SUN8I  
> > >
> > > This patch is great, but this last change doesn't seem to be directly
> > > connected?  
> > 
> > It is an existing bug: there is no axp_set_dcdc4() for the AXP818, but
> > since the AXP818 is not included in the guards at the calling site
> > in board.c above, we didn't notice.
> > So without this change, all A83T boards (the only ones using AXP818)
> > would fail compilation.
> > I just forgot to mention it in the commit message, will add it.  
> 
> Will you resend this patch after updating the commit message?

Well, I was actually thinking of merging it straight away (with the
updated commit message), since I think that plus a tiny typo were the only
changes requested in that series.
Unless there is more from your side?

Cheers,
Andre

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Leon Anavi]

Hi,

Commit ffb0294 from 12 November 2023 that simplifies early PMIC setup
conditions causes issues on Cubieboard 4 and Merrii A80 Optimus with
Allwinner A80 SoC (sun9i). The commit was introduced with U-Boot 2024.01
(rc3) and remains as of today. Because of it both of these boards hang at:

Starting kernel ...

Older U-Boot versions without this commit work fine. As a temporary
solution I reverted commit ffb0294 and this way the boards boot
successfully. I tested this work around on Merrii A80 Optimus with several
U-Boot versions, including with U-Boot 2024.10.

Lazar, a friend who owns Cubieboard 4, also tested and confirmed his board
boots with U-Boot 2024.10 if this commit has been reverted.

How to fix this? Is there a known configuration that can be added to
Merrii_A80_Optimus_defconfig and Cubieboard4_defconfig to avoid hanging
with the existing source code from commit ffb0294 ?

Best regards,
Leon

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Andre Przywara]

On Mon, 9 Dec 2024 23:08:19 +0200
Leon Anavi <leon.anavi@konsulko.com> wrote:

Hi Leon,

thanks for the report!

> Commit ffb0294 from 12 November 2023 that simplifies early PMIC setup
> conditions causes issues on Cubieboard 4 and Merrii A80 Optimus with
> Allwinner A80 SoC (sun9i). The commit was introduced with U-Boot 2024.01
> (rc3) and remains as of today. Because of it both of these boards hang at:
> 
> Starting kernel ...

That's odd, how do you boot the kernel, exactly?
I just tried mainline U-Boot (via FEL), with:
=> setenv bootargs "console=ttyS0,115200n8 earlycon"
=> bootz $kernel_addr_r $ramdisk_addr_r:300000 $fdtcontroladdr

and it booted fine to the prompt, on a Cubieboard 4 (CC-A80 v1.2).
Kernel was some 6.11-rc6 I just had lying around.

I also compared the code before and after that patch, the only
difference is the order at which DCDC5 gets programmed: before it's
after DCDC4, with the patch it's right after DCDC1.
The rest looked the same.
Booting ffb0294~1 and ffb0294~0 also worked for me, without issues.
So can you please describe how you test that, exactly?

Please also note we fixed d75fa8c80dcfa in U-Boot (DCDC4/5 typo), and
dd36ad71ad6 in the kernel (DCDC5 constraints in the DT).

Cheers,
Andre

> Older U-Boot versions without this commit work fine. As a temporary
> solution I reverted commit ffb0294 and this way the boards boot
> successfully. I tested this work around on Merrii A80 Optimus with several
> U-Boot versions, including with U-Boot 2024.10.


> 
> Lazar, a friend who owns Cubieboard 4, also tested and confirmed his board
> boots with U-Boot 2024.10 if this commit has been reverted.
> 
> How to fix this? Is there a known configuration that can be added to
> Merrii_A80_Optimus_defconfig and Cubieboard4_defconfig to avoid hanging
> with the existing source code from commit ffb0294 ?
> 
> Best regards,
> Leon

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Leon Anavi]

Hi Andre,

On 11.12.24 г. 23:53 ч., Andre Przywara wrote:
> On Mon, 9 Dec 2024 23:08:19 +0200
> Leon Anavi<leon.anavi@konsulko.com> wrote:
>
> Hi Leon,
>
> thanks for the report!
>
>> Commit ffb0294 from 12 November 2023 that simplifies early PMIC setup
>> conditions causes issues on Cubieboard 4 and Merrii A80 Optimus with
>> Allwinner A80 SoC (sun9i). The commit was introduced with U-Boot 2024.01
>> (rc3) and remains as of today. Because of it both of these boards hang at:
>>
>> Starting kernel ...
> That's odd, how do you boot the kernel, exactly?
> I just tried mainline U-Boot (via FEL), with:
> => setenv bootargs "console=ttyS0,115200n8 earlycon"
> => bootz $kernel_addr_r $ramdisk_addr_r:300000 $fdtcontroladdr
>
> and it booted fine to the prompt, on a Cubieboard 4 (CC-A80 v1.2).
> Kernel was some 6.11-rc6 I just had lying around.
>
> I also compared the code before and after that patch, the only
> difference is the order at which DCDC5 gets programmed: before it's
> after DCDC4, with the patch it's right after DCDC1.
> The rest looked the same.
> Booting ffb0294~1 and ffb0294~0 also worked for me, without issues.
> So can you please describe how you test that, exactly?
I built core-image-base using the Yocto Project and OpenEmbedded as well 
as the meta-sunxi BSP layer. The U-Boot version depends on the Yocto 
release. For Scarthgap it is with U-Boot 2024.01 and for the ongoing 
development in the master branches the U-Boot version is 2024.10. The 
Linux kernel version is 6.6.28. I experienced the same issue with both 
U-Boot versions on Merrii A80 Optimus and Lazar (his email is CC) 
confirmed the same results on Cubieboard 4. The boot sequence for the 
boards in meta-sunxi is through boot.scr generated from the following 
boot.cmd:
https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-bsp/u-boot/files/arm/boot.cmd

In a nutshell, the issue can be reproduced with the following scenario 
in U-Boot:

setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 
rootwait panic=10
load mmc 0:1 ${fdt_addr_r} ${fdtfile}
load mmc 0:1 ${kernel_addr_r} zImage
bootz ${kernel_addr_r} - ${fdt_addr_r}

Merrii A80 Optimus board boots fine if I revert commit ffb0294. However, 
if commit ffb0294 is present in U-Boot the board hangs. Here is the log: 
U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000) Allwinner Technology 
CPU: Allwinner A80 (SUN9I) Model: Merrii A80 Optimus Board DRAM: 2 GiB 
Core: 62 devices, 18 uclasses, devicetree: separate WDT: Not starting 
watchdog@6000ca0 WDT: Not starting watchdog@8001000 MMC: 
sunxi_set_reset: (RST#0) unhandled sunxi_set_reset: (RST#2) unhandled 
sunxi_set_reset: (RST#1) unhandled mmc@1c0f000: 0, mmc@1c10000: 2, 
mmc@1c11000: 1 Loading Environment from FAT... Unable to read 
"uboot.env" from mmc0:1... In: serial@7000000 Out: serial@7000000 Err: 
serial@7000000 Net: No ethernet found. Hit any key to stop autoboot: 0 
=> setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 
rootwait panic=10 => load mmc 0:1 ${fdt_addr_r} ${fdtfile} 24443 bytes 
read in 3 ms (7.8 MiB/s) => load mmc 0:1 ${kernel_addr_r} zImage 5397992 
bytes read in 236 ms (21.8 MiB/s) => bootz ${kernel_addr_r} - 
${fdt_addr_r} Kernel image @ 0x22000000 [ 0x000000 - 0x525de8 ] ## 
Flattened Device Tree blob at 23000000 Booting using the fdt blob at 
0x23000000 Working FDT set to 23000000 Loading Device Tree to 29ff7000, 
end 29ffff7a ... OK Working FDT set to 29ff7000 Starting kernel ... 
Please note that U-Boot is marked with suffix "-dirty" because of the 
patches applied by u-boot_%.bbappend from Yocto/OE layer meta-sunxi but 
these patches are for other boards and don't touch the file 
board/sunxi/board.c. Am I missing something as a configuration that can 
make the board boot the same way without hanging when commit ffb0294 is 
present?Best regards,
Leon

>
> Please also note we fixed d75fa8c80dcfa in U-Boot (DCDC4/5 typo), and
> dd36ad71ad6 in the kernel (DCDC5 constraints in the DT).
>
> Cheers,
> Andre
>
>> Older U-Boot versions without this commit work fine. As a temporary
>> solution I reverted commit ffb0294 and this way the boards boot
>> successfully. I tested this work around on Merrii A80 Optimus with several
>> U-Boot versions, including with U-Boot 2024.10.
>
>> Lazar, a friend who owns Cubieboard 4, also tested and confirmed his board
>> boots with U-Boot 2024.10 if this commit has been reverted.
>>
>> How to fix this? Is there a known configuration that can be added to
>> Merrii_A80_Optimus_defconfig and Cubieboard4_defconfig to avoid hanging
>> with the existing source code from commit ffb0294 ?
>>
>> Best regards,
>> Leon

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Andre Przywara]

On Thu, 12 Dec 2024 11:19:06 +0200
Leon Anavi <leon.anavi@konsulko.com> wrote:

Hi Leon,

> On 11.12.24 г. 23:53 ч., Andre Przywara wrote:
> > On Mon, 9 Dec 2024 23:08:19 +0200
> > Leon Anavi<leon.anavi@konsulko.com> wrote:
> >
> > Hi Leon,
> >
> > thanks for the report!
> >  
> >> Commit ffb0294 from 12 November 2023 that simplifies early PMIC setup
> >> conditions causes issues on Cubieboard 4 and Merrii A80 Optimus with
> >> Allwinner A80 SoC (sun9i). The commit was introduced with U-Boot 2024.01
> >> (rc3) and remains as of today. Because of it both of these boards hang at:
> >>
> >> Starting kernel ...  
> > That's odd, how do you boot the kernel, exactly?
> > I just tried mainline U-Boot (via FEL), with:  
> > => setenv bootargs "console=ttyS0,115200n8 earlycon"
> > => bootz $kernel_addr_r $ramdisk_addr_r:300000 $fdtcontroladdr  
> >
> > and it booted fine to the prompt, on a Cubieboard 4 (CC-A80 v1.2).
> > Kernel was some 6.11-rc6 I just had lying around.
> >
> > I also compared the code before and after that patch, the only
> > difference is the order at which DCDC5 gets programmed: before it's
> > after DCDC4, with the patch it's right after DCDC1.
> > The rest looked the same.
> > Booting ffb0294~1 and ffb0294~0 also worked for me, without issues.
> > So can you please describe how you test that, exactly?  
> I built core-image-base using the Yocto Project and OpenEmbedded as well Starting kernel ...
> as the meta-sunxi BSP layer. The U-Boot version depends on the Yocto 
> release. For Scarthgap it is with U-Boot 2024.01 and for the ongoing 
> development in the master branches the U-Boot version is 2024.10. The 
> Linux kernel version is 6.6.28. I experienced the same issue with both 
> U-Boot versions on Merrii A80 Optimus and Lazar (his email is CC) 
> confirmed the same results on Cubieboard 4. The boot sequence for the 
> boards in meta-sunxi is through boot.scr generated from the following 
> boot.cmd:
> https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-bsp/u-boot/files/arm/boot.cmd
> 
> In a nutshell, the issue can be reproduced with the following scenario 
> in U-Boot:
> 
> setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 
> rootwait panic=10

So I tried with an SD card now, and I think I see what you mean now.
I was a bit confused first why it would hang for you after "Starting
kernel ...", but I guess it actually doesn't: can you add "earlycon" to your
command line and confirm that the kernel boots, but hangs while waiting
for the secondary cores?
I am still scratching my head how this commit would affect this
behaviour, but this change here seems to fix it for me:

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 29a329f41a2..d7c46eec615 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -582,7 +582,6 @@ void sunxi_board_init(void)
 
 #ifdef CONFIG_AXP_DCDC1_VOLT
 	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
-	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
 #endif
 #ifdef CONFIG_AXP_DCDC2_VOLT
 	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
@@ -591,6 +590,9 @@ void sunxi_board_init(void)
 #ifdef CONFIG_AXP_DCDC4_VOLT
 	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
 #endif
+#ifdef CONFIG_AXP_DCDC5_VOLT
+	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
+#endif
 
 #ifdef CONFIG_AXP_ALDO1_VOLT
 	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);

Can you confirm this?
This fix looks easily mainline-able, as it just restores the old
initialisation order, but I still would like to know why the other
order hangs. Will try to do some experiments.

Cheers,
Andre


> load mmc 0:1 ${fdt_addr_r} ${fdtfile}
> load mmc 0:1 ${kernel_addr_r} zImage
> bootz ${kernel_addr_r} - ${fdt_addr_r}
> 
> Merrii A80 Optimus board boots fine if I revert commit ffb0294.
> However, if commit ffb0294 is present in U-Boot the board hangs. Here
> is the log: U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
> Allwinner Technology CPU: Allwinner A80 (SUN9I) Model: Merrii A80
> Optimus Board DRAM: 2 GiB Core: 62 devices, 18 uclasses, devicetree:
> separate WDT: Not starting watchdog@6000ca0 WDT: Not starting
> watchdog@8001000 MMC: sunxi_set_reset: (RST#0) unhandled
> sunxi_set_reset: (RST#2) unhandled sunxi_set_reset: (RST#1) unhandled
> mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment
> from FAT... Unable to read "uboot.env" from mmc0:1... In:
> serial@7000000 Out: serial@7000000 Err: serial@7000000 Net: No
> ethernet found. Hit any key to stop autoboot: 0 => setenv bootargs
> console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootwait
> panic=10 => load mmc 0:1 ${fdt_addr_r} ${fdtfile} 24443 bytes read in
> 3 ms (7.8 MiB/s) => load mmc 0:1 ${kernel_addr_r} zImage 5397992
> bytes read in 236 ms (21.8 MiB/s) => bootz ${kernel_addr_r} -
> ${fdt_addr_r} Kernel image @ 0x22000000 [ 0x000000 - 0x525de8 ] ##
> Flattened Device Tree blob at 23000000 Booting using the fdt blob at
> 0x23000000 Working FDT set to 23000000 Loading Device Tree to
> 29ff7000, end 29ffff7a ... OK Working FDT set to 29ff7000 Starting
> kernel ... Please note that U-Boot is marked with suffix "-dirty"
> because of the patches applied by u-boot_%.bbappend from Yocto/OE
> layer meta-sunxi but these patches are for other boards and don't
> touch the file board/sunxi/board.c. Am I missing something as a
> configuration that can make the board boot the same way without
> hanging when commit ffb0294 is present?Best regards, Leon
> 
> >
> > Please also note we fixed d75fa8c80dcfa in U-Boot (DCDC4/5 typo),
> > and dd36ad71ad6 in the kernel (DCDC5 constraints in the DT).
> >
> > Cheers,
> > Andre
> >  
> >> Older U-Boot versions without this commit work fine. As a temporary
> >> solution I reverted commit ffb0294 and this way the boards boot
> >> successfully. I tested this work around on Merrii A80 Optimus with
> >> several U-Boot versions, including with U-Boot 2024.10.  
> >  
> >> Lazar, a friend who owns Cubieboard 4, also tested and confirmed
> >> his board boots with U-Boot 2024.10 if this commit has been
> >> reverted.
> >>
> >> How to fix this? Is there a known configuration that can be added
> >> to Merrii_A80_Optimus_defconfig and Cubieboard4_defconfig to avoid
> >> hanging with the existing source code from commit ffb0294 ?
> >>
> >> Best regards,
> >> Leon  

Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions

[Leon Anavi]

Hi Andre,

On 14.12.24 г. 4:19 ч., Andre Przywara wrote:
> On Thu, 12 Dec 2024 11:19:06 +0200
> Leon Anavi<leon.anavi@konsulko.com> wrote:
>
> Hi Leon,
>
>> On 11.12.24 г. 23:53 ч., Andre Przywara wrote:
>>> On Mon, 9 Dec 2024 23:08:19 +0200
>>> Leon Anavi<leon.anavi@konsulko.com> wrote:
>>>
>>> Hi Leon,
>>>
>>> thanks for the report!
>>>   
>>>> Commit ffb0294 from 12 November 2023 that simplifies early PMIC setup
>>>> conditions causes issues on Cubieboard 4 and Merrii A80 Optimus with
>>>> Allwinner A80 SoC (sun9i). The commit was introduced with U-Boot 2024.01
>>>> (rc3) and remains as of today. Because of it both of these boards hang at:
>>>>
>>>> Starting kernel ...
>>> That's odd, how do you boot the kernel, exactly?
>>> I just tried mainline U-Boot (via FEL), with:
>>> => setenv bootargs "console=ttyS0,115200n8 earlycon"
>>> => bootz $kernel_addr_r $ramdisk_addr_r:300000 $fdtcontroladdr
>>>
>>> and it booted fine to the prompt, on a Cubieboard 4 (CC-A80 v1.2).
>>> Kernel was some 6.11-rc6 I just had lying around.
>>>
>>> I also compared the code before and after that patch, the only
>>> difference is the order at which DCDC5 gets programmed: before it's
>>> after DCDC4, with the patch it's right after DCDC1.
>>> The rest looked the same.
>>> Booting ffb0294~1 and ffb0294~0 also worked for me, without issues.
>>> So can you please describe how you test that, exactly?
>> I built core-image-base using the Yocto Project and OpenEmbedded as well Starting kernel ...
>> as the meta-sunxi BSP layer. The U-Boot version depends on the Yocto
>> release. For Scarthgap it is with U-Boot 2024.01 and for the ongoing
>> development in the master branches the U-Boot version is 2024.10. The
>> Linux kernel version is 6.6.28. I experienced the same issue with both
>> U-Boot versions on Merrii A80 Optimus and Lazar (his email is CC)
>> confirmed the same results on Cubieboard 4. The boot sequence for the
>> boards in meta-sunxi is through boot.scr generated from the following
>> boot.cmd:
>> https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-bsp/u-boot/files/arm/boot.cmd
>>
>> In a nutshell, the issue can be reproduced with the following scenario
>> in U-Boot:
>>
>> setenv bootargs console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2
>> rootwait panic=10
> So I tried with an SD card now, and I think I see what you mean now.
> I was a bit confused first why it would hang for you after "Starting
> kernel ...", but I guess it actually doesn't: can you add "earlycon" to your
> command line and confirm that the kernel boots, but hangs while waiting
> for the secondary cores?
> I am still scratching my head how this commit would affect this
> behaviour, but this change here seems to fix it for me:
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 29a329f41a2..d7c46eec615 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -582,7 +582,6 @@ void sunxi_board_init(void)
>   
>   #ifdef CONFIG_AXP_DCDC1_VOLT
>   	power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
> -	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
>   #endif
>   #ifdef CONFIG_AXP_DCDC2_VOLT
>   	power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
> @@ -591,6 +590,9 @@ void sunxi_board_init(void)
>   #ifdef CONFIG_AXP_DCDC4_VOLT
>   	power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
>   #endif
> +#ifdef CONFIG_AXP_DCDC5_VOLT
> +	power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> +#endif
>   
>   #ifdef CONFIG_AXP_ALDO1_VOLT
>   	power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
>
> Can you confirm this?


Yes, thank you. Excellent work! I confirm this solution works. I have 
just tested it on Merrii A80 Optimus board. I applied your patch on top 
of U-Boot 2024.10.

> This fix looks easily mainline-able, as it just restores the old
> initialisation order, but I still would like to know why the other
> order hangs. Will try to do some experiments.

OK. In the mean time I will contribute your patch to meta-sunxi BSP 
layer so that it can be used for the existing U-Boot versions in images 
for sun9i machines built using the Yocto project and OpenEmbedded. This 
is obviously a far better solution than reverting commit ffb0294.
Thanks,
Leon

>
> Cheers,
> Andre
>
>
>> load mmc 0:1 ${fdt_addr_r} ${fdtfile}
>> load mmc 0:1 ${kernel_addr_r} zImage
>> bootz ${kernel_addr_r} - ${fdt_addr_r}
>>
>> Merrii A80 Optimus board boots fine if I revert commit ffb0294.
>> However, if commit ffb0294 is present in U-Boot the board hangs. Here
>> is the log: U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
>> Allwinner Technology CPU: Allwinner A80 (SUN9I) Model: Merrii A80
>> Optimus Board DRAM: 2 GiB Core: 62 devices, 18 uclasses, devicetree:
>> separate WDT: Not starting watchdog@6000ca0 WDT: Not starting
>> watchdog@8001000 MMC: sunxi_set_reset: (RST#0) unhandled
>> sunxi_set_reset: (RST#2) unhandled sunxi_set_reset: (RST#1) unhandled
>> mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment
>> from FAT... Unable to read "uboot.env" frommmc0:1... In:
>> serial@7000000 Out: serial@7000000 Err: serial@7000000 Net: No
>> ethernet found. Hit any key to stop autoboot: 0 => setenv bootargs
>> console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootwait
>> panic=10 => load mmc 0:1 ${fdt_addr_r} ${fdtfile} 24443 bytes read in
>> 3 ms (7.8 MiB/s) => load mmc 0:1 ${kernel_addr_r} zImage 5397992
>> bytes read in 236 ms (21.8 MiB/s) => bootz ${kernel_addr_r} -
>> ${fdt_addr_r} Kernel image @ 0x22000000 [ 0x000000 - 0x525de8 ] ##
>> Flattened Device Tree blob at 23000000 Booting using the fdt blob at
>> 0x23000000 Working FDT set to 23000000 Loading Device Tree to
>> 29ff7000, end 29ffff7a ... OK Working FDT set to 29ff7000 Starting
>> kernel ... Please note that U-Boot is marked with suffix "-dirty"
>> because of the patches applied by u-boot_%.bbappend from Yocto/OE
>> layer meta-sunxi but these patches are for other boards and don't
>> touch the file board/sunxi/board.c. Am I missing something as a
>> configuration that can make the board boot the same way without
>> hanging when commit ffb0294 is present?Best regards, Leon
>>
>>> Please also note we fixed d75fa8c80dcfa in U-Boot (DCDC4/5 typo),
>>> and dd36ad71ad6 in the kernel (DCDC5 constraints in the DT).
>>>
>>> Cheers,
>>> Andre
>>>   
>>>> Older U-Boot versions without this commit work fine. As a temporary
>>>> solution I reverted commit ffb0294 and this way the boards boot
>>>> successfully. I tested this work around on Merrii A80 Optimus with
>>>> several U-Boot versions, including with U-Boot 2024.10.
>>>   
>>>> Lazar, a friend who owns Cubieboard 4, also tested and confirmed
>>>> his board boots with U-Boot 2024.10 if this commit has been
>>>> reverted.
>>>>
>>>> How to fix this? Is there a known configuration that can be added
>>>> to Merrii_A80_Optimus_defconfig and Cubieboard4_defconfig to avoid
>>>> hanging with the existing source code from commit ffb0294 ?
>>>>
>>>> Best regards,
>>>> Leon