Broken commit de47ff536363289f92f85ed1e4901724d238432d

Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

Hello Tom!

Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.

If you look at P1020RDB-PD_defconfig file change in this commit there is:

--- a/configs/P1020RDB-PD_defconfig
+++ b/configs/P1020RDB-PD_defconfig
@@ -9,6 +9,7 @@ CONFIG_MPC85xx=y
 # CONFIG_CMD_ERRATA is not set
 CONFIG_TARGET_P1020RDB_PD=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
+CONFIG_SYS_MPC85XX_NO_RESETVEC=y
 CONFIG_MP=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y

Which does not make sense to me.

First thing is that CONFIG_MPC85XX_HAVE_RESET_VECTOR and
CONFIG_SYS_MPC85XX_NO_RESETVEC are exclusive options. You can either
disable generating of reset vector in image or enable it. What is
expected from the result when you ask Kconfig to both enable and disable
it? First specified option win? Or last specified win? Or random of
those two options win? It is not really clear for me.

Second thing is that reset vector is required for (parallel) NOR booting
and your change is adding CONFIG_SYS_MPC85XX_NO_RESETVEC=y to defconfig
for NOR, which to my guess make image non-bootable and broken.

And seems that other defconfig files in that change have similar issues.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:

> Hello Tom!
> 
> Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.

I thought I had managed to mirror the TPL/SPL/full usage that was there
prior, but apparently some got missed.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> 
> > Hello Tom!
> > 
> > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> 
> I thought I had managed to mirror the TPL/SPL/full usage that was there
> prior, but apparently some got missed.
> 
> -- 
> Tom

Yea, conversion to Kconfig seems that was incorrect.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > 
> > > Hello Tom!
> > > 
> > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > 
> > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > prior, but apparently some got missed.
> 
> Yea, conversion to Kconfig seems that was incorrect.

As the config files were just unclear, but you seem to understand what
it's supposed to be, a patch to clean it up would be most appreciated,
thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > 
> > > > Hello Tom!
> > > > 
> > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > 
> > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > prior, but apparently some got missed.
> > 
> > Yea, conversion to Kconfig seems that was incorrect.
> 
> As the config files were just unclear, but you seem to understand what
> it's supposed to be, a patch to clean it up would be most appreciated,
> thanks.
> 
> -- 
> Tom

Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
that all kconfig migration changes done after that commit are broken.

I really do not have energy to investigate what and how was broken due
to incorrect kconfig migration.


I did simple test. Applied following change:

diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index a6523753d5ca..489f24df0ab1 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
 "bootm $norbootaddr - $norfdtaddr"
 
 #endif /* __CONFIG_H */
+
+#ifdef CONFIG_SDCARD
+#error
+#endif

And then called:

make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin

And it failed, even when this defconfig file is not SD card builds.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > 
> > > > > Hello Tom!
> > > > > 
> > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > 
> > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > prior, but apparently some got missed.
> > > 
> > > Yea, conversion to Kconfig seems that was incorrect.
> > 
> > As the config files were just unclear, but you seem to understand what
> > it's supposed to be, a patch to clean it up would be most appreciated,
> > thanks.
> > 
> > -- 
> > Tom
> 
> Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> that all kconfig migration changes done after that commit are broken.
> 
> I really do not have energy to investigate what and how was broken due
> to incorrect kconfig migration.
> 
> 
> I did simple test. Applied following change:
> 
> diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> index a6523753d5ca..489f24df0ab1 100644
> --- a/include/configs/p1_p2_rdb_pc.h
> +++ b/include/configs/p1_p2_rdb_pc.h
> @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
>  "bootm $norbootaddr - $norfdtaddr"
>  
>  #endif /* __CONFIG_H */
> +
> +#ifdef CONFIG_SDCARD
> +#error
> +#endif
> 
> And then called:
> 
> make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> 
> And it failed, even when this defconfig file is not SD card builds.

Where is PBL in that case even then?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > 
> > > > > > Hello Tom!
> > > > > > 
> > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > 
> > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > prior, but apparently some got missed.
> > > > 
> > > > Yea, conversion to Kconfig seems that was incorrect.
> > > 
> > > As the config files were just unclear, but you seem to understand what
> > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > thanks.
> > > 
> > > -- 
> > > Tom
> > 
> > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > that all kconfig migration changes done after that commit are broken.
> > 
> > I really do not have energy to investigate what and how was broken due
> > to incorrect kconfig migration.
> > 
> > 
> > I did simple test. Applied following change:
> > 
> > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > index a6523753d5ca..489f24df0ab1 100644
> > --- a/include/configs/p1_p2_rdb_pc.h
> > +++ b/include/configs/p1_p2_rdb_pc.h
> > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> >  "bootm $norbootaddr - $norfdtaddr"
> >  
> >  #endif /* __CONFIG_H */
> > +
> > +#ifdef CONFIG_SDCARD
> > +#error
> > +#endif
> > 
> > And then called:
> > 
> > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > 
> > And it failed, even when this defconfig file is not SD card builds.
> 
> Where is PBL in that case even then?

P2020 (and older) are pre-PBL boards, they do not support NXP PBL
header.

In case of parallel NOR and parallel NAND booting there is no BootROM,
no preboot environment, nothing. CPU does execute-in-place, maps the
last page and starts execution of the last instruction on that page.
It is U-Boot code which just does branch to _start symbol (which is also
in the last page).

For NOR booting (P2020RDB-PC_defconfig) there is no SPL involved.

In case of SPI NOR or SD card booting, there is some trivial BootROM
which takes pre-PBL header and it can be either generated by external
NXP tool or now also U-Boot too (IIRC my patch for this was merged).

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > 
> > > > > > > Hello Tom!
> > > > > > > 
> > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > 
> > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > prior, but apparently some got missed.
> > > > > 
> > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > 
> > > > As the config files were just unclear, but you seem to understand what
> > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > thanks.
> > > > 
> > > > -- 
> > > > Tom
> > > 
> > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > that all kconfig migration changes done after that commit are broken.
> > > 
> > > I really do not have energy to investigate what and how was broken due
> > > to incorrect kconfig migration.
> > > 
> > > 
> > > I did simple test. Applied following change:
> > > 
> > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > index a6523753d5ca..489f24df0ab1 100644
> > > --- a/include/configs/p1_p2_rdb_pc.h
> > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > >  "bootm $norbootaddr - $norfdtaddr"
> > >  
> > >  #endif /* __CONFIG_H */
> > > +
> > > +#ifdef CONFIG_SDCARD
> > > +#error
> > > +#endif
> > > 
> > > And then called:
> > > 
> > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > 
> > > And it failed, even when this defconfig file is not SD card builds.
> > 
> > Where is PBL in that case even then?
> 
> P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> header.

Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
on "Freescale PBL load location".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Friday 05 August 2022 11:03:40 Tom Rini wrote:
> On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> > On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > 
> > > > > > > > Hello Tom!
> > > > > > > > 
> > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > > 
> > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > prior, but apparently some got missed.
> > > > > > 
> > > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > > 
> > > > > As the config files were just unclear, but you seem to understand what
> > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > thanks.
> > > > > 
> > > > > -- 
> > > > > Tom
> > > > 
> > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > that all kconfig migration changes done after that commit are broken.
> > > > 
> > > > I really do not have energy to investigate what and how was broken due
> > > > to incorrect kconfig migration.
> > > > 
> > > > 
> > > > I did simple test. Applied following change:
> > > > 
> > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > index a6523753d5ca..489f24df0ab1 100644
> > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > >  "bootm $norbootaddr - $norfdtaddr"
> > > >  
> > > >  #endif /* __CONFIG_H */
> > > > +
> > > > +#ifdef CONFIG_SDCARD
> > > > +#error
> > > > +#endif
> > > > 
> > > > And then called:
> > > > 
> > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > 
> > > > And it failed, even when this defconfig file is not SD card builds.
> > > 
> > > Where is PBL in that case even then?
> > 
> > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > header.
> 
> Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> on "Freescale PBL load location".
> 
> -- 
> Tom

I just do not understand.

P10** and P20** do not support NXP PBL. They support only pre-PBL and
for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.

But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
"SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
SD-card version of SPL to load proper U-Boot.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3225 bytes --]

On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:
> On Friday 05 August 2022 11:03:40 Tom Rini wrote:
> > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > 
> > > > > > > > > Hello Tom!
> > > > > > > > > 
> > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > > > 
> > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > prior, but apparently some got missed.
> > > > > > > 
> > > > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > > > 
> > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > thanks.
> > > > > > 
> > > > > > -- 
> > > > > > Tom
> > > > > 
> > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > that all kconfig migration changes done after that commit are broken.
> > > > > 
> > > > > I really do not have energy to investigate what and how was broken due
> > > > > to incorrect kconfig migration.
> > > > > 
> > > > > 
> > > > > I did simple test. Applied following change:
> > > > > 
> > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > >  
> > > > >  #endif /* __CONFIG_H */
> > > > > +
> > > > > +#ifdef CONFIG_SDCARD
> > > > > +#error
> > > > > +#endif
> > > > > 
> > > > > And then called:
> > > > > 
> > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > 
> > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > 
> > > > Where is PBL in that case even then?
> > > 
> > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > header.
> > 
> > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > on "Freescale PBL load location".
> > 
> > -- 
> > Tom
> 
> I just do not understand.
> 
> P10** and P20** do not support NXP PBL. They support only pre-PBL and
> for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> 
> But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> SD-card version of SPL to load proper U-Boot.

So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
needs to be corrected then.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Friday 05 August 2022 11:44:00 Tom Rini wrote:
> On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:
> > On Friday 05 August 2022 11:03:40 Tom Rini wrote:
> > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > 
> > > > > > > > > > Hello Tom!
> > > > > > > > > > 
> > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > > > > 
> > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > prior, but apparently some got missed.
> > > > > > > > 
> > > > > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > > > > 
> > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > thanks.
> > > > > > > 
> > > > > > > -- 
> > > > > > > Tom
> > > > > > 
> > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > 
> > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > to incorrect kconfig migration.
> > > > > > 
> > > > > > 
> > > > > > I did simple test. Applied following change:
> > > > > > 
> > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > >  
> > > > > >  #endif /* __CONFIG_H */
> > > > > > +
> > > > > > +#ifdef CONFIG_SDCARD
> > > > > > +#error
> > > > > > +#endif
> > > > > > 
> > > > > > And then called:
> > > > > > 
> > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > 
> > > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > > 
> > > > > Where is PBL in that case even then?
> > > > 
> > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > header.
> > > 
> > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > on "Freescale PBL load location".
> > > 
> > > -- 
> > > Tom
> > 
> > I just do not understand.
> > 
> > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > 
> > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > SD-card version of SPL to load proper U-Boot.
> 
> So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> needs to be corrected then.
> 
> -- 
> Tom

But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
mode in which can be booted from SD card. Or what do you have in mind as
purpose of this symbol?

The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
also when building (parallel) NOR version of U-Boot.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4366 bytes --]

On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:
> On Friday 05 August 2022 11:44:00 Tom Rini wrote:
> > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:
> > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:
> > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > 
> > > > > > > > > > > Hello Tom!
> > > > > > > > > > > 
> > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > > > > > 
> > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > prior, but apparently some got missed.
> > > > > > > > > 
> > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > > > > > 
> > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > thanks.
> > > > > > > > 
> > > > > > > > -- 
> > > > > > > > Tom
> > > > > > > 
> > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > 
> > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > to incorrect kconfig migration.
> > > > > > > 
> > > > > > > 
> > > > > > > I did simple test. Applied following change:
> > > > > > > 
> > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > >  
> > > > > > >  #endif /* __CONFIG_H */
> > > > > > > +
> > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > +#error
> > > > > > > +#endif
> > > > > > > 
> > > > > > > And then called:
> > > > > > > 
> > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > 
> > > > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > > > 
> > > > > > Where is PBL in that case even then?
> > > > > 
> > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > header.
> > > > 
> > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > on "Freescale PBL load location".
> > > > 
> > > > -- 
> > > > Tom
> > > 
> > > I just do not understand.
> > > 
> > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > 
> > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > SD-card version of SPL to load proper U-Boot.
> > 
> > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > needs to be corrected then.
> 
> But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> mode in which can be booted from SD card. Or what do you have in mind as
> purpose of this symbol?
> 
> The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> also when building (parallel) NOR version of U-Boot.

To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
non-descriptive and that for some platforms it means "we have NXP PBL"
and others means "we're booting from SDCARD". The former should be
renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
which is still a bad name, but what everyone else uses, so makes
renaming it later to something less bad easier.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Friday 05 August 2022 11:54:53 Tom Rini wrote:
> On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:
> > On Friday 05 August 2022 11:44:00 Tom Rini wrote:
> > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:
> > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:
> > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > 
> > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > > > > > > 
> > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > prior, but apparently some got missed.
> > > > > > > > > > 
> > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > > > > > > 
> > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > thanks.
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > Tom
> > > > > > > > 
> > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > 
> > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > to incorrect kconfig migration.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > I did simple test. Applied following change:
> > > > > > > > 
> > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > >  
> > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > +
> > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > +#error
> > > > > > > > +#endif
> > > > > > > > 
> > > > > > > > And then called:
> > > > > > > > 
> > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > 
> > > > > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > > > > 
> > > > > > > Where is PBL in that case even then?
> > > > > > 
> > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > header.
> > > > > 
> > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > on "Freescale PBL load location".
> > > > > 
> > > > > -- 
> > > > > Tom
> > > > 
> > > > I just do not understand.
> > > > 
> > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > 
> > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > SD-card version of SPL to load proper U-Boot.
> > > 
> > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > needs to be corrected then.
> > 
> > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > mode in which can be booted from SD card. Or what do you have in mind as
> > purpose of this symbol?
> > 
> > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > also when building (parallel) NOR version of U-Boot.
> 
> To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> non-descriptive and that for some platforms it means "we have NXP PBL"
> and others means "we're booting from SDCARD". The former should be
> renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> which is still a bad name, but what everyone else uses, so makes
> renaming it later to something less bad easier.
> 
> -- 
> Tom

So I hope that you will do something with it. I already spent lot of
time to fix and improve powerpc support, but the result is that my
patches are on the list, mostly ignored; but changes which are breaking
powerpc support are happily merging. In this state I'm loosing any
motivation to continue development as it is needed to do again to find
out what new is broken.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5798 bytes --]

On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> On Friday 05 August 2022 11:54:53 Tom Rini wrote:
> > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:
> > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:
> > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:
> > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:
> > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:
> > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:
> > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:
> > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:
> > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > > > > > > > > > > > 
> > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > prior, but apparently some got missed.
> > > > > > > > > > > 
> > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.
> > > > > > > > > > 
> > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > thanks.
> > > > > > > > > > 
> > > > > > > > > > -- 
> > > > > > > > > > Tom
> > > > > > > > > 
> > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > 
> > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > 
> > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > >  
> > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > +
> > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > +#error
> > > > > > > > > +#endif
> > > > > > > > > 
> > > > > > > > > And then called:
> > > > > > > > > 
> > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > 
> > > > > > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > > > > > 
> > > > > > > > Where is PBL in that case even then?
> > > > > > > 
> > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > header.
> > > > > > 
> > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > on "Freescale PBL load location".
> > > > > > 
> > > > > > -- 
> > > > > > Tom
> > > > > 
> > > > > I just do not understand.
> > > > > 
> > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > 
> > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > SD-card version of SPL to load proper U-Boot.
> > > > 
> > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > needs to be corrected then.
> > > 
> > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > mode in which can be booted from SD card. Or what do you have in mind as
> > > purpose of this symbol?
> > > 
> > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > also when building (parallel) NOR version of U-Boot.
> > 
> > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > non-descriptive and that for some platforms it means "we have NXP PBL"
> > and others means "we're booting from SDCARD". The former should be
> > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > which is still a bad name, but what everyone else uses, so makes
> > renaming it later to something less bad easier.
> 
> So I hope that you will do something with it. I already spent lot of
> time to fix and improve powerpc support, but the result is that my
> patches are on the list, mostly ignored; but changes which are breaking
> powerpc support are happily merging. In this state I'm loosing any
> motivation to continue development as it is needed to do again to find
> out what new is broken.

I'm not planning to try and further fiddle with those symbols. A
simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
assume that Marek will be picking up your PowerPC patches at this point,
so any further work you're doing in that area shouldn't be delayed.
I'll put re-examining this on my TODO list, but it's below finishing my
CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.

You should fix whatever platforms you have access to and ignore the
rest, I feel likely to be removing most of them shortly at this point.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Marek Behún]

On Fri, 5 Aug 2022 18:20:19 -0400
Tom Rini <trini@konsulko.com> wrote:

> On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > >   
> > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > 
> > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > 
> > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > thanks.
> > > > > > > > > > > 
> > > > > > > > > > > -- 
> > > > > > > > > > > Tom  
> > > > > > > > > > 
> > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > 
> > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > 
> > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > >  
> > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > +
> > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > +#error
> > > > > > > > > > +#endif
> > > > > > > > > > 
> > > > > > > > > > And then called:
> > > > > > > > > > 
> > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > 
> > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > 
> > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > 
> > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > header.  
> > > > > > > 
> > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > on "Freescale PBL load location".
> > > > > > > 
> > > > > > > -- 
> > > > > > > Tom  
> > > > > > 
> > > > > > I just do not understand.
> > > > > > 
> > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > 
> > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > 
> > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > needs to be corrected then.  
> > > > 
> > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > purpose of this symbol?
> > > > 
> > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > also when building (parallel) NOR version of U-Boot.  
> > > 
> > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > and others means "we're booting from SDCARD". The former should be
> > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > which is still a bad name, but what everyone else uses, so makes
> > > renaming it later to something less bad easier.  
> > 
> > So I hope that you will do something with it. I already spent lot of
> > time to fix and improve powerpc support, but the result is that my
> > patches are on the list, mostly ignored; but changes which are breaking
> > powerpc support are happily merging. In this state I'm loosing any
> > motivation to continue development as it is needed to do again to find
> > out what new is broken.  
> 
> I'm not planning to try and further fiddle with those symbols. A
> simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> assume that Marek will be picking up your PowerPC patches at this point,
> so any further work you're doing in that area shouldn't be delayed.
> I'll put re-examining this on my TODO list, but it's below finishing my
> CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> 
> You should fix whatever platforms you have access to and ignore the
> rest, I feel likely to be removing most of them shortly at this point.
> 

I shall try to fix this on our platform by "reverting" these to
different names, so that there are no new CONFIG_ macros.

Marek

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6702 bytes --]

On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> On Fri, 5 Aug 2022 18:20:19 -0400
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > 
> > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > thanks.
> > > > > > > > > > > > 
> > > > > > > > > > > > -- 
> > > > > > > > > > > > Tom  
> > > > > > > > > > > 
> > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > 
> > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > >  
> > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > +#error
> > > > > > > > > > > +#endif
> > > > > > > > > > > 
> > > > > > > > > > > And then called:
> > > > > > > > > > > 
> > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > 
> > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > 
> > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > 
> > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > header.  
> > > > > > > > 
> > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > on "Freescale PBL load location".
> > > > > > > > 
> > > > > > > > -- 
> > > > > > > > Tom  
> > > > > > > 
> > > > > > > I just do not understand.
> > > > > > > 
> > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > 
> > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > 
> > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > needs to be corrected then.  
> > > > > 
> > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > purpose of this symbol?
> > > > > 
> > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > also when building (parallel) NOR version of U-Boot.  
> > > > 
> > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > and others means "we're booting from SDCARD". The former should be
> > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > which is still a bad name, but what everyone else uses, so makes
> > > > renaming it later to something less bad easier.  
> > > 
> > > So I hope that you will do something with it. I already spent lot of
> > > time to fix and improve powerpc support, but the result is that my
> > > patches are on the list, mostly ignored; but changes which are breaking
> > > powerpc support are happily merging. In this state I'm loosing any
> > > motivation to continue development as it is needed to do again to find
> > > out what new is broken.  
> > 
> > I'm not planning to try and further fiddle with those symbols. A
> > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > assume that Marek will be picking up your PowerPC patches at this point,
> > so any further work you're doing in that area shouldn't be delayed.
> > I'll put re-examining this on my TODO list, but it's below finishing my
> > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > 
> > You should fix whatever platforms you have access to and ignore the
> > rest, I feel likely to be removing most of them shortly at this point.
> > 
> 
> I shall try to fix this on our platform by "reverting" these to
> different names, so that there are no new CONFIG_ macros.

OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
soon, since they've been orphaned for a long while.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Monday 08 August 2022 09:37:22 Tom Rini wrote:
> On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> > On Fri, 5 Aug 2022 18:20:19 -0400
> > Tom Rini <trini@konsulko.com> wrote:
> > 
> > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > -- 
> > > > > > > > > > > > > Tom  
> > > > > > > > > > > > 
> > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > 
> > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > >  
> > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > +
> > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > +#error
> > > > > > > > > > > > +#endif
> > > > > > > > > > > > 
> > > > > > > > > > > > And then called:
> > > > > > > > > > > > 
> > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > 
> > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > > 
> > > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > > 
> > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > header.  
> > > > > > > > > 
> > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > Tom  
> > > > > > > > 
> > > > > > > > I just do not understand.
> > > > > > > > 
> > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > 
> > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > > 
> > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > needs to be corrected then.  
> > > > > > 
> > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > purpose of this symbol?
> > > > > > 
> > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > also when building (parallel) NOR version of U-Boot.  
> > > > > 
> > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > and others means "we're booting from SDCARD". The former should be
> > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > renaming it later to something less bad easier.  
> > > > 
> > > > So I hope that you will do something with it. I already spent lot of
> > > > time to fix and improve powerpc support, but the result is that my
> > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > powerpc support are happily merging. In this state I'm loosing any
> > > > motivation to continue development as it is needed to do again to find
> > > > out what new is broken.  
> > > 
> > > I'm not planning to try and further fiddle with those symbols. A
> > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > assume that Marek will be picking up your PowerPC patches at this point,
> > > so any further work you're doing in that area shouldn't be delayed.
> > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > 
> > > You should fix whatever platforms you have access to and ignore the
> > > rest, I feel likely to be removing most of them shortly at this point.
> > > 
> > 
> > I shall try to fix this on our platform by "reverting" these to
> > different names, so that there are no new CONFIG_ macros.
> 
> OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> soon, since they've been orphaned for a long while.
> 
> -- 
> Tom

Any progress on fixing this issue? Currently all this stuff is not
working in u-boot master due to broken kconfig migration. And any
continuation in kconfig migration just makes it worse and harder to fix
later.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7582 bytes --]

On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:
> On Monday 08 August 2022 09:37:22 Tom Rini wrote:
> > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > Tom  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > >  
> > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > +#error
> > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > 
> > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > 
> > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > > > 
> > > > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > > > 
> > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > header.  
> > > > > > > > > > 
> > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > 
> > > > > > > > > > -- 
> > > > > > > > > > Tom  
> > > > > > > > > 
> > > > > > > > > I just do not understand.
> > > > > > > > > 
> > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > 
> > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > > > 
> > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > needs to be corrected then.  
> > > > > > > 
> > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > purpose of this symbol?
> > > > > > > 
> > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > also when building (parallel) NOR version of U-Boot.  
> > > > > > 
> > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > renaming it later to something less bad easier.  
> > > > > 
> > > > > So I hope that you will do something with it. I already spent lot of
> > > > > time to fix and improve powerpc support, but the result is that my
> > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > motivation to continue development as it is needed to do again to find
> > > > > out what new is broken.  
> > > > 
> > > > I'm not planning to try and further fiddle with those symbols. A
> > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > so any further work you're doing in that area shouldn't be delayed.
> > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > 
> > > > You should fix whatever platforms you have access to and ignore the
> > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > 
> > > 
> > > I shall try to fix this on our platform by "reverting" these to
> > > different names, so that there are no new CONFIG_ macros.
> > 
> > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > soon, since they've been orphaned for a long while.
> 
> Any progress on fixing this issue? Currently all this stuff is not
> working in u-boot master due to broken kconfig migration. And any
> continuation in kconfig migration just makes it worse and harder to fix
> later.

I've removed the corenet_ds platforms now.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Friday 26 August 2022 10:53:58 Tom Rini wrote:
> On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:
> > On Monday 08 August 2022 09:37:22 Tom Rini wrote:
> > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > Tom Rini <trini@konsulko.com> wrote:
> > > > 
> > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > Tom  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > >  
> > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > > > > 
> > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > header.  
> > > > > > > > > > > 
> > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > 
> > > > > > > > > > > -- 
> > > > > > > > > > > Tom  
> > > > > > > > > > 
> > > > > > > > > > I just do not understand.
> > > > > > > > > > 
> > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > 
> > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > > > > 
> > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > needs to be corrected then.  
> > > > > > > > 
> > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > purpose of this symbol?
> > > > > > > > 
> > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > also when building (parallel) NOR version of U-Boot.  
> > > > > > > 
> > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > renaming it later to something less bad easier.  
> > > > > > 
> > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > motivation to continue development as it is needed to do again to find
> > > > > > out what new is broken.  
> > > > > 
> > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > 
> > > > > You should fix whatever platforms you have access to and ignore the
> > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > 
> > > > 
> > > > I shall try to fix this on our platform by "reverting" these to
> > > > different names, so that there are no new CONFIG_ macros.
> > > 
> > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > soon, since they've been orphaned for a long while.
> > 
> > Any progress on fixing this issue? Currently all this stuff is not
> > working in u-boot master due to broken kconfig migration. And any
> > continuation in kconfig migration just makes it worse and harder to fix
> > later.
> 
> I've removed the corenet_ds platforms now.
> 
> -- 
> Tom

I'm reminding this issue again. u-boot master branch is still broken.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 8476 bytes --]

On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:
> On Friday 26 August 2022 10:53:58 Tom Rini wrote:
> > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:
> > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:
> > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > 
> > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > Tom  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > header.  
> > > > > > > > > > > > 
> > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > 
> > > > > > > > > > > > -- 
> > > > > > > > > > > > Tom  
> > > > > > > > > > > 
> > > > > > > > > > > I just do not understand.
> > > > > > > > > > > 
> > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > 
> > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > > > > > 
> > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > needs to be corrected then.  
> > > > > > > > > 
> > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > purpose of this symbol?
> > > > > > > > > 
> > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > also when building (parallel) NOR version of U-Boot.  
> > > > > > > > 
> > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > renaming it later to something less bad easier.  
> > > > > > > 
> > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > out what new is broken.  
> > > > > > 
> > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > 
> > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > 
> > > > > 
> > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > different names, so that there are no new CONFIG_ macros.
> > > > 
> > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > soon, since they've been orphaned for a long while.
> > > 
> > > Any progress on fixing this issue? Currently all this stuff is not
> > > working in u-boot master due to broken kconfig migration. And any
> > > continuation in kconfig migration just makes it worse and harder to fix
> > > later.
> > 
> > I've removed the corenet_ds platforms now.
> 
> I'm reminding this issue again. u-boot master branch is still broken.

I don't really remember what the fix was at this point, but you should
fix whatever boards you have and care about as it's a matter of
selecting the correct option, yes?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Sunday 09 October 2022 08:45:03 Tom Rini wrote:
> On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:
> > On Friday 26 August 2022 10:53:58 Tom Rini wrote:
> > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:
> > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:
> > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> > > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > > 
> > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > Tom  
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > > header.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > > 
> > > > > > > > > > > > > -- 
> > > > > > > > > > > > > Tom  
> > > > > > > > > > > > 
> > > > > > > > > > > > I just do not understand.
> > > > > > > > > > > > 
> > > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > > 
> > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > > > > > > 
> > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > > needs to be corrected then.  
> > > > > > > > > > 
> > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > > purpose of this symbol?
> > > > > > > > > > 
> > > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > > also when building (parallel) NOR version of U-Boot.  
> > > > > > > > > 
> > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > > renaming it later to something less bad easier.  
> > > > > > > > 
> > > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > > out what new is broken.  
> > > > > > > 
> > > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > > 
> > > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > > 
> > > > > > 
> > > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > > different names, so that there are no new CONFIG_ macros.
> > > > > 
> > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > > soon, since they've been orphaned for a long while.
> > > > 
> > > > Any progress on fixing this issue? Currently all this stuff is not
> > > > working in u-boot master due to broken kconfig migration. And any
> > > > continuation in kconfig migration just makes it worse and harder to fix
> > > > later.
> > > 
> > > I've removed the corenet_ds platforms now.
> > 
> > I'm reminding this issue again. u-boot master branch is still broken.
> 
> I don't really remember what the fix was at this point, but you should
> fix whatever boards you have and care about as it's a matter of
> selecting the correct option, yes?

See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pali/
Broken is Kconfig migration which you done. I wrote in that email simple
test case how to check if it is OK or not.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 9576 bytes --]

On Sun, Oct 09, 2022 at 03:10:45PM +0200, Pali Rohár wrote:
> On Sunday 09 October 2022 08:45:03 Tom Rini wrote:
> > On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:
> > > On Friday 26 August 2022 10:53:58 Tom Rini wrote:
> > > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:
> > > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:
> > > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:
> > > > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > > > 
> > > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:
> > > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:  
> > > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:  
> > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:  
> > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:  
> > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:  
> > > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:  
> > > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.  
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > > > prior, but apparently some got missed.  
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.  
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > > Tom  
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.  
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Where is PBL in that case even then?  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > > > header.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > Tom  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I just do not understand.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > > > SD-card version of SPL to load proper U-Boot.  
> > > > > > > > > > > > 
> > > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > > > needs to be corrected then.  
> > > > > > > > > > > 
> > > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > > > purpose of this symbol?
> > > > > > > > > > > 
> > > > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > > > also when building (parallel) NOR version of U-Boot.  
> > > > > > > > > > 
> > > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > > > renaming it later to something less bad easier.  
> > > > > > > > > 
> > > > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > > > out what new is broken.  
> > > > > > > > 
> > > > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > > > 
> > > > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > > > 
> > > > > > > 
> > > > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > > > different names, so that there are no new CONFIG_ macros.
> > > > > > 
> > > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > > > soon, since they've been orphaned for a long while.
> > > > > 
> > > > > Any progress on fixing this issue? Currently all this stuff is not
> > > > > working in u-boot master due to broken kconfig migration. And any
> > > > > continuation in kconfig migration just makes it worse and harder to fix
> > > > > later.
> > > > 
> > > > I've removed the corenet_ds platforms now.
> > > 
> > > I'm reminding this issue again. u-boot master branch is still broken.
> > 
> > I don't really remember what the fix was at this point, but you should
> > fix whatever boards you have and care about as it's a matter of
> > selecting the correct option, yes?
> 
> See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pali/
> Broken is Kconfig migration which you done. I wrote in that email simple
> test case how to check if it is OK or not.

Yes, but I'm not un-migrating the symbol. As I think you're the only
person who cares about mpc85xx platforms right now, is your platform
working, or is there something that needs to be changed so that it does
work?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Marek Behún]

On Sun, 9 Oct 2022 12:32:02 -0400
Tom Rini <trini@konsulko.com> wrote:

> On Sun, Oct 09, 2022 at 03:10:45PM +0200, Pali Rohár wrote:
> > On Sunday 09 October 2022 08:45:03 Tom Rini wrote:  
> > > On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:  
> > > > On Friday 26 August 2022 10:53:58 Tom Rini wrote:  
> > > > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:  
> > > > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:  
> > > > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:  
> > > > > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >   
> > > > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:  
> > > > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:    
> > > > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:    
> > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:    
> > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > > > >     
> > > > > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.    
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > > > > prior, but apparently some got missed.    
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.    
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.    
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Where is PBL in that case even then?    
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > > > > header.    
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I just do not understand.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > > > > SD-card version of SPL to load proper U-Boot.    
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > > > > needs to be corrected then.    
> > > > > > > > > > > > 
> > > > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > > > > purpose of this symbol?
> > > > > > > > > > > > 
> > > > > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > > > > also when building (parallel) NOR version of U-Boot.    
> > > > > > > > > > > 
> > > > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > > > > renaming it later to something less bad easier.    
> > > > > > > > > > 
> > > > > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > > > > out what new is broken.    
> > > > > > > > > 
> > > > > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > > > > 
> > > > > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > > > >   
> > > > > > > > 
> > > > > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > > > > different names, so that there are no new CONFIG_ macros.  
> > > > > > > 
> > > > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > > > > soon, since they've been orphaned for a long while.  
> > > > > > 
> > > > > > Any progress on fixing this issue? Currently all this stuff is not
> > > > > > working in u-boot master due to broken kconfig migration. And any
> > > > > > continuation in kconfig migration just makes it worse and harder to fix
> > > > > > later.  
> > > > > 
> > > > > I've removed the corenet_ds platforms now.  
> > > > 
> > > > I'm reminding this issue again. u-boot master branch is still broken.  
> > > 
> > > I don't really remember what the fix was at this point, but you should
> > > fix whatever boards you have and care about as it's a matter of
> > > selecting the correct option, yes?  
> > 
> > See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pali/
> > Broken is Kconfig migration which you done. I wrote in that email simple
> > test case how to check if it is OK or not.  
> 
> Yes, but I'm not un-migrating the symbol. As I think you're the only
> person who cares about mpc85xx platforms right now, is your platform
> working, or is there something that needs to be changed so that it does
> work?
> 

He's not the only one. I am still rebasing Pali's patches on top of
current master. Please give me some more time.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Monday 10 October 2022 14:20:20 Marek Behún wrote:
> On Sun, 9 Oct 2022 12:32:02 -0400
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Sun, Oct 09, 2022 at 03:10:45PM +0200, Pali Rohár wrote:
> > > On Sunday 09 October 2022 08:45:03 Tom Rini wrote:  
> > > > On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:  
> > > > > On Friday 26 August 2022 10:53:58 Tom Rini wrote:  
> > > > > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:  
> > > > > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:  
> > > > > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:  
> > > > > > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >   
> > > > > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:    
> > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:    
> > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:    
> > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > > > > >     
> > > > > > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.    
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > > > > > prior, but apparently some got missed.    
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.    
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.    
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Where is PBL in that case even then?    
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > > > > > header.    
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I just do not understand.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > > > > > SD-card version of SPL to load proper U-Boot.    
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > > > > > needs to be corrected then.    
> > > > > > > > > > > > > 
> > > > > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > > > > > purpose of this symbol?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > > > > > also when building (parallel) NOR version of U-Boot.    
> > > > > > > > > > > > 
> > > > > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > > > > > renaming it later to something less bad easier.    
> > > > > > > > > > > 
> > > > > > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > > > > > out what new is broken.    
> > > > > > > > > > 
> > > > > > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > > > > > 
> > > > > > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > > > > >   
> > > > > > > > > 
> > > > > > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > > > > > different names, so that there are no new CONFIG_ macros.  
> > > > > > > > 
> > > > > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > > > > > soon, since they've been orphaned for a long while.  
> > > > > > > 
> > > > > > > Any progress on fixing this issue? Currently all this stuff is not
> > > > > > > working in u-boot master due to broken kconfig migration. And any
> > > > > > > continuation in kconfig migration just makes it worse and harder to fix
> > > > > > > later.  
> > > > > > 
> > > > > > I've removed the corenet_ds platforms now.  
> > > > > 
> > > > > I'm reminding this issue again. u-boot master branch is still broken.  
> > > > 
> > > > I don't really remember what the fix was at this point, but you should
> > > > fix whatever boards you have and care about as it's a matter of
> > > > selecting the correct option, yes?  
> > > 
> > > See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pali/
> > > Broken is Kconfig migration which you done. I wrote in that email simple
> > > test case how to check if it is OK or not.  
> > 
> > Yes, but I'm not un-migrating the symbol. As I think you're the only
> > person who cares about mpc85xx platforms right now, is your platform
> > working, or is there something that needs to be changed so that it does
> > work?
> > 
> 
> He's not the only one. I am still rebasing Pali's patches on top of
> current master. Please give me some more time.

Gentle reminder.

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Wednesday 02 November 2022 00:14:21 Pali Rohár wrote:
> On Monday 10 October 2022 14:20:20 Marek Behún wrote:
> > On Sun, 9 Oct 2022 12:32:02 -0400
> > Tom Rini <trini@konsulko.com> wrote:
> > 
> > > On Sun, Oct 09, 2022 at 03:10:45PM +0200, Pali Rohár wrote:
> > > > On Sunday 09 October 2022 08:45:03 Tom Rini wrote:  
> > > > > On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:  
> > > > > > On Friday 26 August 2022 10:53:58 Tom Rini wrote:  
> > > > > > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:  
> > > > > > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:  
> > > > > > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:  
> > > > > > > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > > > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >   
> > > > > > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:    
> > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:    
> > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > > > > > >     
> > > > > > > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.    
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > > > > > > prior, but apparently some got missed.    
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.    
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.    
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Where is PBL in that case even then?    
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > > > > > > header.    
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I just do not understand.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > > > > > > SD-card version of SPL to load proper U-Boot.    
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > > > > > > needs to be corrected then.    
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > > > > > > purpose of this symbol?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > > > > > > also when building (parallel) NOR version of U-Boot.    
> > > > > > > > > > > > > 
> > > > > > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > > > > > > renaming it later to something less bad easier.    
> > > > > > > > > > > > 
> > > > > > > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > > > > > > out what new is broken.    
> > > > > > > > > > > 
> > > > > > > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > > > > > > 
> > > > > > > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > > > > > >   
> > > > > > > > > > 
> > > > > > > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > > > > > > different names, so that there are no new CONFIG_ macros.  
> > > > > > > > > 
> > > > > > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > > > > > > soon, since they've been orphaned for a long while.  
> > > > > > > > 
> > > > > > > > Any progress on fixing this issue? Currently all this stuff is not
> > > > > > > > working in u-boot master due to broken kconfig migration. And any
> > > > > > > > continuation in kconfig migration just makes it worse and harder to fix
> > > > > > > > later.  
> > > > > > > 
> > > > > > > I've removed the corenet_ds platforms now.  
> > > > > > 
> > > > > > I'm reminding this issue again. u-boot master branch is still broken.  
> > > > > 
> > > > > I don't really remember what the fix was at this point, but you should
> > > > > fix whatever boards you have and care about as it's a matter of
> > > > > selecting the correct option, yes?  
> > > > 
> > > > See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pali/
> > > > Broken is Kconfig migration which you done. I wrote in that email simple
> > > > test case how to check if it is OK or not.  
> > > 
> > > Yes, but I'm not un-migrating the symbol. As I think you're the only
> > > person who cares about mpc85xx platforms right now, is your platform
> > > working, or is there something that needs to be changed so that it does
> > > work?
> > > 
> > 
> > He's not the only one. I am still rebasing Pali's patches on top of
> > current master. Please give me some more time.
> 
> Gentle reminder.

What is the state?

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

On Monday 21 November 2022 18:56:42 Pali Rohár wrote:
> On Wednesday 02 November 2022 00:14:21 Pali Rohár wrote:
> > On Monday 10 October 2022 14:20:20 Marek Behún wrote:
> > > On Sun, 9 Oct 2022 12:32:02 -0400
> > > Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > > On Sun, Oct 09, 2022 at 03:10:45PM +0200, Pali Rohár wrote:
> > > > > On Sunday 09 October 2022 08:45:03 Tom Rini wrote:  
> > > > > > On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Rohár wrote:  
> > > > > > > On Friday 26 August 2022 10:53:58 Tom Rini wrote:  
> > > > > > > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Rohár wrote:  
> > > > > > > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote:  
> > > > > > > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Behún wrote:  
> > > > > > > > > > > On Fri, 5 Aug 2022 18:20:19 -0400
> > > > > > > > > > > Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >   
> > > > > > > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Rohár wrote:  
> > > > > > > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote:    
> > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote:    
> > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:    
> > > > > > > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:    
> > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > > > > > > >     
> > > > > > > > > > > > > > > > > > > > > > > > > Hello Tom!
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > > > > > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.    
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > > > > > > > > > > > > > > > > > > > > > > > prior, but apparently some got missed.    
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems that was incorrect.    
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > As the config files were just unclear, but you seem to understand what
> > > > > > > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean it up would be most appreciated,
> > > > > > > > > > > > > > > > > > > > > > thanks.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > > > > > > > > > > > > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > > > > > > > > > > > > > > > > to incorrect kconfig migration.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > I did simple test. Applied following change:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > > > > > > > > > > > > > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > >  #endif /* __CONFIG_H */
> > > > > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD
> > > > > > > > > > > > > > > > > > > > > +#error
> > > > > > > > > > > > > > > > > > > > > +#endif
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > And then called:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > And it failed, even when this defconfig file is not SD card builds.    
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Where is PBL in that case even then?    
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they do not support NXP PBL
> > > > > > > > > > > > > > > > > > > header.    
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Ah, OK, then it should just be removing TARGET_P2020RDB from the choice
> > > > > > > > > > > > > > > > > > on "Freescale PBL load location".
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > > > > Tom    
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I just do not understand.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > P10** and P20** do not support NXP PBL. They support only pre-PBL and
> > > > > > > > > > > > > > > > > for SD card pre-PBL support I added option FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS_EXTRA_OPTIONS contains
> > > > > > > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then also in P10** and P20**
> > > > > > > > > > > > > > > > > SD-card version of SPL to load proper U-Boot.    
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very frustrating. That's what
> > > > > > > > > > > > > > > > needs to be corrected then.    
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that U-Boot is compiled in
> > > > > > > > > > > > > > > mode in which can be booted from SD card. Or what do you have in mind as
> > > > > > > > > > > > > > > purpose of this symbol?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > The issue is that your Kconfig migration changes enabled CONFIG_SDCARD
> > > > > > > > > > > > > > > also when building (parallel) NOR version of U-Boot.    
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exists. It's very much
> > > > > > > > > > > > > > non-descriptive and that for some platforms it means "we have NXP PBL"
> > > > > > > > > > > > > > and others means "we're booting from SDCARD". The former should be
> > > > > > > > > > > > > > renamed to be descriptive, and the latter should re-use CONFIG_SD_CARD
> > > > > > > > > > > > > > which is still a bad name, but what everyone else uses, so makes
> > > > > > > > > > > > > > renaming it later to something less bad easier.    
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So I hope that you will do something with it. I already spent lot of
> > > > > > > > > > > > > time to fix and improve powerpc support, but the result is that my
> > > > > > > > > > > > > patches are on the list, mostly ignored; but changes which are breaking
> > > > > > > > > > > > > powerpc support are happily merging. In this state I'm loosing any
> > > > > > > > > > > > > motivation to continue development as it is needed to do again to find
> > > > > > > > > > > > > out what new is broken.    
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm not planning to try and further fiddle with those symbols. A
> > > > > > > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS is gone. I
> > > > > > > > > > > > assume that Marek will be picking up your PowerPC patches at this point,
> > > > > > > > > > > > so any further work you're doing in that area shouldn't be delayed.
> > > > > > > > > > > > I'll put re-examining this on my TODO list, but it's below finishing my
> > > > > > > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS.
> > > > > > > > > > > > 
> > > > > > > > > > > > You should fix whatever platforms you have access to and ignore the
> > > > > > > > > > > > rest, I feel likely to be removing most of them shortly at this point.
> > > > > > > > > > > >   
> > > > > > > > > > > 
> > > > > > > > > > > I shall try to fix this on our platform by "reverting" these to
> > > > > > > > > > > different names, so that there are no new CONFIG_ macros.  
> > > > > > > > > > 
> > > > > > > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a removal patch
> > > > > > > > > > soon, since they've been orphaned for a long while.  
> > > > > > > > > 
> > > > > > > > > Any progress on fixing this issue? Currently all this stuff is not
> > > > > > > > > working in u-boot master due to broken kconfig migration. And any
> > > > > > > > > continuation in kconfig migration just makes it worse and harder to fix
> > > > > > > > > later.  
> > > > > > > > 
> > > > > > > > I've removed the corenet_ds platforms now.  
> > > > > > > 
> > > > > > > I'm reminding this issue again. u-boot master branch is still broken.  
> > > > > > 
> > > > > > I don't really remember what the fix was at this point, but you should
> > > > > > fix whatever boards you have and care about as it's a matter of
> > > > > > selecting the correct option, yes?  
> > > > > 
> > > > > See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pali/
> > > > > Broken is Kconfig migration which you done. I wrote in that email simple
> > > > > test case how to check if it is OK or not.  
> > > > 
> > > > Yes, but I'm not un-migrating the symbol. As I think you're the only
> > > > person who cares about mpc85xx platforms right now, is your platform
> > > > working, or is there something that needs to be changed so that it does
> > > > work?
> > > > 
> > > 
> > > He's not the only one. I am still rebasing Pali's patches on top of
> > > current master. Please give me some more time.
> > 
> > Gentle reminder.
> 
> What is the state?

PING?

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Marek Behún]

On Fri, 16 Dec 2022 19:01:00 +0100
Pali Rohár <pali@kernel.org> wrote:

> PING?

I didn't forget and it's the first thing on my todo once I have time
for work. I am having a hiatus from work because of school stuff, I will
start working on this immediately after I return (which will be in
February at the latest).

Since I know how much this frustrates you, I am sorry. But I did not
forget about this, your work won't be thrown away.

Marek

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> that all kconfig migration changes done after that commit are broken.
> 
> I really do not have energy to investigate what and how was broken due
> to incorrect kconfig migration.
> 
> 
> I did simple test. Applied following change:
> 
> diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> index a6523753d5ca..489f24df0ab1 100644
> --- a/include/configs/p1_p2_rdb_pc.h
> +++ b/include/configs/p1_p2_rdb_pc.h
> @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
>  "bootm $norbootaddr - $norfdtaddr"
>  
>  #endif /* __CONFIG_H */
> +
> +#ifdef CONFIG_SDCARD
> +#error
> +#endif
> 
> And then called:
> 
> make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> 
> And it failed, even when this defconfig file is not SD card builds.

Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
Could you please look at it? Because it is a regressions which made P1
and P2 broken. Based on the past experience it really does not make
sense to wait for somebody who promised to do something as same
situation is just repeating.

Above diff is a simple check to verify if code conversion is correct or
not. If _before_ conversion CONFIG_SDCARD was not defined then also
_after_ conversion this macro must not be defined. Right?

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3851 bytes --]

On Fri, Dec 16, 2022 at 10:56:39PM +0100, Pali Rohár wrote:
> On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > that all kconfig migration changes done after that commit are broken.
> > 
> > I really do not have energy to investigate what and how was broken due
> > to incorrect kconfig migration.
> > 
> > 
> > I did simple test. Applied following change:
> > 
> > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > index a6523753d5ca..489f24df0ab1 100644
> > --- a/include/configs/p1_p2_rdb_pc.h
> > +++ b/include/configs/p1_p2_rdb_pc.h
> > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> >  "bootm $norbootaddr - $norfdtaddr"
> >  
> >  #endif /* __CONFIG_H */
> > +
> > +#ifdef CONFIG_SDCARD
> > +#error
> > +#endif
> > 
> > And then called:
> > 
> > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > 
> > And it failed, even when this defconfig file is not SD card builds.
> 
> Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
> Could you please look at it? Because it is a regressions which made P1
> and P2 broken. Based on the past experience it really does not make
> sense to wait for somebody who promised to do something as same
> situation is just repeating.
> 
> Above diff is a simple check to verify if code conversion is correct or
> not. If _before_ conversion CONFIG_SDCARD was not defined then also
> _after_ conversion this macro must not be defined. Right?

I dug through all of this again. I thought I understood what the right
answer was again for a moment, but I don't. You, however, understand
what platforms don't use PBL and what they use instead. I understand
half of the fix, which is to change:
choice
        prompt "Freescale PBL load location"
        depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
                || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
                && !CMD_NAND)

To, I think:
choice
        prompt "Freescale PBL load location"
        depends on RAMBOOT_PBL

Then introduce some new, not "SDCARD" symbol, for the P1/P2 platforms
that don't use PBL but instead the FSL_PREPBL_ESDHC_BOOT_SECTOR logic
you introduced before.

I say I almost thought I had it because I thought this would work:
diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 24d3f1f20c25..59740b173b11 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -15,7 +15,7 @@ config CMD_ERRATA
 config FSL_PREPBL_ESDHC_BOOT_SECTOR
 	bool "Generate QorIQ pre-PBL eSDHC boot sector"
 	depends on MPC85xx
-	depends on SDCARD
+	depends on TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB
 	help
 	  With this option final image would have prepended QorIQ pre-PBL eSDHC
 	  boot sector suitable for SD card images. This boot sector instruct
diff --git a/boot/Kconfig b/boot/Kconfig
index 4a001bcee851..d1c9c5f25067 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -725,8 +725,7 @@ config RAMBOOT_PBL
 
 choice
 	prompt "Freescale PBL load location"
-	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
-		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
+	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB) \
 		&& !CMD_NAND)
 
 config SDCARD

But no one enables CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR. But maybe that
just needs to be enabled on the platforms in question, and then the
first dependency change above is just dropping the SDCARD line? I really
don't know, and I'd be equally happy to just remove all of the P1*/P2*
boards if they don't boot and no one cares to fix them.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Wednesday 21 December 2022 21:54:15 Tom Rini wrote:
> On Fri, Dec 16, 2022 at 10:56:39PM +0100, Pali Rohár wrote:
> > On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > that all kconfig migration changes done after that commit are broken.
> > > 
> > > I really do not have energy to investigate what and how was broken due
> > > to incorrect kconfig migration.
> > > 
> > > 
> > > I did simple test. Applied following change:
> > > 
> > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > index a6523753d5ca..489f24df0ab1 100644
> > > --- a/include/configs/p1_p2_rdb_pc.h
> > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > >  "bootm $norbootaddr - $norfdtaddr"
> > >  
> > >  #endif /* __CONFIG_H */
> > > +
> > > +#ifdef CONFIG_SDCARD
> > > +#error
> > > +#endif
> > > 
> > > And then called:
> > > 
> > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > 
> > > And it failed, even when this defconfig file is not SD card builds.
> > 
> > Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
> > Could you please look at it? Because it is a regressions which made P1
> > and P2 broken. Based on the past experience it really does not make
> > sense to wait for somebody who promised to do something as same
> > situation is just repeating.
> > 
> > Above diff is a simple check to verify if code conversion is correct or
> > not. If _before_ conversion CONFIG_SDCARD was not defined then also
> > _after_ conversion this macro must not be defined. Right?
> 
> I dug through all of this again. I thought I understood what the right
> answer was again for a moment, but I don't. You, however, understand
> what platforms don't use PBL and what they use instead. I understand
> half of the fix, which is to change:
> choice
>         prompt "Freescale PBL load location"
>         depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
>                 || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
>                 && !CMD_NAND)
> 
> To, I think:
> choice
>         prompt "Freescale PBL load location"
>         depends on RAMBOOT_PBL
> 
> Then introduce some new, not "SDCARD" symbol, for the P1/P2 platforms
> that don't use PBL but instead the FSL_PREPBL_ESDHC_BOOT_SECTOR logic
> you introduced before.

P2020RDB-PC_defconfig is for booting from FLASH NOR, not from SD card.
CONFIG_SDCARD for P1/P2 must be defined when booting from SD card.

Before commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 everything worked
fine and CONFIG_SDCARD was not defined for P2020RDB-PC_defconfig. After
commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2, symbol CONFIG_SDCARD is
defined.

You can check it by adding into config.h:

+#ifdef CONFIG_SDCARD
+#error
+#endif

> I say I almost thought I had it because I thought this would work:
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 24d3f1f20c25..59740b173b11 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -15,7 +15,7 @@ config CMD_ERRATA
>  config FSL_PREPBL_ESDHC_BOOT_SECTOR
>  	bool "Generate QorIQ pre-PBL eSDHC boot sector"
>  	depends on MPC85xx
> -	depends on SDCARD
> +	depends on TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB

No, original code was OK. As is written in description
FSL_PREPBL_ESDHC_BOOT_SECTOR is for writing bootsector to SD card. And
it is optional as there is other way how to generate it, as described in
some doc/ file.

But if you choose to compile u-boot for P2020RDB-PC_defconfig (NOR
FLASH) then there is no SD card booting and hence
FSL_PREPBL_ESDHC_BOOT_SECTOR for P2020RDB-PC_defconfig must never be
generated. So FSL_PREPBL_ESDHC_BOOT_SECTOR must depends on SDCARD.

>  	help
>  	  With this option final image would have prepended QorIQ pre-PBL eSDHC
>  	  boot sector suitable for SD card images. This boot sector instruct
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 4a001bcee851..d1c9c5f25067 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -725,8 +725,7 @@ config RAMBOOT_PBL
>  
>  choice
>  	prompt "Freescale PBL load location"
> -	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> -		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> +	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB) \
>  		&& !CMD_NAND)
>  
>  config SDCARD
> 
> But no one enables CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR.

It is optional _user_ symbol. During compilation of sd card version of
u-boot, user can enable it.

For turris 1.x board there is waiting patch on the list which uses it.
No review yet?

> But maybe that
> just needs to be enabled on the platforms in question, and then the
> first dependency change above is just dropping the SDCARD line? I really
> don't know, and I'd be equally happy to just remove all of the P1*/P2*
> boards if they don't boot and no one cares to fix them.
> 
> -- 
> Tom

Just fix the conversion process. The rule is simple: if config.h did
not have enabled CONFIG_SDCARD then after conversion config.h must not
have it enabled.

Compare git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2~1
and git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

Because it worked fine before commit
d433c74eecdce1e4952ef4e8c712a9289c0dfcc2.

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6533 bytes --]

On Thu, Dec 22, 2022 at 08:49:47AM +0100, Pali Rohár wrote:
> On Wednesday 21 December 2022 21:54:15 Tom Rini wrote:
> > On Fri, Dec 16, 2022 at 10:56:39PM +0100, Pali Rohár wrote:
> > > On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > that all kconfig migration changes done after that commit are broken.
> > > > 
> > > > I really do not have energy to investigate what and how was broken due
> > > > to incorrect kconfig migration.
> > > > 
> > > > 
> > > > I did simple test. Applied following change:
> > > > 
> > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > index a6523753d5ca..489f24df0ab1 100644
> > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > >  "bootm $norbootaddr - $norfdtaddr"
> > > >  
> > > >  #endif /* __CONFIG_H */
> > > > +
> > > > +#ifdef CONFIG_SDCARD
> > > > +#error
> > > > +#endif
> > > > 
> > > > And then called:
> > > > 
> > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > 
> > > > And it failed, even when this defconfig file is not SD card builds.
> > > 
> > > Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
> > > Could you please look at it? Because it is a regressions which made P1
> > > and P2 broken. Based on the past experience it really does not make
> > > sense to wait for somebody who promised to do something as same
> > > situation is just repeating.
> > > 
> > > Above diff is a simple check to verify if code conversion is correct or
> > > not. If _before_ conversion CONFIG_SDCARD was not defined then also
> > > _after_ conversion this macro must not be defined. Right?
> > 
> > I dug through all of this again. I thought I understood what the right
> > answer was again for a moment, but I don't. You, however, understand
> > what platforms don't use PBL and what they use instead. I understand
> > half of the fix, which is to change:
> > choice
> >         prompt "Freescale PBL load location"
> >         depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> >                 || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> >                 && !CMD_NAND)
> > 
> > To, I think:
> > choice
> >         prompt "Freescale PBL load location"
> >         depends on RAMBOOT_PBL
> > 
> > Then introduce some new, not "SDCARD" symbol, for the P1/P2 platforms
> > that don't use PBL but instead the FSL_PREPBL_ESDHC_BOOT_SECTOR logic
> > you introduced before.
> 
> P2020RDB-PC_defconfig is for booting from FLASH NOR, not from SD card.
> CONFIG_SDCARD for P1/P2 must be defined when booting from SD card.
> 
> Before commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 everything worked
> fine and CONFIG_SDCARD was not defined for P2020RDB-PC_defconfig. After
> commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2, symbol CONFIG_SDCARD is
> defined.
> 
> You can check it by adding into config.h:
> 
> +#ifdef CONFIG_SDCARD
> +#error
> +#endif
> 
> > I say I almost thought I had it because I thought this would work:
> > diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> > index 24d3f1f20c25..59740b173b11 100644
> > --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> > +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> > @@ -15,7 +15,7 @@ config CMD_ERRATA
> >  config FSL_PREPBL_ESDHC_BOOT_SECTOR
> >  	bool "Generate QorIQ pre-PBL eSDHC boot sector"
> >  	depends on MPC85xx
> > -	depends on SDCARD
> > +	depends on TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB
> 
> No, original code was OK. As is written in description
> FSL_PREPBL_ESDHC_BOOT_SECTOR is for writing bootsector to SD card. And
> it is optional as there is other way how to generate it, as described in
> some doc/ file.
> 
> But if you choose to compile u-boot for P2020RDB-PC_defconfig (NOR
> FLASH) then there is no SD card booting and hence
> FSL_PREPBL_ESDHC_BOOT_SECTOR for P2020RDB-PC_defconfig must never be
> generated. So FSL_PREPBL_ESDHC_BOOT_SECTOR must depends on SDCARD.
> 
> >  	help
> >  	  With this option final image would have prepended QorIQ pre-PBL eSDHC
> >  	  boot sector suitable for SD card images. This boot sector instruct
> > diff --git a/boot/Kconfig b/boot/Kconfig
> > index 4a001bcee851..d1c9c5f25067 100644
> > --- a/boot/Kconfig
> > +++ b/boot/Kconfig
> > @@ -725,8 +725,7 @@ config RAMBOOT_PBL
> >  
> >  choice
> >  	prompt "Freescale PBL load location"
> > -	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > -		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > +	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB) \
> >  		&& !CMD_NAND)
> >  
> >  config SDCARD
> > 
> > But no one enables CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR.
> 
> It is optional _user_ symbol. During compilation of sd card version of
> u-boot, user can enable it.
> 
> For turris 1.x board there is waiting patch on the list which uses it.
> No review yet?
> 
> > But maybe that
> > just needs to be enabled on the platforms in question, and then the
> > first dependency change above is just dropping the SDCARD line? I really
> > don't know, and I'd be equally happy to just remove all of the P1*/P2*
> > boards if they don't boot and no one cares to fix them.
> > 
> > -- 
> > Tom
> 
> Just fix the conversion process. The rule is simple: if config.h did
> not have enabled CONFIG_SDCARD then after conversion config.h must not
> have it enabled.
> 
> Compare git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2~1
> and git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2
> 
> Because it worked fine before commit
> d433c74eecdce1e4952ef4e8c712a9289c0dfcc2.

Thanks for explaining. Since you clearly understand what it should do,
and I do not, please submit something to implement the correct questions
in Kconfig. There was some overloading of a symbol before which I didn't
understand, and still don't exactly. Otherwise, since I believe you're
saying the Turris platform is fine, once Marek merges it (you will
likely need to rebase on next, next week, once I finish merging all of
the CONFIG migration stuff), I'll just delete the P1/P2 platforms
sometime in the next release if no one actually cares to fix them.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Thursday 22 December 2022 09:29:27 Tom Rini wrote:
> On Thu, Dec 22, 2022 at 08:49:47AM +0100, Pali Rohár wrote:
> > On Wednesday 21 December 2022 21:54:15 Tom Rini wrote:
> > > On Fri, Dec 16, 2022 at 10:56:39PM +0100, Pali Rohár wrote:
> > > > On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > that all kconfig migration changes done after that commit are broken.
> > > > > 
> > > > > I really do not have energy to investigate what and how was broken due
> > > > > to incorrect kconfig migration.
> > > > > 
> > > > > 
> > > > > I did simple test. Applied following change:
> > > > > 
> > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > >  
> > > > >  #endif /* __CONFIG_H */
> > > > > +
> > > > > +#ifdef CONFIG_SDCARD
> > > > > +#error
> > > > > +#endif
> > > > > 
> > > > > And then called:
> > > > > 
> > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > 
> > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > 
> > > > Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
> > > > Could you please look at it? Because it is a regressions which made P1
> > > > and P2 broken. Based on the past experience it really does not make
> > > > sense to wait for somebody who promised to do something as same
> > > > situation is just repeating.
> > > > 
> > > > Above diff is a simple check to verify if code conversion is correct or
> > > > not. If _before_ conversion CONFIG_SDCARD was not defined then also
> > > > _after_ conversion this macro must not be defined. Right?
> > > 
> > > I dug through all of this again. I thought I understood what the right
> > > answer was again for a moment, but I don't. You, however, understand
> > > what platforms don't use PBL and what they use instead. I understand
> > > half of the fix, which is to change:
> > > choice
> > >         prompt "Freescale PBL load location"
> > >         depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > >                 || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > >                 && !CMD_NAND)
> > > 
> > > To, I think:
> > > choice
> > >         prompt "Freescale PBL load location"
> > >         depends on RAMBOOT_PBL
> > > 
> > > Then introduce some new, not "SDCARD" symbol, for the P1/P2 platforms
> > > that don't use PBL but instead the FSL_PREPBL_ESDHC_BOOT_SECTOR logic
> > > you introduced before.
> > 
> > P2020RDB-PC_defconfig is for booting from FLASH NOR, not from SD card.
> > CONFIG_SDCARD for P1/P2 must be defined when booting from SD card.
> > 
> > Before commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 everything worked
> > fine and CONFIG_SDCARD was not defined for P2020RDB-PC_defconfig. After
> > commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2, symbol CONFIG_SDCARD is
> > defined.
> > 
> > You can check it by adding into config.h:
> > 
> > +#ifdef CONFIG_SDCARD
> > +#error
> > +#endif
> > 
> > > I say I almost thought I had it because I thought this would work:
> > > diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > index 24d3f1f20c25..59740b173b11 100644
> > > --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> > > +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > @@ -15,7 +15,7 @@ config CMD_ERRATA
> > >  config FSL_PREPBL_ESDHC_BOOT_SECTOR
> > >  	bool "Generate QorIQ pre-PBL eSDHC boot sector"
> > >  	depends on MPC85xx
> > > -	depends on SDCARD
> > > +	depends on TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB
> > 
> > No, original code was OK. As is written in description
> > FSL_PREPBL_ESDHC_BOOT_SECTOR is for writing bootsector to SD card. And
> > it is optional as there is other way how to generate it, as described in
> > some doc/ file.
> > 
> > But if you choose to compile u-boot for P2020RDB-PC_defconfig (NOR
> > FLASH) then there is no SD card booting and hence
> > FSL_PREPBL_ESDHC_BOOT_SECTOR for P2020RDB-PC_defconfig must never be
> > generated. So FSL_PREPBL_ESDHC_BOOT_SECTOR must depends on SDCARD.
> > 
> > >  	help
> > >  	  With this option final image would have prepended QorIQ pre-PBL eSDHC
> > >  	  boot sector suitable for SD card images. This boot sector instruct
> > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > index 4a001bcee851..d1c9c5f25067 100644
> > > --- a/boot/Kconfig
> > > +++ b/boot/Kconfig
> > > @@ -725,8 +725,7 @@ config RAMBOOT_PBL
> > >  
> > >  choice
> > >  	prompt "Freescale PBL load location"
> > > -	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > > -		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > > +	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB) \
> > >  		&& !CMD_NAND)
> > >  
> > >  config SDCARD
> > > 
> > > But no one enables CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > 
> > It is optional _user_ symbol. During compilation of sd card version of
> > u-boot, user can enable it.
> > 
> > For turris 1.x board there is waiting patch on the list which uses it.
> > No review yet?
> > 
> > > But maybe that
> > > just needs to be enabled on the platforms in question, and then the
> > > first dependency change above is just dropping the SDCARD line? I really
> > > don't know, and I'd be equally happy to just remove all of the P1*/P2*
> > > boards if they don't boot and no one cares to fix them.
> > > 
> > > -- 
> > > Tom
> > 
> > Just fix the conversion process. The rule is simple: if config.h did
> > not have enabled CONFIG_SDCARD then after conversion config.h must not
> > have it enabled.
> > 
> > Compare git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2~1
> > and git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2
> > 
> > Because it worked fine before commit
> > d433c74eecdce1e4952ef4e8c712a9289c0dfcc2.
> 
> Thanks for explaining. Since you clearly understand what it should do,
> and I do not, please submit something to implement the correct questions
> in Kconfig. There was some overloading of a symbol before which I didn't
> understand, and still don't exactly. Otherwise, since I believe you're
> saying the Turris platform is fine, once Marek merges it (you will
> likely need to rebase on next, next week, once I finish merging all of
> the CONFIG migration stuff), I'll just delete the P1/P2 platforms
> sometime in the next release if no one actually cares to fix them.
> 
> -- 
> Tom

In lot of projects it is common that developer who introduced broken
commit, is responsible to either fix it or revert it. I really do not
have a time and power to fix every one broken commit behind every one
developer. I sent lot of other fixes and in this case I at least wrote
what is broken. Moreover it my was not my decision to use Kconfig for
this stuff, which is unsuitable tool here. So do not take me wrong but I
do not have motivation to fight with another tool for things for which
it was not designed and try to hunt bugs in it.

It should have been pretty simple migration from tool A to tool B as it
does not introduce any new feature nor code change. It should produce
same u-boot.bin binary before and after change. And also it is not
needed to fully understand what which option means. And if binaries are
not same then conversion was wrong. No need for HW, just compiling and
unit testing.

I have rebased turris 1.x patches at least 3 times. This is not enough??
Why should I rebase it again? Note that it depends on P1/P2 because
turris 1.x is based on P2.

Also I have sent tons of patches and fixes for P1/P2 platforms and the
only thing which you are going to do is to delete this platform?

You should have wrote this statement year ago and I would never take
care of P1/P2 and fixing it. This is absolutely rude decision to show
active developers: go away, we do not care about you, your time and your
contributions.

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 10076 bytes --]

On Thu, Dec 22, 2022 at 06:13:06PM +0100, Pali Rohár wrote:
> On Thursday 22 December 2022 09:29:27 Tom Rini wrote:
> > On Thu, Dec 22, 2022 at 08:49:47AM +0100, Pali Rohár wrote:
> > > On Wednesday 21 December 2022 21:54:15 Tom Rini wrote:
> > > > On Fri, Dec 16, 2022 at 10:56:39PM +0100, Pali Rohár wrote:
> > > > > On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > > 
> > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > to incorrect kconfig migration.
> > > > > > 
> > > > > > 
> > > > > > I did simple test. Applied following change:
> > > > > > 
> > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > >  
> > > > > >  #endif /* __CONFIG_H */
> > > > > > +
> > > > > > +#ifdef CONFIG_SDCARD
> > > > > > +#error
> > > > > > +#endif
> > > > > > 
> > > > > > And then called:
> > > > > > 
> > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > > 
> > > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > > 
> > > > > Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
> > > > > Could you please look at it? Because it is a regressions which made P1
> > > > > and P2 broken. Based on the past experience it really does not make
> > > > > sense to wait for somebody who promised to do something as same
> > > > > situation is just repeating.
> > > > > 
> > > > > Above diff is a simple check to verify if code conversion is correct or
> > > > > not. If _before_ conversion CONFIG_SDCARD was not defined then also
> > > > > _after_ conversion this macro must not be defined. Right?
> > > > 
> > > > I dug through all of this again. I thought I understood what the right
> > > > answer was again for a moment, but I don't. You, however, understand
> > > > what platforms don't use PBL and what they use instead. I understand
> > > > half of the fix, which is to change:
> > > > choice
> > > >         prompt "Freescale PBL load location"
> > > >         depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > > >                 || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > > >                 && !CMD_NAND)
> > > > 
> > > > To, I think:
> > > > choice
> > > >         prompt "Freescale PBL load location"
> > > >         depends on RAMBOOT_PBL
> > > > 
> > > > Then introduce some new, not "SDCARD" symbol, for the P1/P2 platforms
> > > > that don't use PBL but instead the FSL_PREPBL_ESDHC_BOOT_SECTOR logic
> > > > you introduced before.
> > > 
> > > P2020RDB-PC_defconfig is for booting from FLASH NOR, not from SD card.
> > > CONFIG_SDCARD for P1/P2 must be defined when booting from SD card.
> > > 
> > > Before commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 everything worked
> > > fine and CONFIG_SDCARD was not defined for P2020RDB-PC_defconfig. After
> > > commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2, symbol CONFIG_SDCARD is
> > > defined.
> > > 
> > > You can check it by adding into config.h:
> > > 
> > > +#ifdef CONFIG_SDCARD
> > > +#error
> > > +#endif
> > > 
> > > > I say I almost thought I had it because I thought this would work:
> > > > diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > > index 24d3f1f20c25..59740b173b11 100644
> > > > --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> > > > +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > > @@ -15,7 +15,7 @@ config CMD_ERRATA
> > > >  config FSL_PREPBL_ESDHC_BOOT_SECTOR
> > > >  	bool "Generate QorIQ pre-PBL eSDHC boot sector"
> > > >  	depends on MPC85xx
> > > > -	depends on SDCARD
> > > > +	depends on TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB
> > > 
> > > No, original code was OK. As is written in description
> > > FSL_PREPBL_ESDHC_BOOT_SECTOR is for writing bootsector to SD card. And
> > > it is optional as there is other way how to generate it, as described in
> > > some doc/ file.
> > > 
> > > But if you choose to compile u-boot for P2020RDB-PC_defconfig (NOR
> > > FLASH) then there is no SD card booting and hence
> > > FSL_PREPBL_ESDHC_BOOT_SECTOR for P2020RDB-PC_defconfig must never be
> > > generated. So FSL_PREPBL_ESDHC_BOOT_SECTOR must depends on SDCARD.
> > > 
> > > >  	help
> > > >  	  With this option final image would have prepended QorIQ pre-PBL eSDHC
> > > >  	  boot sector suitable for SD card images. This boot sector instruct
> > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > index 4a001bcee851..d1c9c5f25067 100644
> > > > --- a/boot/Kconfig
> > > > +++ b/boot/Kconfig
> > > > @@ -725,8 +725,7 @@ config RAMBOOT_PBL
> > > >  
> > > >  choice
> > > >  	prompt "Freescale PBL load location"
> > > > -	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > > > -		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > > > +	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB) \
> > > >  		&& !CMD_NAND)
> > > >  
> > > >  config SDCARD
> > > > 
> > > > But no one enables CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > > 
> > > It is optional _user_ symbol. During compilation of sd card version of
> > > u-boot, user can enable it.
> > > 
> > > For turris 1.x board there is waiting patch on the list which uses it.
> > > No review yet?
> > > 
> > > > But maybe that
> > > > just needs to be enabled on the platforms in question, and then the
> > > > first dependency change above is just dropping the SDCARD line? I really
> > > > don't know, and I'd be equally happy to just remove all of the P1*/P2*
> > > > boards if they don't boot and no one cares to fix them.
> > > > 
> > > > -- 
> > > > Tom
> > > 
> > > Just fix the conversion process. The rule is simple: if config.h did
> > > not have enabled CONFIG_SDCARD then after conversion config.h must not
> > > have it enabled.
> > > 
> > > Compare git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2~1
> > > and git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2
> > > 
> > > Because it worked fine before commit
> > > d433c74eecdce1e4952ef4e8c712a9289c0dfcc2.
> > 
> > Thanks for explaining. Since you clearly understand what it should do,
> > and I do not, please submit something to implement the correct questions
> > in Kconfig. There was some overloading of a symbol before which I didn't
> > understand, and still don't exactly. Otherwise, since I believe you're
> > saying the Turris platform is fine, once Marek merges it (you will
> > likely need to rebase on next, next week, once I finish merging all of
> > the CONFIG migration stuff), I'll just delete the P1/P2 platforms
> > sometime in the next release if no one actually cares to fix them.
> > 
> > -- 
> > Tom
> 
> In lot of projects it is common that developer who introduced broken
> commit, is responsible to either fix it or revert it. I really do not
> have a time and power to fix every one broken commit behind every one
> developer. I sent lot of other fixes and in this case I at least wrote
> what is broken. Moreover it my was not my decision to use Kconfig for
> this stuff, which is unsuitable tool here. So do not take me wrong but I
> do not have motivation to fight with another tool for things for which
> it was not designed and try to hunt bugs in it.
> 
> It should have been pretty simple migration from tool A to tool B as it
> does not introduce any new feature nor code change. It should produce
> same u-boot.bin binary before and after change. And also it is not
> needed to fully understand what which option means. And if binaries are
> not same then conversion was wrong. No need for HW, just compiling and
> unit testing.
> 
> I have rebased turris 1.x patches at least 3 times. This is not enough??
> Why should I rebase it again? Note that it depends on P1/P2 because
> turris 1.x is based on P2.
> 
> Also I have sent tons of patches and fixes for P1/P2 platforms and the
> only thing which you are going to do is to delete this platform?
> 
> You should have wrote this statement year ago and I would never take
> care of P1/P2 and fixing it. This is absolutely rude decision to show
> active developers: go away, we do not care about you, your time and your
> contributions.

Had I realized 10 years ago that Freescale was overloading CONFIG_SDCARD
they way they were, I'd have rejected the changes then. So yes, that's
on me. But this also wasn't a simple migration, or things wouldn't be
broken right now. That's part of the problem. And I can't functionally
test things. Which is why I've repeatedly asked if you can pick up and
"own" these parts of the system which you understand and can test, and I
cannot. At the time I likely figured the size change on a few platforms
was one of the cases where the migration fixed an inconsistency, rather
than breakage, as that has also happened as these changes go in.

I'm sorry you're frustrated here. I'm also frustrated here because the
#ifdef games that PowerPC used, in a number of places have been very
hard to un-wrap so that we can have something other than a home-grown
build system. And I've tried to take your other feedback in to
consideration, which has resulted in a large number of symbols being
moved to CFG_... instead of Kconfig, as you're right, it wasn't the
right mechanism for them.

So, is it really just the 3 platforms that use p1_p2_rdb.h that need
neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
Or is it the P1010RDB ones too?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Simon Glass]

Hi Pali,

On Thu, 22 Dec 2022 at 10:13, Pali Rohár <pali@kernel.org> wrote:
>
> On Thursday 22 December 2022 09:29:27 Tom Rini wrote:
> > On Thu, Dec 22, 2022 at 08:49:47AM +0100, Pali Rohár wrote:
> > > On Wednesday 21 December 2022 21:54:15 Tom Rini wrote:
> > > > On Fri, Dec 16, 2022 at 10:56:39PM +0100, Pali Rohár wrote:
> > > > > On Friday 05 August 2022 16:21:24 Pali Rohár wrote:
> > > > > > Broken is also commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2. Seems
> > > > > > that all kconfig migration changes done after that commit are broken.
> > > > > >
> > > > > > I really do not have energy to investigate what and how was broken due
> > > > > > to incorrect kconfig migration.
> > > > > >
> > > > > >
> > > > > > I did simple test. Applied following change:
> > > > > >
> > > > > > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > > > > > index a6523753d5ca..489f24df0ab1 100644
> > > > > > --- a/include/configs/p1_p2_rdb_pc.h
> > > > > > +++ b/include/configs/p1_p2_rdb_pc.h
> > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_RST_CMD)"\0"
> > > > > >  "bootm $norbootaddr - $norfdtaddr"
> > > > > >
> > > > > >  #endif /* __CONFIG_H */
> > > > > > +
> > > > > > +#ifdef CONFIG_SDCARD
> > > > > > +#error
> > > > > > +#endif
> > > > > >
> > > > > > And then called:
> > > > > >
> > > > > > make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig u-boot.bin
> > > > > >
> > > > > > And it failed, even when this defconfig file is not SD card builds.
> > > > >
> > > > > Tom, that commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 is yours.
> > > > > Could you please look at it? Because it is a regressions which made P1
> > > > > and P2 broken. Based on the past experience it really does not make
> > > > > sense to wait for somebody who promised to do something as same
> > > > > situation is just repeating.
> > > > >
> > > > > Above diff is a simple check to verify if code conversion is correct or
> > > > > not. If _before_ conversion CONFIG_SDCARD was not defined then also
> > > > > _after_ conversion this macro must not be defined. Right?
> > > >
> > > > I dug through all of this again. I thought I understood what the right
> > > > answer was again for a moment, but I don't. You, however, understand
> > > > what platforms don't use PBL and what they use instead. I understand
> > > > half of the fix, which is to change:
> > > > choice
> > > >         prompt "Freescale PBL load location"
> > > >         depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > > >                 || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > > >                 && !CMD_NAND)
> > > >
> > > > To, I think:
> > > > choice
> > > >         prompt "Freescale PBL load location"
> > > >         depends on RAMBOOT_PBL
> > > >
> > > > Then introduce some new, not "SDCARD" symbol, for the P1/P2 platforms
> > > > that don't use PBL but instead the FSL_PREPBL_ESDHC_BOOT_SECTOR logic
> > > > you introduced before.
> > >
> > > P2020RDB-PC_defconfig is for booting from FLASH NOR, not from SD card.
> > > CONFIG_SDCARD for P1/P2 must be defined when booting from SD card.
> > >
> > > Before commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 everything worked
> > > fine and CONFIG_SDCARD was not defined for P2020RDB-PC_defconfig. After
> > > commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2, symbol CONFIG_SDCARD is
> > > defined.
> > >
> > > You can check it by adding into config.h:
> > >
> > > +#ifdef CONFIG_SDCARD
> > > +#error
> > > +#endif
> > >
> > > > I say I almost thought I had it because I thought this would work:
> > > > diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > > index 24d3f1f20c25..59740b173b11 100644
> > > > --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> > > > +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > > @@ -15,7 +15,7 @@ config CMD_ERRATA
> > > >  config FSL_PREPBL_ESDHC_BOOT_SECTOR
> > > >   bool "Generate QorIQ pre-PBL eSDHC boot sector"
> > > >   depends on MPC85xx
> > > > - depends on SDCARD
> > > > + depends on TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB
> > >
> > > No, original code was OK. As is written in description
> > > FSL_PREPBL_ESDHC_BOOT_SECTOR is for writing bootsector to SD card. And
> > > it is optional as there is other way how to generate it, as described in
> > > some doc/ file.
> > >
> > > But if you choose to compile u-boot for P2020RDB-PC_defconfig (NOR
> > > FLASH) then there is no SD card booting and hence
> > > FSL_PREPBL_ESDHC_BOOT_SECTOR for P2020RDB-PC_defconfig must never be
> > > generated. So FSL_PREPBL_ESDHC_BOOT_SECTOR must depends on SDCARD.
> > >
> > > >   help
> > > >     With this option final image would have prepended QorIQ pre-PBL eSDHC
> > > >     boot sector suitable for SD card images. This boot sector instruct
> > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > index 4a001bcee851..d1c9c5f25067 100644
> > > > --- a/boot/Kconfig
> > > > +++ b/boot/Kconfig
> > > > @@ -725,8 +725,7 @@ config RAMBOOT_PBL
> > > >
> > > >  choice
> > > >   prompt "Freescale PBL load location"
> > > > - depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > > > -         || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > > > + depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB) \
> > > >           && !CMD_NAND)
> > > >
> > > >  config SDCARD
> > > >
> > > > But no one enables CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR.
> > >
> > > It is optional _user_ symbol. During compilation of sd card version of
> > > u-boot, user can enable it.
> > >
> > > For turris 1.x board there is waiting patch on the list which uses it.
> > > No review yet?
> > >
> > > > But maybe that
> > > > just needs to be enabled on the platforms in question, and then the
> > > > first dependency change above is just dropping the SDCARD line? I really
> > > > don't know, and I'd be equally happy to just remove all of the P1*/P2*
> > > > boards if they don't boot and no one cares to fix them.
> > > >
> > > > --
> > > > Tom
> > >
> > > Just fix the conversion process. The rule is simple: if config.h did
> > > not have enabled CONFIG_SDCARD then after conversion config.h must not
> > > have it enabled.
> > >
> > > Compare git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2~1
> > > and git checkout d433c74eecdce1e4952ef4e8c712a9289c0dfcc2
> > >
> > > Because it worked fine before commit
> > > d433c74eecdce1e4952ef4e8c712a9289c0dfcc2.
> >
> > Thanks for explaining. Since you clearly understand what it should do,
> > and I do not, please submit something to implement the correct questions
> > in Kconfig. There was some overloading of a symbol before which I didn't
> > understand, and still don't exactly. Otherwise, since I believe you're
> > saying the Turris platform is fine, once Marek merges it (you will
> > likely need to rebase on next, next week, once I finish merging all of
> > the CONFIG migration stuff), I'll just delete the P1/P2 platforms
> > sometime in the next release if no one actually cares to fix them.
> >
> > --
> > Tom
>
> In lot of projects it is common that developer who introduced broken
> commit, is responsible to either fix it or revert it. I really do not
> have a time and power to fix every one broken commit behind every one
> developer. I sent lot of other fixes and in this case I at least wrote
> what is broken. Moreover it my was not my decision to use Kconfig for
> this stuff, which is unsuitable tool here. So do not take me wrong but I
> do not have motivation to fight with another tool for things for which
> it was not designed and try to hunt bugs in it.
>
> It should have been pretty simple migration from tool A to tool B as it
> does not introduce any new feature nor code change. It should produce
> same u-boot.bin binary before and after change. And also it is not
> needed to fully understand what which option means. And if binaries are
> not same then conversion was wrong. No need for HW, just compiling and
> unit testing.
>
> I have rebased turris 1.x patches at least 3 times. This is not enough??
> Why should I rebase it again? Note that it depends on P1/P2 because
> turris 1.x is based on P2.
>
> Also I have sent tons of patches and fixes for P1/P2 platforms and the
> only thing which you are going to do is to delete this platform?
>
> You should have wrote this statement year ago and I would never take
> care of P1/P2 and fixing it. This is absolutely rude decision to show
> active developers: go away, we do not care about you, your time and your
> contributions.

I don't think it needs to be deleted, from my reading of what Tom said.

One thing to bear in mind is that the Kconfig migration has been going
on for 6 years and Tom has actually managed to complete it. It will be
a big win for the project. One thing that has made it so hard is that
some board maintainers have moved on and don't take notice of
migrations.

I know from bitter experience that converting to Kconfig and keeping
everything the same is extremely tricky. Buildman has a -K option to
show CONFIG differences largely for this reason. But in this case, we
need to move things to CFG_ also...so...it is not easy.

Regards,
Simon

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> I'm sorry you're frustrated here. I'm also frustrated here because the
> #ifdef games that PowerPC used, in a number of places have been very
> hard to un-wrap so that we can have something other than a home-grown
> build system.

I was already trying to reduce it too, some patches I sent, some other I
was preparing and some other are part of turris 1.x platform, which is
waiting there for 6 months. I planned to apply removal of MMC symbols to
other P1/P2 boards, like it is in turris patch, but after turris patch
is merged... which did not happen yet.

> And I've tried to take your other feedback in to
> consideration, which has resulted in a large number of symbols being
> moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> right mechanism for them.
> 
> So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> Or is it the P1010RDB ones too?

It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
predates P3 platform. If there are not some suspicious symbol names then
it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
ARCH_P2020 symbol.

P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
or e6500), so you can ignore these.

Is there any tool which can list all defconfig files which defines some
of those symbols, including transitionally?

It looks like that there are other boards just than P1010RDB which are
affected. For example I see there: TARGET_SOCRATES TARGET_QEMU_PPCE500.
Default boot source is FLASH and just few boards can have multiple boot
source (which means that have multiple defconfig files with those
suffixes). And obviously SD card boot source must not be enabled when
(default) FLASH is used.

Note that u-boot for qemu e500 board can be started in qemu and hence
tested if works without need a real HW. There is also documentation for
it, recently I sent a small doc patch.

Seems that similar CI test like test/nokia_rx51_test.sh could be useful
here.

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]

On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > I'm sorry you're frustrated here. I'm also frustrated here because the
> > #ifdef games that PowerPC used, in a number of places have been very
> > hard to un-wrap so that we can have something other than a home-grown
> > build system.
> 
> I was already trying to reduce it too, some patches I sent, some other I
> was preparing and some other are part of turris 1.x platform, which is
> waiting there for 6 months. I planned to apply removal of MMC symbols to
> other P1/P2 boards, like it is in turris patch, but after turris patch
> is merged... which did not happen yet.

Right, and thanks for what you've done already.

> > And I've tried to take your other feedback in to
> > consideration, which has resulted in a large number of symbols being
> > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > right mechanism for them.
> > 
> > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > Or is it the P1010RDB ones too?
> 
> It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> predates P3 platform. If there are not some suspicious symbol names then
> it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> ARCH_P2020 symbol.
> 
> P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> or e6500), so you can ignore these.

OK.

> Is there any tool which can list all defconfig files which defines some
> of those symbols, including transitionally?

With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
make a database that you can consult with -f. That takes both SYMBOL and
~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
And you can chain them together. For example:
$ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
8 matches
P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
$ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
8 matches
P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND

> It looks like that there are other boards just than P1010RDB which are
> affected. For example I see there: TARGET_SOCRATES TARGET_QEMU_PPCE500.
> Default boot source is FLASH and just few boards can have multiple boot
> source (which means that have multiple defconfig files with those
> suffixes). And obviously SD card boot source must not be enabled when
> (default) FLASH is used.
> 
> Note that u-boot for qemu e500 board can be started in qemu and hence
> tested if works without need a real HW. There is also documentation for
> it, recently I sent a small doc patch.
> 
> Seems that similar CI test like test/nokia_rx51_test.sh could be useful
> here.

Note that we run qemu-ppce500 as part of CI normally. What makes
nokia_rx51 special is (a) the specific QEMU required and then (b) the
Linux boot testing.  qemu-ppce500 starts up and runs our pytests only.
Any updates to doc/board/emulation/qemu-ppce500.rst with more useful
information would of course be appreciated too.  We configure how qemu
is fired off here is
https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-ppce500_na
and I suspect that how we fire up QEMU means that the issue you're
noting isn't triggered since we don't boot it from flash but instead
pass the binary.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> I suspect that how we fire up QEMU means that the issue you're
> noting isn't triggered since we don't boot it from flash but instead
> pass the binary.

Yes, this sounds like that problematic part is not tested. To spot this
issue some end-to-end test is needed... For flash setup - booting
directly from the qemu flash (execute in place) without initialized RAM
and letting u-boot to do it. For SD card setup - booting via BootROM
(like it is on the real HW). Seems that SD card BootROM is not available
on internet and no idea if it can be dumped from some Freescale CPU (it
is even legal to do it?). So some alternative bootrom implementation for
such testing is needed... which is lot of work.

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Thu, Dec 22, 2022 at 10:02:42PM +0100, Pali Rohár wrote:
> On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > I suspect that how we fire up QEMU means that the issue you're
> > noting isn't triggered since we don't boot it from flash but instead
> > pass the binary.
> 
> Yes, this sounds like that problematic part is not tested. To spot this
> issue some end-to-end test is needed... For flash setup - booting
> directly from the qemu flash (execute in place) without initialized RAM
> and letting u-boot to do it. For SD card setup - booting via BootROM
> (like it is on the real HW). Seems that SD card BootROM is not available
> on internet and no idea if it can be dumped from some Freescale CPU (it
> is even legal to do it?). So some alternative bootrom implementation for
> such testing is needed... which is lot of work.

We do some things like this already, for other QEMU platforms (the
flash_impl variable is set to the shell script to create a flash image)
but, it's unlikely to be worth expending the effort here, the ROM QEMU
uses here isn't the Freescale one, but from openhackware.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > #ifdef games that PowerPC used, in a number of places have been very
> > > hard to un-wrap so that we can have something other than a home-grown
> > > build system.
> > 
> > I was already trying to reduce it too, some patches I sent, some other I
> > was preparing and some other are part of turris 1.x platform, which is
> > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > other P1/P2 boards, like it is in turris patch, but after turris patch
> > is merged... which did not happen yet.
> 
> Right, and thanks for what you've done already.
> 
> > > And I've tried to take your other feedback in to
> > > consideration, which has resulted in a large number of symbols being
> > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > right mechanism for them.
> > > 
> > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > Or is it the P1010RDB ones too?
> > 
> > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > predates P3 platform. If there are not some suspicious symbol names then
> > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > ARCH_P2020 symbol.
> > 
> > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > or e6500), so you can ignore these.
> 
> OK.
> 
> > Is there any tool which can list all defconfig files which defines some
> > of those symbols, including transitionally?
> 
> With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> make a database that you can consult with -f. That takes both SYMBOL and
> ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> And you can chain them together. For example:
> $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> 8 matches
> P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> 8 matches
> P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND

Ok, I tried to build database and list of the affected defconfig files:
(all except T, P3+ and P204x)

$ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC

So it means that these defconfigs are broken and CONFIG_SDCARD for them
must be turned off:

P1010RDB-PB_36BIT_NOR
P1010RDB-PB_NOR
P1010RDB-PA_36BIT_NOR
P1010RDB-PA_NOR
P1020RDB-PC
P1020RDB-PC_36BIT
P1020RDB-PD
P2020RDB-PC_36BIT
P2020RDB-PC


These defconfigs have already CONFIG_SDCARD turned off:

$ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
socrates
MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
qemu-ppce500

And seems that no of them is sd card related (hopefully).

> > It looks like that there are other boards just than P1010RDB which are
> > affected. For example I see there: TARGET_SOCRATES TARGET_QEMU_PPCE500.
> > Default boot source is FLASH and just few boards can have multiple boot
> > source (which means that have multiple defconfig files with those
> > suffixes). And obviously SD card boot source must not be enabled when
> > (default) FLASH is used.
> > 
> > Note that u-boot for qemu e500 board can be started in qemu and hence
> > tested if works without need a real HW. There is also documentation for
> > it, recently I sent a small doc patch.
> > 
> > Seems that similar CI test like test/nokia_rx51_test.sh could be useful
> > here.
> 
> Note that we run qemu-ppce500 as part of CI normally. What makes
> nokia_rx51 special is (a) the specific QEMU required and then (b) the
> Linux boot testing.  qemu-ppce500 starts up and runs our pytests only.
> Any updates to doc/board/emulation/qemu-ppce500.rst with more useful
> information would of course be appreciated too.  We configure how qemu
> is fired off here is
> https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.qemu-ppce500_na
> and I suspect that how we fire up QEMU means that the issue you're
> noting isn't triggered since we don't boot it from flash but instead
> pass the binary.
> 
> -- 
> Tom

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 11430 bytes --]

On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Rohár wrote:
> On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > > #ifdef games that PowerPC used, in a number of places have been very
> > > > hard to un-wrap so that we can have something other than a home-grown
> > > > build system.
> > > 
> > > I was already trying to reduce it too, some patches I sent, some other I
> > > was preparing and some other are part of turris 1.x platform, which is
> > > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > > other P1/P2 boards, like it is in turris patch, but after turris patch
> > > is merged... which did not happen yet.
> > 
> > Right, and thanks for what you've done already.
> > 
> > > > And I've tried to take your other feedback in to
> > > > consideration, which has resulted in a large number of symbols being
> > > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > > right mechanism for them.
> > > > 
> > > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > > Or is it the P1010RDB ones too?
> > > 
> > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > > predates P3 platform. If there are not some suspicious symbol names then
> > > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > > ARCH_P2020 symbol.
> > > 
> > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > > or e6500), so you can ignore these.
> > 
> > OK.
> > 
> > > Is there any tool which can list all defconfig files which defines some
> > > of those symbols, including transitionally?
> > 
> > With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> > make a database that you can consult with -f. That takes both SYMBOL and
> > ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> > And you can chain them together. For example:
> > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> > 8 matches
> > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> > 8 matches
> > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND
> 
> Ok, I tried to build database and list of the affected defconfig files:
> (all except T, P3+ and P204x)
> 
> $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
> P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
> P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
> P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC
> 
> So it means that these defconfigs are broken and CONFIG_SDCARD for them
> must be turned off:
> 
> P1010RDB-PB_36BIT_NOR
> P1010RDB-PB_NOR
> P1010RDB-PA_36BIT_NOR
> P1010RDB-PA_NOR
> P1020RDB-PC
> P1020RDB-PC_36BIT
> P1020RDB-PD
> P2020RDB-PC_36BIT
> P2020RDB-PC
> 
> 
> These defconfigs have already CONFIG_SDCARD turned off:
> 
> $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
> socrates
> MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
> P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
> P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
> P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
> qemu-ppce500
> 
> And seems that no of them is sd card related (hopefully).

Thanks!  Does the following look reasonable to you
(CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll
make a proper patch next:


diff --git a/boot/Kconfig b/boot/Kconfig
index 4a001bcee851..424ad0e466da 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -724,16 +724,19 @@ config RAMBOOT_PBL
 	  For more details refer to doc/README.pblimage
 
 choice
-	prompt "Freescale PBL load location"
+	prompt "Freescale PBL (or predecessor) load location"
 	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
 		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
 		&& !CMD_NAND)
 
 config SDCARD
-	bool "Freescale PBL is found on SD card"
+	bool "Freescale PBL (or similar) is found on SD card"
 
 config SPIFLASH
-	bool "Freescale PBL is found on SPI flash"
+	bool "Freescale PBL (or similar) is found on SPI flash"
+
+config NO_PBL
+	bool "Freescale PBL (or similar) is not used in this case"
 
 endchoice
 
diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig b/configs/P1010RDB-PA_36BIT_NOR_defconfig
index dcf74f5d6af5..deff04bf881d 100644
--- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
+++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
@@ -19,7 +19,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
diff --git a/configs/P1010RDB-PA_NOR_defconfig b/configs/P1010RDB-PA_NOR_defconfig
index 537d8bf576b0..98486a0ae2ff 100644
--- a/configs/P1010RDB-PA_NOR_defconfig
+++ b/configs/P1010RDB-PA_NOR_defconfig
@@ -18,7 +18,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
diff --git a/configs/P1010RDB-PB_36BIT_NOR_defconfig b/configs/P1010RDB-PB_36BIT_NOR_defconfig
index 92a7e0966936..41a1a852b986 100644
--- a/configs/P1010RDB-PB_36BIT_NOR_defconfig
+++ b/configs/P1010RDB-PB_36BIT_NOR_defconfig
@@ -19,7 +19,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
diff --git a/configs/P1010RDB-PB_NOR_defconfig b/configs/P1010RDB-PB_NOR_defconfig
index 3e16470608e5..16c076bc9aaa 100644
--- a/configs/P1010RDB-PB_NOR_defconfig
+++ b/configs/P1010RDB-PB_NOR_defconfig
@@ -18,7 +18,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
diff --git a/configs/P1020RDB-PC_36BIT_defconfig b/configs/P1020RDB-PC_36BIT_defconfig
index ce0ba0e37574..e60c92cedae9 100644
--- a/configs/P1020RDB-PC_36BIT_defconfig
+++ b/configs/P1020RDB-PC_36BIT_defconfig
@@ -21,7 +21,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig
index aae886b75c4e..f0f0eee65d29 100644
--- a/configs/P1020RDB-PC_defconfig
+++ b/configs/P1020RDB-PC_defconfig
@@ -20,7 +20,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
diff --git a/configs/P1020RDB-PD_defconfig b/configs/P1020RDB-PD_defconfig
index 5fecb6684735..8b7f9310b1a4 100644
--- a/configs/P1020RDB-PD_defconfig
+++ b/configs/P1020RDB-PD_defconfig
@@ -20,7 +20,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
diff --git a/configs/P2020RDB-PC_36BIT_defconfig b/configs/P2020RDB-PC_36BIT_defconfig
index b1dbca6e7ea3..1640f2379863 100644
--- a/configs/P2020RDB-PC_36BIT_defconfig
+++ b/configs/P2020RDB-PC_36BIT_defconfig
@@ -21,7 +21,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
diff --git a/configs/P2020RDB-PC_defconfig b/configs/P2020RDB-PC_defconfig
index 1ee46f9fbe9f..ca9f44728845 100644
--- a/configs/P2020RDB-PC_defconfig
+++ b/configs/P2020RDB-PC_defconfig
@@ -20,7 +20,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_FSL_FIXED_MMC_LOCATION=y
+CONFIG_NO_PBL=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Friday 23 December 2022 14:18:32 Tom Rini wrote:
> On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Rohár wrote:
> > On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > > > #ifdef games that PowerPC used, in a number of places have been very
> > > > > hard to un-wrap so that we can have something other than a home-grown
> > > > > build system.
> > > > 
> > > > I was already trying to reduce it too, some patches I sent, some other I
> > > > was preparing and some other are part of turris 1.x platform, which is
> > > > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > > > other P1/P2 boards, like it is in turris patch, but after turris patch
> > > > is merged... which did not happen yet.
> > > 
> > > Right, and thanks for what you've done already.
> > > 
> > > > > And I've tried to take your other feedback in to
> > > > > consideration, which has resulted in a large number of symbols being
> > > > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > > > right mechanism for them.
> > > > > 
> > > > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > > > Or is it the P1010RDB ones too?
> > > > 
> > > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > > > predates P3 platform. If there are not some suspicious symbol names then
> > > > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > > > ARCH_P2020 symbol.
> > > > 
> > > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > > > or e6500), so you can ignore these.
> > > 
> > > OK.
> > > 
> > > > Is there any tool which can list all defconfig files which defines some
> > > > of those symbols, including transitionally?
> > > 
> > > With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> > > make a database that you can consult with -f. That takes both SYMBOL and
> > > ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> > > And you can chain them together. For example:
> > > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> > > 8 matches
> > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> > > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> > > 8 matches
> > > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND
> > 
> > Ok, I tried to build database and list of the affected defconfig files:
> > (all except T, P3+ and P204x)
> > 
> > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
> > P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
> > P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
> > P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC
> > 
> > So it means that these defconfigs are broken and CONFIG_SDCARD for them
> > must be turned off:
> > 
> > P1010RDB-PB_36BIT_NOR
> > P1010RDB-PB_NOR
> > P1010RDB-PA_36BIT_NOR
> > P1010RDB-PA_NOR
> > P1020RDB-PC
> > P1020RDB-PC_36BIT
> > P1020RDB-PD
> > P2020RDB-PC_36BIT
> > P2020RDB-PC
> > 
> > 
> > These defconfigs have already CONFIG_SDCARD turned off:
> > 
> > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
> > socrates
> > MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
> > P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
> > P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
> > P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
> > qemu-ppce500
> > 
> > And seems that no of them is sd card related (hopefully).
> 
> Thanks!  Does the following look reasonable to you
> (CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll
> make a proper patch next:

Just to note that possibility of booting pre-PBL devices from SD or SPI
is described in document AN3659 - Booting from On-Chip ROM (eSDHC or eSPI):
https://www.nxp.com/docs/en/application-note/AN3659.pdf
In P2020 documentation it is named "On-chip boot ROM-eSDHC".

> 
> 
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 4a001bcee851..424ad0e466da 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -724,16 +724,19 @@ config RAMBOOT_PBL
>  	  For more details refer to doc/README.pblimage
>  
>  choice
> -	prompt "Freescale PBL load location"
> +	prompt "Freescale PBL (or predecessor) load location"
>  	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
>  		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
>  		&& !CMD_NAND)
>  
>  config SDCARD
> -	bool "Freescale PBL is found on SD card"
> +	bool "Freescale PBL (or similar) is found on SD card"
>  
>  config SPIFLASH
> -	bool "Freescale PBL is found on SPI flash"
> +	bool "Freescale PBL (or similar) is found on SPI flash"
> +
> +config NO_PBL
> +	bool "Freescale PBL (or similar) is not used in this case"
>  
>  endchoice
>  

Ok! I did runtime tests with P2020RDB-PC_defconfig on P2020 based board.


1. directly on v2022.04 tag

==> works fine


2. merged problematic commit d433c74eecdc with v2022.04 tag

$ ll u-boot.bin
-rw-r--r-- 1 pali pali 151781376 dec 23 21:24 u-boot.bin

==> not possible to flash --> binary toooooo big (due to broken commit)


3. merged problematic commit d433c74eecdc with v2022.04 tag and applying
above boot/Kconfig change and adding CONFIG_NO_PBL=y into file
P2020RDB-PC_defconfig. Also I added to include/configs/p1_p2_rdb_pc.h
check:

#ifdef CONFIG_SDCARD
#error "CONFIG_SDCARD is defined"
#endif

Whole steps:
$ git checkout v2022.04
$ git merge d433c74eecdc
(resolve merge conflict for doc/)
$ git checkout --theirs doc/usage/index.rst
$ git add doc/usage/index.rst
$ git commit
apply change
add CONFIG_NO_PBL=y
$ make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig
$ make CROSS_COMPILE=powerpc-linux-gnuspe- -j12

Binary now has correct size (it must have exactly 768 kB)

$ ll u-boot.bin
-rw-r--r-- 1 pali pali 786432 dec 23 21:33 u-boot.bin

U-Boot 2022.04-00286-g72336d158369-dirty (Dec 23 2022 - 21:18:23 +0100)

CPU0:  P2020E, Version: 2.1, (0x80ea0021)
Core:  e500, Version: 5.1, (0x80211051)
Clock Configuration:
       CPU0:1200 MHz, CPU1:1200 MHz, 
       CCB:600  MHz,
       DDR:400  MHz (800 MT/s data rate) (Asynchronous), LBC:600  MHz
L1:    D-cache 32 KiB enabled
       I-cache 32 KiB enabled
Model: fsl,P2020RDB-PC
Board: P2020RDB-PC CPLD: V4.1 PCBA: V4.0
rom_loc: nor upper bank
SD/MMC : 4-bit Mode
eSPI : Enabled
DRAM:  Detected UDIMM 9905594-003.A00G  
2 GiB (DDR3, 64-bit, CL=6, ECC off)
Core:  11 devices, 9 uclasses, devicetree: embed
No address specified for VSC7385 microcode.
Flash: 16 MiB
L2:    512 KiB enabled
MMC:   fsl_esdhc: Internal clock never stabilised.
FSL_SDHC: 0
Loading Environment from Flash... OK
In:    serial
Out:   serial
Err:   serial
Net:   eTSEC1
Error: eTSEC1 address not set.
, eTSEC2
Error: eTSEC2 address not set.
, eTSEC3
Error: eTSEC3 address not set.

=> 

==> So works fine!


4. u-boot master with this patch

==> does not work, no output on console; but SDCARD version is working,
so clearly some other commit broke non-SDCARD version too.

So go ahead and apply this fix to master branch. You can add my
Tested-by: Pali Rohár <pali@kernel.org>

> diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> index dcf74f5d6af5..deff04bf881d 100644
> --- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
> +++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> @@ -19,7 +19,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> diff --git a/configs/P1010RDB-PA_NOR_defconfig b/configs/P1010RDB-PA_NOR_defconfig
> index 537d8bf576b0..98486a0ae2ff 100644
> --- a/configs/P1010RDB-PA_NOR_defconfig
> +++ b/configs/P1010RDB-PA_NOR_defconfig
> @@ -18,7 +18,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> diff --git a/configs/P1010RDB-PB_36BIT_NOR_defconfig b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> index 92a7e0966936..41a1a852b986 100644
> --- a/configs/P1010RDB-PB_36BIT_NOR_defconfig
> +++ b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> @@ -19,7 +19,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> diff --git a/configs/P1010RDB-PB_NOR_defconfig b/configs/P1010RDB-PB_NOR_defconfig
> index 3e16470608e5..16c076bc9aaa 100644
> --- a/configs/P1010RDB-PB_NOR_defconfig
> +++ b/configs/P1010RDB-PB_NOR_defconfig
> @@ -18,7 +18,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> diff --git a/configs/P1020RDB-PC_36BIT_defconfig b/configs/P1020RDB-PC_36BIT_defconfig
> index ce0ba0e37574..e60c92cedae9 100644
> --- a/configs/P1020RDB-PC_36BIT_defconfig
> +++ b/configs/P1020RDB-PC_36BIT_defconfig
> @@ -21,7 +21,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig
> index aae886b75c4e..f0f0eee65d29 100644
> --- a/configs/P1020RDB-PC_defconfig
> +++ b/configs/P1020RDB-PC_defconfig
> @@ -20,7 +20,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> diff --git a/configs/P1020RDB-PD_defconfig b/configs/P1020RDB-PD_defconfig
> index 5fecb6684735..8b7f9310b1a4 100644
> --- a/configs/P1020RDB-PD_defconfig
> +++ b/configs/P1020RDB-PD_defconfig
> @@ -20,7 +20,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> diff --git a/configs/P2020RDB-PC_36BIT_defconfig b/configs/P2020RDB-PC_36BIT_defconfig
> index b1dbca6e7ea3..1640f2379863 100644
> --- a/configs/P2020RDB-PC_36BIT_defconfig
> +++ b/configs/P2020RDB-PC_36BIT_defconfig
> @@ -21,7 +21,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> diff --git a/configs/P2020RDB-PC_defconfig b/configs/P2020RDB-PC_defconfig
> index 1ee46f9fbe9f..ca9f44728845 100644
> --- a/configs/P2020RDB-PC_defconfig
> +++ b/configs/P2020RDB-PC_defconfig
> @@ -20,7 +20,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> -CONFIG_FSL_FIXED_MMC_LOCATION=y
> +CONFIG_NO_PBL=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTCOMMAND=y
>  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> 
> -- 
> Tom

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> Or is it the P1010RDB ones too?

I have looked at d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 again and for
sure also PBL platforms are affected. For example board P2041RDB_NAND
did not have SDCARD set before that commit and it has it set after that
commit. So complementary command (grep -v => grep) finds them:

$ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
P2041RDB_SDCARD P2041RDB_NAND
T1024RDB_SDCARD T1024RDB_NAND
T1042D4RDB_NAND T1042D4RDB_SDCARD
T2080RDB_revD_NAND T2080RDB_SDCARD T2080RDB_NAND T2080QDS_SDCARD T2080RDB_revD_SDCARD T2080QDS_NAND
T4240RDB_SDCARD

So all non-SDCARD defconfigs with high probability are affected. But
unfortunately I do not have any P3/P4/P5/T board for testing there.

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Friday 23 December 2022 22:39:00 Pali Rohár wrote:
> On Friday 23 December 2022 14:18:32 Tom Rini wrote:
> > On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Rohár wrote:
> > > On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > > > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > > > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > > > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > > > > #ifdef games that PowerPC used, in a number of places have been very
> > > > > > hard to un-wrap so that we can have something other than a home-grown
> > > > > > build system.
> > > > > 
> > > > > I was already trying to reduce it too, some patches I sent, some other I
> > > > > was preparing and some other are part of turris 1.x platform, which is
> > > > > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > > > > other P1/P2 boards, like it is in turris patch, but after turris patch
> > > > > is merged... which did not happen yet.
> > > > 
> > > > Right, and thanks for what you've done already.
> > > > 
> > > > > > And I've tried to take your other feedback in to
> > > > > > consideration, which has resulted in a large number of symbols being
> > > > > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > > > > right mechanism for them.
> > > > > > 
> > > > > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > > > > Or is it the P1010RDB ones too?
> > > > > 
> > > > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > > > > predates P3 platform. If there are not some suspicious symbol names then
> > > > > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > > > > ARCH_P2020 symbol.
> > > > > 
> > > > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > > > > or e6500), so you can ignore these.
> > > > 
> > > > OK.
> > > > 
> > > > > Is there any tool which can list all defconfig files which defines some
> > > > > of those symbols, including transitionally?
> > > > 
> > > > With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> > > > make a database that you can consult with -f. That takes both SYMBOL and
> > > > ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> > > > And you can chain them together. For example:
> > > > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> > > > 8 matches
> > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> > > > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> > > > 8 matches
> > > > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND
> > > 
> > > Ok, I tried to build database and list of the affected defconfig files:
> > > (all except T, P3+ and P204x)
> > > 
> > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
> > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
> > > P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
> > > P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC
> > > 
> > > So it means that these defconfigs are broken and CONFIG_SDCARD for them
> > > must be turned off:
> > > 
> > > P1010RDB-PB_36BIT_NOR
> > > P1010RDB-PB_NOR
> > > P1010RDB-PA_36BIT_NOR
> > > P1010RDB-PA_NOR
> > > P1020RDB-PC
> > > P1020RDB-PC_36BIT
> > > P1020RDB-PD
> > > P2020RDB-PC_36BIT
> > > P2020RDB-PC
> > > 
> > > 
> > > These defconfigs have already CONFIG_SDCARD turned off:
> > > 
> > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
> > > socrates
> > > MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
> > > P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
> > > P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
> > > P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
> > > qemu-ppce500
> > > 
> > > And seems that no of them is sd card related (hopefully).
> > 
> > Thanks!  Does the following look reasonable to you
> > (CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll
> > make a proper patch next:
> 
> Just to note that possibility of booting pre-PBL devices from SD or SPI
> is described in document AN3659 - Booting from On-Chip ROM (eSDHC or eSPI):
> https://www.nxp.com/docs/en/application-note/AN3659.pdf
> In P2020 documentation it is named "On-chip boot ROM-eSDHC".
> 
> > 
> > 
> > diff --git a/boot/Kconfig b/boot/Kconfig
> > index 4a001bcee851..424ad0e466da 100644
> > --- a/boot/Kconfig
> > +++ b/boot/Kconfig
> > @@ -724,16 +724,19 @@ config RAMBOOT_PBL
> >  	  For more details refer to doc/README.pblimage
> >  
> >  choice
> > -	prompt "Freescale PBL load location"
> > +	prompt "Freescale PBL (or predecessor) load location"
> >  	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> >  		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> >  		&& !CMD_NAND)

And it should depends on CPU/ARCH, not at list of boards... as this is
bootrom/CPU feature, not board feature. So maybe on CONFIG_MPC85xx? But
needs to be ensured that SDCARD symbol is not enabled in defconfigs
where it is not.

> >  
> >  config SDCARD
> > -	bool "Freescale PBL is found on SD card"
> > +	bool "Freescale PBL (or similar) is found on SD card"
> >  
> >  config SPIFLASH
> > -	bool "Freescale PBL is found on SPI flash"
> > +	bool "Freescale PBL (or similar) is found on SPI flash"
> > +
> > +config NO_PBL
> > +	bool "Freescale PBL (or similar) is not used in this case"
> >  
> >  endchoice
> >  
> 
> Ok! I did runtime tests with P2020RDB-PC_defconfig on P2020 based board.
> 
> 
> 1. directly on v2022.04 tag
> 
> ==> works fine
> 
> 
> 2. merged problematic commit d433c74eecdc with v2022.04 tag
> 
> $ ll u-boot.bin
> -rw-r--r-- 1 pali pali 151781376 dec 23 21:24 u-boot.bin
> 
> ==> not possible to flash --> binary toooooo big (due to broken commit)
> 
> 
> 3. merged problematic commit d433c74eecdc with v2022.04 tag and applying
> above boot/Kconfig change and adding CONFIG_NO_PBL=y into file
> P2020RDB-PC_defconfig. Also I added to include/configs/p1_p2_rdb_pc.h
> check:
> 
> #ifdef CONFIG_SDCARD
> #error "CONFIG_SDCARD is defined"
> #endif
> 
> Whole steps:
> $ git checkout v2022.04
> $ git merge d433c74eecdc
> (resolve merge conflict for doc/)
> $ git checkout --theirs doc/usage/index.rst
> $ git add doc/usage/index.rst
> $ git commit
> apply change
> add CONFIG_NO_PBL=y
> $ make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig
> $ make CROSS_COMPILE=powerpc-linux-gnuspe- -j12
> 
> Binary now has correct size (it must have exactly 768 kB)
> 
> $ ll u-boot.bin
> -rw-r--r-- 1 pali pali 786432 dec 23 21:33 u-boot.bin
> 
> U-Boot 2022.04-00286-g72336d158369-dirty (Dec 23 2022 - 21:18:23 +0100)
> 
> CPU0:  P2020E, Version: 2.1, (0x80ea0021)
> Core:  e500, Version: 5.1, (0x80211051)
> Clock Configuration:
>        CPU0:1200 MHz, CPU1:1200 MHz, 
>        CCB:600  MHz,
>        DDR:400  MHz (800 MT/s data rate) (Asynchronous), LBC:600  MHz
> L1:    D-cache 32 KiB enabled
>        I-cache 32 KiB enabled
> Model: fsl,P2020RDB-PC
> Board: P2020RDB-PC CPLD: V4.1 PCBA: V4.0
> rom_loc: nor upper bank
> SD/MMC : 4-bit Mode
> eSPI : Enabled
> DRAM:  Detected UDIMM 9905594-003.A00G  
> 2 GiB (DDR3, 64-bit, CL=6, ECC off)
> Core:  11 devices, 9 uclasses, devicetree: embed
> No address specified for VSC7385 microcode.
> Flash: 16 MiB
> L2:    512 KiB enabled
> MMC:   fsl_esdhc: Internal clock never stabilised.
> FSL_SDHC: 0
> Loading Environment from Flash... OK
> In:    serial
> Out:   serial
> Err:   serial
> Net:   eTSEC1
> Error: eTSEC1 address not set.
> , eTSEC2
> Error: eTSEC2 address not set.
> , eTSEC3
> Error: eTSEC3 address not set.
> 
> => 
> 
> ==> So works fine!
> 
> 
> 4. u-boot master with this patch
> 
> ==> does not work, no output on console; but SDCARD version is working,
> so clearly some other commit broke non-SDCARD version too.
> 
> So go ahead and apply this fix to master branch. You can add my
> Tested-by: Pali Rohár <pali@kernel.org>
> 
> > diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> > index dcf74f5d6af5..deff04bf881d 100644
> > --- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
> > +++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> > @@ -19,7 +19,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1010RDB-PA_NOR_defconfig b/configs/P1010RDB-PA_NOR_defconfig
> > index 537d8bf576b0..98486a0ae2ff 100644
> > --- a/configs/P1010RDB-PA_NOR_defconfig
> > +++ b/configs/P1010RDB-PA_NOR_defconfig
> > @@ -18,7 +18,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1010RDB-PB_36BIT_NOR_defconfig b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> > index 92a7e0966936..41a1a852b986 100644
> > --- a/configs/P1010RDB-PB_36BIT_NOR_defconfig
> > +++ b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> > @@ -19,7 +19,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1010RDB-PB_NOR_defconfig b/configs/P1010RDB-PB_NOR_defconfig
> > index 3e16470608e5..16c076bc9aaa 100644
> > --- a/configs/P1010RDB-PB_NOR_defconfig
> > +++ b/configs/P1010RDB-PB_NOR_defconfig
> > @@ -18,7 +18,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1020RDB-PC_36BIT_defconfig b/configs/P1020RDB-PC_36BIT_defconfig
> > index ce0ba0e37574..e60c92cedae9 100644
> > --- a/configs/P1020RDB-PC_36BIT_defconfig
> > +++ b/configs/P1020RDB-PC_36BIT_defconfig
> > @@ -21,7 +21,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig
> > index aae886b75c4e..f0f0eee65d29 100644
> > --- a/configs/P1020RDB-PC_defconfig
> > +++ b/configs/P1020RDB-PC_defconfig
> > @@ -20,7 +20,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P1020RDB-PD_defconfig b/configs/P1020RDB-PD_defconfig
> > index 5fecb6684735..8b7f9310b1a4 100644
> > --- a/configs/P1020RDB-PD_defconfig
> > +++ b/configs/P1020RDB-PD_defconfig
> > @@ -20,7 +20,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P2020RDB-PC_36BIT_defconfig b/configs/P2020RDB-PC_36BIT_defconfig
> > index b1dbca6e7ea3..1640f2379863 100644
> > --- a/configs/P2020RDB-PC_36BIT_defconfig
> > +++ b/configs/P2020RDB-PC_36BIT_defconfig
> > @@ -21,7 +21,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P2020RDB-PC_defconfig b/configs/P2020RDB-PC_defconfig
> > index 1ee46f9fbe9f..ca9f44728845 100644
> > --- a/configs/P2020RDB-PC_defconfig
> > +++ b/configs/P2020RDB-PC_defconfig
> > @@ -20,7 +20,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > 
> > -- 
> > Tom
> 
> 

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7093 bytes --]

On Fri, Dec 23, 2022 at 11:34:46PM +0100, Pali Rohár wrote:
> On Friday 23 December 2022 22:39:00 Pali Rohár wrote:
> > On Friday 23 December 2022 14:18:32 Tom Rini wrote:
> > > On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Rohár wrote:
> > > > On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > > > > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > > > > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > > > > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > > > > > #ifdef games that PowerPC used, in a number of places have been very
> > > > > > > hard to un-wrap so that we can have something other than a home-grown
> > > > > > > build system.
> > > > > > 
> > > > > > I was already trying to reduce it too, some patches I sent, some other I
> > > > > > was preparing and some other are part of turris 1.x platform, which is
> > > > > > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > > > > > other P1/P2 boards, like it is in turris patch, but after turris patch
> > > > > > is merged... which did not happen yet.
> > > > > 
> > > > > Right, and thanks for what you've done already.
> > > > > 
> > > > > > > And I've tried to take your other feedback in to
> > > > > > > consideration, which has resulted in a large number of symbols being
> > > > > > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > > > > > right mechanism for them.
> > > > > > > 
> > > > > > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > > > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > > > > > Or is it the P1010RDB ones too?
> > > > > > 
> > > > > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > > > > > predates P3 platform. If there are not some suspicious symbol names then
> > > > > > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > > > > > ARCH_P2020 symbol.
> > > > > > 
> > > > > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > > > > > or e6500), so you can ignore these.
> > > > > 
> > > > > OK.
> > > > > 
> > > > > > Is there any tool which can list all defconfig files which defines some
> > > > > > of those symbols, including transitionally?
> > > > > 
> > > > > With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> > > > > make a database that you can consult with -f. That takes both SYMBOL and
> > > > > ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> > > > > And you can chain them together. For example:
> > > > > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> > > > > 8 matches
> > > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> > > > > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> > > > > 8 matches
> > > > > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND
> > > > 
> > > > Ok, I tried to build database and list of the affected defconfig files:
> > > > (all except T, P3+ and P204x)
> > > > 
> > > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
> > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
> > > > P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
> > > > P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC
> > > > 
> > > > So it means that these defconfigs are broken and CONFIG_SDCARD for them
> > > > must be turned off:
> > > > 
> > > > P1010RDB-PB_36BIT_NOR
> > > > P1010RDB-PB_NOR
> > > > P1010RDB-PA_36BIT_NOR
> > > > P1010RDB-PA_NOR
> > > > P1020RDB-PC
> > > > P1020RDB-PC_36BIT
> > > > P1020RDB-PD
> > > > P2020RDB-PC_36BIT
> > > > P2020RDB-PC
> > > > 
> > > > 
> > > > These defconfigs have already CONFIG_SDCARD turned off:
> > > > 
> > > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
> > > > socrates
> > > > MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
> > > > P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
> > > > P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
> > > > P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
> > > > qemu-ppce500
> > > > 
> > > > And seems that no of them is sd card related (hopefully).
> > > 
> > > Thanks!  Does the following look reasonable to you
> > > (CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll
> > > make a proper patch next:
> > 
> > Just to note that possibility of booting pre-PBL devices from SD or SPI
> > is described in document AN3659 - Booting from On-Chip ROM (eSDHC or eSPI):
> > https://www.nxp.com/docs/en/application-note/AN3659.pdf
> > In P2020 documentation it is named "On-chip boot ROM-eSDHC".
> > 
> > > 
> > > 
> > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > index 4a001bcee851..424ad0e466da 100644
> > > --- a/boot/Kconfig
> > > +++ b/boot/Kconfig
> > > @@ -724,16 +724,19 @@ config RAMBOOT_PBL
> > >  	  For more details refer to doc/README.pblimage
> > >  
> > >  choice
> > > -	prompt "Freescale PBL load location"
> > > +	prompt "Freescale PBL (or predecessor) load location"
> > >  	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > >  		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > >  		&& !CMD_NAND)
> 
> And it should depends on CPU/ARCH, not at list of boards... as this is
> bootrom/CPU feature, not board feature. So maybe on CONFIG_MPC85xx? But
> needs to be ensured that SDCARD symbol is not enabled in defconfigs
> where it is not.

So, with the benefit of hindsight, I re-ran the before/after world build
of the original bad migration, to see what changed where.  That gives
us:
P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PC P1020RDB-PC_36BIT P1020RDB-PD
P1010RDB-PA_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_36BIT_NOR
P1010RDB-PB_NOR T1024RDB_NAND T2080RDB_NAND T2080RDB_revD_NAND
T2080QDS_NAND

And aside from p1_p2_rdb those differences are just print related.  But,
that excludes include/configs/.  And then if we look at what sets
CONFIG_SDCARD in include/configs/ there might be a few pad sizes that
then get migrated wrong, but I'm not sure.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Saturday 24 December 2022 11:13:41 Tom Rini wrote:
> On Fri, Dec 23, 2022 at 11:34:46PM +0100, Pali Rohár wrote:
> > On Friday 23 December 2022 22:39:00 Pali Rohár wrote:
> > > On Friday 23 December 2022 14:18:32 Tom Rini wrote:
> > > > On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Rohár wrote:
> > > > > On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > > > > > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > > > > > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > > > > > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > > > > > > #ifdef games that PowerPC used, in a number of places have been very
> > > > > > > > hard to un-wrap so that we can have something other than a home-grown
> > > > > > > > build system.
> > > > > > > 
> > > > > > > I was already trying to reduce it too, some patches I sent, some other I
> > > > > > > was preparing and some other are part of turris 1.x platform, which is
> > > > > > > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > > > > > > other P1/P2 boards, like it is in turris patch, but after turris patch
> > > > > > > is merged... which did not happen yet.
> > > > > > 
> > > > > > Right, and thanks for what you've done already.
> > > > > > 
> > > > > > > > And I've tried to take your other feedback in to
> > > > > > > > consideration, which has resulted in a large number of symbols being
> > > > > > > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > > > > > > right mechanism for them.
> > > > > > > > 
> > > > > > > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > > > > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > > > > > > Or is it the P1010RDB ones too?
> > > > > > > 
> > > > > > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > > > > > > predates P3 platform. If there are not some suspicious symbol names then
> > > > > > > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > > > > > > ARCH_P2020 symbol.
> > > > > > > 
> > > > > > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > > > > > > or e6500), so you can ignore these.
> > > > > > 
> > > > > > OK.
> > > > > > 
> > > > > > > Is there any tool which can list all defconfig files which defines some
> > > > > > > of those symbols, including transitionally?
> > > > > > 
> > > > > > With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> > > > > > make a database that you can consult with -f. That takes both SYMBOL and
> > > > > > ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> > > > > > And you can chain them together. For example:
> > > > > > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> > > > > > 8 matches
> > > > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> > > > > > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> > > > > > 8 matches
> > > > > > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND
> > > > > 
> > > > > Ok, I tried to build database and list of the affected defconfig files:
> > > > > (all except T, P3+ and P204x)
> > > > > 
> > > > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
> > > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
> > > > > P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
> > > > > P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC
> > > > > 
> > > > > So it means that these defconfigs are broken and CONFIG_SDCARD for them
> > > > > must be turned off:
> > > > > 
> > > > > P1010RDB-PB_36BIT_NOR
> > > > > P1010RDB-PB_NOR
> > > > > P1010RDB-PA_36BIT_NOR
> > > > > P1010RDB-PA_NOR
> > > > > P1020RDB-PC
> > > > > P1020RDB-PC_36BIT
> > > > > P1020RDB-PD
> > > > > P2020RDB-PC_36BIT
> > > > > P2020RDB-PC
> > > > > 
> > > > > 
> > > > > These defconfigs have already CONFIG_SDCARD turned off:
> > > > > 
> > > > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
> > > > > socrates
> > > > > MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
> > > > > P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
> > > > > P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
> > > > > P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
> > > > > qemu-ppce500
> > > > > 
> > > > > And seems that no of them is sd card related (hopefully).
> > > > 
> > > > Thanks!  Does the following look reasonable to you
> > > > (CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll
> > > > make a proper patch next:
> > > 
> > > Just to note that possibility of booting pre-PBL devices from SD or SPI
> > > is described in document AN3659 - Booting from On-Chip ROM (eSDHC or eSPI):
> > > https://www.nxp.com/docs/en/application-note/AN3659.pdf
> > > In P2020 documentation it is named "On-chip boot ROM-eSDHC".
> > > 
> > > > 
> > > > 
> > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > index 4a001bcee851..424ad0e466da 100644
> > > > --- a/boot/Kconfig
> > > > +++ b/boot/Kconfig
> > > > @@ -724,16 +724,19 @@ config RAMBOOT_PBL
> > > >  	  For more details refer to doc/README.pblimage
> > > >  
> > > >  choice
> > > > -	prompt "Freescale PBL load location"
> > > > +	prompt "Freescale PBL (or predecessor) load location"
> > > >  	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> > > >  		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> > > >  		&& !CMD_NAND)
> > 
> > And it should depends on CPU/ARCH, not at list of boards... as this is
> > bootrom/CPU feature, not board feature. So maybe on CONFIG_MPC85xx? But
> > needs to be ensured that SDCARD symbol is not enabled in defconfigs
> > where it is not.
> 
> So, with the benefit of hindsight, I re-ran the before/after world build
> of the original bad migration, to see what changed where.  That gives
> us:
> P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PC P1020RDB-PC_36BIT P1020RDB-PD
> P1010RDB-PA_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_36BIT_NOR
> P1010RDB-PB_NOR T1024RDB_NAND T2080RDB_NAND T2080RDB_revD_NAND
> T2080QDS_NAND
> 
> And aside from p1_p2_rdb those differences are just print related.  But,
> that excludes include/configs/.  And then if we look at what sets
> CONFIG_SDCARD in include/configs/ there might be a few pad sizes that
> then get migrated wrong, but I'm not sure.
> 
> -- 
> Tom

This is probably reason why u-boot from master branch did not work
during my yesterday tests.

I created list of macros from include/configs/* files which value
depends on CONFIG_SDCARD:

BOOT_PAGE_OFFSET
CONFIG_ENV_RANGE
CONFIG_FSL_FIXED_MMC_LOCATION
CONFIG_RAMBOOT_TEXT_BASE
CONFIG_RESET_VECTOR_ADDRESS
CONFIG_SPL_COMMON_INIT_DDR
CONFIG_SPL_FLUSH_IMAGE
CONFIG_SPL_GD_ADDR
CONFIG_SPL_INIT_MINIMAL
CONFIG_SPL_MAX_SIZE
CONFIG_SPL_NAND_INIT
CONFIG_SPL_PAD_TO
CONFIG_SPL_RELOC_MALLOC_ADDR
CONFIG_SPL_RELOC_MALLOC_SIZE
CONFIG_SPL_RELOC_STACK
CONFIG_SPL_RELOC_TEXT_BASE
CONFIG_SPL_SKIP_RELOCATE
CONFIG_SPL_SPI_FLASH_MINIMAL
CONFIG_SPL_TARGET
CONFIG_SYS_CCSR_DO_NOT_RELOCATE
CONFIG_SYS_INIT_L2_ADDR
CONFIG_SYS_INIT_L2_ADDR_PHYS
CONFIG_SYS_INIT_L2_END
CONFIG_SYS_L2_SIZE
CONFIG_SYS_MMC_U_BOOT_DST
CONFIG_SYS_MMC_U_BOOT_OFFS
CONFIG_SYS_MMC_U_BOOT_SIZE
CONFIG_SYS_MMC_U_BOOT_START
CONFIG_SYS_MPC85XX_NO_RESETVEC
CONFIG_SYS_NAND_U_BOOT_DST
CONFIG_SYS_NAND_U_BOOT_SIZE
CONFIG_SYS_NAND_U_BOOT_START
CONFIG_SYS_SPI_FLASH_U_BOOT_DST
CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS
CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE
CONFIG_SYS_SPI_FLASH_U_BOOT_START
CONFIG_TPL_PAD_TO
RESET_VECTOR_OFFSET
SPL_ENV_ADDR

So if they were migrated then probably have wrong values, undefined
value or completely missing after migration.

Freescale P2020 Internal Boot ROM

[Pali Rohár]

On Thursday 22 December 2022 19:36:58 Tom Rini wrote:
> On Thu, Dec 22, 2022 at 10:02:42PM +0100, Pali Rohár wrote:
> > On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > > I suspect that how we fire up QEMU means that the issue you're
> > > noting isn't triggered since we don't boot it from flash but instead
> > > pass the binary.
> > 
> > Yes, this sounds like that problematic part is not tested. To spot this
> > issue some end-to-end test is needed... For flash setup - booting
> > directly from the qemu flash (execute in place) without initialized RAM
> > and letting u-boot to do it. For SD card setup - booting via BootROM
> > (like it is on the real HW). Seems that SD card BootROM is not available
> > on internet and no idea if it can be dumped from some Freescale CPU (it
> > is even legal to do it?). So some alternative bootrom implementation for
> > such testing is needed... which is lot of work.
> 
> We do some things like this already, for other QEMU platforms (the
> flash_impl variable is set to the shell script to create a flash image)
> but, it's unlikely to be worth expending the effort here, the ROM QEMU
> uses here isn't the Freescale one, but from openhackware.

If somebody is interesting, Freescale P2020 Internal boot ROM for SDHC
(maybe it is common with SPI) is at offset 0xFE000 in CCSR block. Hence
it can be dumped from (32-bit) U-Boot by command:

  => md.b 0xffefe000 0x2000

At first 0x1000 bytes there is nothing and code starts at second part.
During boot phase, it is mapped to the end of the (4GB) memory space
and entry point is the last instruction. So boot rom is just 4kB long.

In case somebody wants this dump, just send me an email.

Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Pali Rohár]

On Friday 23 December 2022 22:39:00 Pali Rohár wrote:
> On Friday 23 December 2022 14:18:32 Tom Rini wrote:
> > On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Rohár wrote:
> > > On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
> > > > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Rohár wrote:
> > > > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote:
> > > > > > I'm sorry you're frustrated here. I'm also frustrated here because the
> > > > > > #ifdef games that PowerPC used, in a number of places have been very
> > > > > > hard to un-wrap so that we can have something other than a home-grown
> > > > > > build system.
> > > > > 
> > > > > I was already trying to reduce it too, some patches I sent, some other I
> > > > > was preparing and some other are part of turris 1.x platform, which is
> > > > > waiting there for 6 months. I planned to apply removal of MMC symbols to
> > > > > other P1/P2 boards, like it is in turris patch, but after turris patch
> > > > > is merged... which did not happen yet.
> > > > 
> > > > Right, and thanks for what you've done already.
> > > > 
> > > > > > And I've tried to take your other feedback in to
> > > > > > consideration, which has resulted in a large number of symbols being
> > > > > > moved to CFG_... instead of Kconfig, as you're right, it wasn't the
> > > > > > right mechanism for them.
> > > > > > 
> > > > > > So, is it really just the 3 platforms that use p1_p2_rdb.h that need
> > > > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix defconfigs?
> > > > > > Or is it the P1010RDB ones too?
> > > > > 
> > > > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot and
> > > > > predates P3 platform. If there are not some suspicious symbol names then
> > > > > it should match any board which uses ARCH_MPC85??? or ARCH_P1?? or
> > > > > ARCH_P2020 symbol.
> > > > > 
> > > > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc or e5500
> > > > > or e6500), so you can ignore these.
> > > > 
> > > > OK.
> > > > 
> > > > > Is there any tool which can list all defconfig files which defines some
> > > > > of those symbols, including transitionally?
> > > > 
> > > > With the caveat of only symbols in Kconfig, tools/moveconfig.py -b will
> > > > make a database that you can consult with -f. That takes both SYMBOL and
> > > > ~SYMBOL to list configs with SYMBOL enabled or disabled, respectively.
> > > > And you can chain them together. For example:
> > > > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD
> > > > 8 matches
> > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR P1010RDB-PA_SDCARD
> > > > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD
> > > > 8 matches
> > > > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_36BIT_NAND
> > > 
> > > Ok, I tried to build database and list of the affected defconfig files:
> > > (all except T, P3+ and P204x)
> > > 
> > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$'
> > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P1010RDB-PA_36BIT_SDCARD
> > > P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT P1020RDB-PD P1020RDB-PC_36BIT_SDCARD
> > > P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020RDB-PC
> > > 
> > > So it means that these defconfigs are broken and CONFIG_SDCARD for them
> > > must be turned off:
> > > 
> > > P1010RDB-PB_36BIT_NOR
> > > P1010RDB-PB_NOR
> > > P1010RDB-PA_36BIT_NOR
> > > P1010RDB-PA_NOR
> > > P1020RDB-PC
> > > P1020RDB-PC_36BIT
> > > P1020RDB-PD
> > > P2020RDB-PC_36BIT
> > > P2020RDB-PC
> > > 
> > > 
> > > These defconfigs have already CONFIG_SDCARD turned off:
> > > 
> > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools/moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$'
> > > socrates
> > > MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT
> > > P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH
> > > P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND
> > > P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_36BIT_NAND
> > > qemu-ppce500
> > > 
> > > And seems that no of them is sd card related (hopefully).
> > 
> > Thanks!  Does the following look reasonable to you
> > (CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll
> > make a proper patch next:
> 
> Just to note that possibility of booting pre-PBL devices from SD or SPI
> is described in document AN3659 - Booting from On-Chip ROM (eSDHC or eSPI):
> https://www.nxp.com/docs/en/application-note/AN3659.pdf
> In P2020 documentation it is named "On-chip boot ROM-eSDHC".
> 
> > 
> > 
> > diff --git a/boot/Kconfig b/boot/Kconfig
> > index 4a001bcee851..424ad0e466da 100644
> > --- a/boot/Kconfig
> > +++ b/boot/Kconfig
> > @@ -724,16 +724,19 @@ config RAMBOOT_PBL
> >  	  For more details refer to doc/README.pblimage
> >  
> >  choice
> > -	prompt "Freescale PBL load location"
> > +	prompt "Freescale PBL (or predecessor) load location"
> >  	depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_PB \
> >  		|| TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \
> >  		&& !CMD_NAND)
> >  
> >  config SDCARD
> > -	bool "Freescale PBL is found on SD card"
> > +	bool "Freescale PBL (or similar) is found on SD card"
> >  
> >  config SPIFLASH
> > -	bool "Freescale PBL is found on SPI flash"
> > +	bool "Freescale PBL (or similar) is found on SPI flash"
> > +
> > +config NO_PBL
> > +	bool "Freescale PBL (or similar) is not used in this case"
> >  
> >  endchoice
> >  
> 
> Ok! I did runtime tests with P2020RDB-PC_defconfig on P2020 based board.
> 
> 
> 1. directly on v2022.04 tag
> 
> ==> works fine
> 
> 
> 2. merged problematic commit d433c74eecdc with v2022.04 tag
> 
> $ ll u-boot.bin
> -rw-r--r-- 1 pali pali 151781376 dec 23 21:24 u-boot.bin
> 
> ==> not possible to flash --> binary toooooo big (due to broken commit)
> 
> 
> 3. merged problematic commit d433c74eecdc with v2022.04 tag and applying
> above boot/Kconfig change and adding CONFIG_NO_PBL=y into file
> P2020RDB-PC_defconfig. Also I added to include/configs/p1_p2_rdb_pc.h
> check:
> 
> #ifdef CONFIG_SDCARD
> #error "CONFIG_SDCARD is defined"
> #endif
> 
> Whole steps:
> $ git checkout v2022.04
> $ git merge d433c74eecdc
> (resolve merge conflict for doc/)
> $ git checkout --theirs doc/usage/index.rst
> $ git add doc/usage/index.rst
> $ git commit
> apply change
> add CONFIG_NO_PBL=y
> $ make CROSS_COMPILE=powerpc-linux-gnuspe- P2020RDB-PC_defconfig
> $ make CROSS_COMPILE=powerpc-linux-gnuspe- -j12
> 
> Binary now has correct size (it must have exactly 768 kB)
> 
> $ ll u-boot.bin
> -rw-r--r-- 1 pali pali 786432 dec 23 21:33 u-boot.bin
> 
> U-Boot 2022.04-00286-g72336d158369-dirty (Dec 23 2022 - 21:18:23 +0100)
> 
> CPU0:  P2020E, Version: 2.1, (0x80ea0021)
> Core:  e500, Version: 5.1, (0x80211051)
> Clock Configuration:
>        CPU0:1200 MHz, CPU1:1200 MHz, 
>        CCB:600  MHz,
>        DDR:400  MHz (800 MT/s data rate) (Asynchronous), LBC:600  MHz
> L1:    D-cache 32 KiB enabled
>        I-cache 32 KiB enabled
> Model: fsl,P2020RDB-PC
> Board: P2020RDB-PC CPLD: V4.1 PCBA: V4.0
> rom_loc: nor upper bank
> SD/MMC : 4-bit Mode
> eSPI : Enabled
> DRAM:  Detected UDIMM 9905594-003.A00G  
> 2 GiB (DDR3, 64-bit, CL=6, ECC off)
> Core:  11 devices, 9 uclasses, devicetree: embed
> No address specified for VSC7385 microcode.
> Flash: 16 MiB
> L2:    512 KiB enabled
> MMC:   fsl_esdhc: Internal clock never stabilised.
> FSL_SDHC: 0
> Loading Environment from Flash... OK
> In:    serial
> Out:   serial
> Err:   serial
> Net:   eTSEC1
> Error: eTSEC1 address not set.
> , eTSEC2
> Error: eTSEC2 address not set.
> , eTSEC3
> Error: eTSEC3 address not set.
> 
> => 
> 
> ==> So works fine!
> 
> 
> 4. u-boot master with this patch
> 
> ==> does not work, no output on console; but SDCARD version is working,
> so clearly some other commit broke non-SDCARD version too.
> 
> So go ahead and apply this fix to master branch. You can add my
> Tested-by: Pali Rohár <pali@kernel.org>

Are you going to apply this fix to master branch?

> > diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> > index dcf74f5d6af5..deff04bf881d 100644
> > --- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
> > +++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> > @@ -19,7 +19,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1010RDB-PA_NOR_defconfig b/configs/P1010RDB-PA_NOR_defconfig
> > index 537d8bf576b0..98486a0ae2ff 100644
> > --- a/configs/P1010RDB-PA_NOR_defconfig
> > +++ b/configs/P1010RDB-PA_NOR_defconfig
> > @@ -18,7 +18,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1010RDB-PB_36BIT_NOR_defconfig b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> > index 92a7e0966936..41a1a852b986 100644
> > --- a/configs/P1010RDB-PB_36BIT_NOR_defconfig
> > +++ b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> > @@ -19,7 +19,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1010RDB-PB_NOR_defconfig b/configs/P1010RDB-PB_NOR_defconfig
> > index 3e16470608e5..16c076bc9aaa 100644
> > --- a/configs/P1010RDB-PB_NOR_defconfig
> > +++ b/configs/P1010RDB-PB_NOR_defconfig
> > @@ -18,7 +18,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr"
> > diff --git a/configs/P1020RDB-PC_36BIT_defconfig b/configs/P1020RDB-PC_36BIT_defconfig
> > index ce0ba0e37574..e60c92cedae9 100644
> > --- a/configs/P1020RDB-PC_36BIT_defconfig
> > +++ b/configs/P1020RDB-PC_36BIT_defconfig
> > @@ -21,7 +21,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig
> > index aae886b75c4e..f0f0eee65d29 100644
> > --- a/configs/P1020RDB-PC_defconfig
> > +++ b/configs/P1020RDB-PC_defconfig
> > @@ -20,7 +20,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P1020RDB-PD_defconfig b/configs/P1020RDB-PD_defconfig
> > index 5fecb6684735..8b7f9310b1a4 100644
> > --- a/configs/P1020RDB-PD_defconfig
> > +++ b/configs/P1020RDB-PD_defconfig
> > @@ -20,7 +20,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P2020RDB-PC_36BIT_defconfig b/configs/P2020RDB-PC_36BIT_defconfig
> > index b1dbca6e7ea3..1640f2379863 100644
> > --- a/configs/P2020RDB-PC_36BIT_defconfig
> > +++ b/configs/P2020RDB-PC_36BIT_defconfig
> > @@ -21,7 +21,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > diff --git a/configs/P2020RDB-PC_defconfig b/configs/P2020RDB-PC_defconfig
> > index 1ee46f9fbe9f..ca9f44728845 100644
> > --- a/configs/P2020RDB-PC_defconfig
> > +++ b/configs/P2020RDB-PC_defconfig
> > @@ -20,7 +20,7 @@ CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> >  CONFIG_OF_BOARD_SETUP=y
> >  CONFIG_OF_STDOUT_VIA_ALIAS=y
> > -CONFIG_FSL_FIXED_MMC_LOCATION=y
> > +CONFIG_NO_PBL=y
> >  CONFIG_BOOTDELAY=10
> >  CONFIG_USE_BOOTCOMMAND=y
> >  CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/$bdev rw rootdelay=30 console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr"
> > 
> > -- 
> > Tom
> 
> 

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Pali Rohár]

And back to this issue...

On Tuesday 02 August 2022 11:13:38 Pali Rohár wrote:
> Hello Tom!
> 
> Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> 
> If you look at P1020RDB-PD_defconfig file change in this commit there is:
> 
> --- a/configs/P1020RDB-PD_defconfig
> +++ b/configs/P1020RDB-PD_defconfig
> @@ -9,6 +9,7 @@ CONFIG_MPC85xx=y
>  # CONFIG_CMD_ERRATA is not set
>  CONFIG_TARGET_P1020RDB_PD=y
>  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
> +CONFIG_SYS_MPC85XX_NO_RESETVEC=y
>  CONFIG_MP=y
>  CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
> 
> Which does not make sense to me.
> 
> First thing is that CONFIG_MPC85XX_HAVE_RESET_VECTOR and
> CONFIG_SYS_MPC85XX_NO_RESETVEC are exclusive options. You can either
> disable generating of reset vector in image or enable it. What is
> expected from the result when you ask Kconfig to both enable and disable
> it? First specified option win? Or last specified win? Or random of
> those two options win? It is not really clear for me.

Experiments proved that CONFIG_SYS_MPC85XX_NO_RESETVEC wins over
CONFIG_MPC85XX_HAVE_RESET_VECTOR. So problematic commit
de47ff536363289f92f85ed1e4901724d238432d effectively disabled reset
vectors in more defconfig files.

> Second thing is that reset vector is required for (parallel) NOR booting
> and your change is adding CONFIG_SYS_MPC85XX_NO_RESETVEC=y to defconfig
> for NOR, which to my guess make image non-bootable and broken.

And this is truth. CONFIG_SYS_MPC85XX_NO_RESETVEC=y in defconfig broke
booting from parallel FLASH NOR memory. Without reset vector, u-boot
from FLASH cannot be booted.

When I manually disabled CONFIG_SYS_MPC85XX_NO_RESETVEC for P2020 then
together with CONFIG_SDCARD fix, I was able to boot U-Boot from FLASH.

So kconfig conversion in commit de47ff536363289f92f85ed1e4901724d238432d
was done incorrectly. Because in 2022.04 CONFIG_SYS_MPC85XX_NO_RESETVEC
was really not enabled in config.h for FLASH defconfigs.

> And seems that other defconfig files in that change have similar issues.

Tom, would you fix this commit de47ff536363289f92f85ed1e4901724d238432d
too? I do not know how you did that kconfig conversion but fix could be
straightforward. By boolean logic CONFIG_MPC85XX_HAVE_RESET_VECTOR xor
CONFIG_SYS_MPC85XX_NO_RESETVEC can be defined. Not both at the same
time.

By moveconfig.py following defconfigs are affected:

$ ./tools/moveconfig.py -f MPC85XX_HAVE_RESET_VECTOR SYS_MPC85XX_NO_RESETVEC
9 matches
P1020RDB-PC P1010RDB-PB_36BIT_NOR P1010RDB-PA_36BIT_NOR P1020RDB-PC_36BIT P1010RDB-PA_NOR P1010RDB-PB_NOR P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PD

All of these defconfigs (by their names) boot from FLASH nor, so they
must have reset vector included and so *NO_RESETVEC* must *not* be
enabled. (Hope it is clear even with too many negations)

Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]

On Wed, Dec 28, 2022 at 05:50:43PM +0100, Pali Rohár wrote:
> And back to this issue...
> 
> On Tuesday 02 August 2022 11:13:38 Pali Rohár wrote:
> > Hello Tom!
> > 
> > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > 
> > If you look at P1020RDB-PD_defconfig file change in this commit there is:
> > 
> > --- a/configs/P1020RDB-PD_defconfig
> > +++ b/configs/P1020RDB-PD_defconfig
> > @@ -9,6 +9,7 @@ CONFIG_MPC85xx=y
> >  # CONFIG_CMD_ERRATA is not set
> >  CONFIG_TARGET_P1020RDB_PD=y
> >  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
> > +CONFIG_SYS_MPC85XX_NO_RESETVEC=y
> >  CONFIG_MP=y
> >  CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> > 
> > Which does not make sense to me.
> > 
> > First thing is that CONFIG_MPC85XX_HAVE_RESET_VECTOR and
> > CONFIG_SYS_MPC85XX_NO_RESETVEC are exclusive options. You can either
> > disable generating of reset vector in image or enable it. What is
> > expected from the result when you ask Kconfig to both enable and disable
> > it? First specified option win? Or last specified win? Or random of
> > those two options win? It is not really clear for me.
> 
> Experiments proved that CONFIG_SYS_MPC85XX_NO_RESETVEC wins over
> CONFIG_MPC85XX_HAVE_RESET_VECTOR. So problematic commit
> de47ff536363289f92f85ed1e4901724d238432d effectively disabled reset
> vectors in more defconfig files.
> 
> > Second thing is that reset vector is required for (parallel) NOR booting
> > and your change is adding CONFIG_SYS_MPC85XX_NO_RESETVEC=y to defconfig
> > for NOR, which to my guess make image non-bootable and broken.
> 
> And this is truth. CONFIG_SYS_MPC85XX_NO_RESETVEC=y in defconfig broke
> booting from parallel FLASH NOR memory. Without reset vector, u-boot
> from FLASH cannot be booted.
> 
> When I manually disabled CONFIG_SYS_MPC85XX_NO_RESETVEC for P2020 then
> together with CONFIG_SDCARD fix, I was able to boot U-Boot from FLASH.
> 
> So kconfig conversion in commit de47ff536363289f92f85ed1e4901724d238432d
> was done incorrectly. Because in 2022.04 CONFIG_SYS_MPC85XX_NO_RESETVEC
> was really not enabled in config.h for FLASH defconfigs.
> 
> > And seems that other defconfig files in that change have similar issues.
> 
> Tom, would you fix this commit de47ff536363289f92f85ed1e4901724d238432d
> too? I do not know how you did that kconfig conversion but fix could be
> straightforward. By boolean logic CONFIG_MPC85XX_HAVE_RESET_VECTOR xor
> CONFIG_SYS_MPC85XX_NO_RESETVEC can be defined. Not both at the same
> time.
> 
> By moveconfig.py following defconfigs are affected:
> 
> $ ./tools/moveconfig.py -f MPC85XX_HAVE_RESET_VECTOR SYS_MPC85XX_NO_RESETVEC
> 9 matches
> P1020RDB-PC P1010RDB-PB_36BIT_NOR P1010RDB-PA_36BIT_NOR P1020RDB-PC_36BIT P1010RDB-PA_NOR P1010RDB-PB_NOR P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PD
> 
> All of these defconfigs (by their names) boot from FLASH nor, so they
> must have reset vector included and so *NO_RESETVEC* must *not* be
> enabled. (Hope it is clear even with too many negations)

Yes, I'll look at this again. My first observation is that the
exhaustive list of incorrectly migrated platforms listed there is ALSO
the list of platforms that had SDCARD/SPIFLASH enabled, when they
shouldn't have and now have NO_PBL set, So, that being set wrong meant
that the part here was wrong.  I think the answer might be to just fix
those configs, and then also add a "depends on
!MPC85XX_HAVE_RESET_VECTOR" to the *SYS_MPC85XX_NO_RESETVEC options.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Broken socrates board (Was: Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d)

[Pali Rohár]

On Wednesday 28 December 2022 17:50:43 Pali Rohár wrote:
> And back to this issue...
> 
> On Tuesday 02 August 2022 11:13:38 Pali Rohár wrote:
> > Hello Tom!
> > 
> > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > 
> > If you look at P1020RDB-PD_defconfig file change in this commit there is:
> > 
> > --- a/configs/P1020RDB-PD_defconfig
> > +++ b/configs/P1020RDB-PD_defconfig
> > @@ -9,6 +9,7 @@ CONFIG_MPC85xx=y
> >  # CONFIG_CMD_ERRATA is not set
> >  CONFIG_TARGET_P1020RDB_PD=y
> >  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
> > +CONFIG_SYS_MPC85XX_NO_RESETVEC=y
> >  CONFIG_MP=y
> >  CONFIG_FIT=y
> >  CONFIG_FIT_VERBOSE=y
> > 
> > Which does not make sense to me.
> > 
> > First thing is that CONFIG_MPC85XX_HAVE_RESET_VECTOR and
> > CONFIG_SYS_MPC85XX_NO_RESETVEC are exclusive options. You can either
> > disable generating of reset vector in image or enable it. What is
> > expected from the result when you ask Kconfig to both enable and disable
> > it? First specified option win? Or last specified win? Or random of
> > those two options win? It is not really clear for me.
> 
> Experiments proved that CONFIG_SYS_MPC85XX_NO_RESETVEC wins over
> CONFIG_MPC85XX_HAVE_RESET_VECTOR. So problematic commit
> de47ff536363289f92f85ed1e4901724d238432d effectively disabled reset
> vectors in more defconfig files.
> 
> > Second thing is that reset vector is required for (parallel) NOR booting
> > and your change is adding CONFIG_SYS_MPC85XX_NO_RESETVEC=y to defconfig
> > for NOR, which to my guess make image non-bootable and broken.
> 
> And this is truth. CONFIG_SYS_MPC85XX_NO_RESETVEC=y in defconfig broke
> booting from parallel FLASH NOR memory. Without reset vector, u-boot
> from FLASH cannot be booted.
> 
> When I manually disabled CONFIG_SYS_MPC85XX_NO_RESETVEC for P2020 then
> together with CONFIG_SDCARD fix, I was able to boot U-Boot from FLASH.
> 
> So kconfig conversion in commit de47ff536363289f92f85ed1e4901724d238432d
> was done incorrectly. Because in 2022.04 CONFIG_SYS_MPC85XX_NO_RESETVEC
> was really not enabled in config.h for FLASH defconfigs.
> 
> > And seems that other defconfig files in that change have similar issues.
> 
> Tom, would you fix this commit de47ff536363289f92f85ed1e4901724d238432d
> too? I do not know how you did that kconfig conversion but fix could be
> straightforward. By boolean logic CONFIG_MPC85XX_HAVE_RESET_VECTOR xor
> CONFIG_SYS_MPC85XX_NO_RESETVEC can be defined. Not both at the same
> time.
> 
> By moveconfig.py following defconfigs are affected:
> 
> $ ./tools/moveconfig.py -f MPC85XX_HAVE_RESET_VECTOR SYS_MPC85XX_NO_RESETVEC
> 9 matches
> P1020RDB-PC P1010RDB-PB_36BIT_NOR P1010RDB-PA_36BIT_NOR P1020RDB-PC_36BIT P1010RDB-PA_NOR P1010RDB-PB_NOR P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PD

And there is one _interesting_ board:

$ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //'`; do ./tools/moveconfig.py -f $arch ~MPC85XX_HAVE_RESET_VECTOR ~SYS_MPC85XX_NO_RESETVEC; done | grep -v ' matches\|^$'
socrates

(I do not know how to easily tell moveconfig.py to do OR, so I called in
more times in loop).

socrates_defconfig is the only one mpc85xx board which does not have
enabled reset vectors nor disabled reset vectors.

As it boots from flash too, it should have reset vector in its binary.
I have looked into compiled u-boot ELF binary and reset vector is there.
So good.

But in u-boot.bin binary it is not, so it is broken.

Checking with v2022.04 release and it is quite interesting. U-Boot build
process produce more *.bin binaries:

-rw-r--r-- 1 pali pali 530613 dec 28 17:57 u-boot.bin
-rw-r--r-- 1 pali pali 530613 dec 28 17:57 u-boot-dtb.bin
-rwxr-xr-x 1 pali pali 524288 dec 28 17:57 u-boot-nodtb.bin
-rw-r--r-- 1 pali pali 655360 dec 28 17:57 u-boot-socrates.bin

u-boot.bin and u-boot-dtb.bin are broken. u-boot-nodtb.bin is
intermediate and u-boot-socrates.bin seems to be correct (contains reset
vector at correct offset and also has DTB file in it).

U-Boot master build only broken u-boot.bin and does *not* build correct
u-boot-socrates.bin.

I bisected this issue why u-boot-socrates.bin stopped being building.
And reason is my commit 5af42eafd7e1 ("Makefile: Reduce usage of custom
mpc85xx u-boot.bin target"). It is binman who built "correct" binary and
that commit deselected it.

I looked again at CONFIG_MPC85XX_HAVE_RESET_VECTOR symbol and its
meaning is currently "build only intermediate binaries for binman,
separate one for u-boot main code, separate one for reset vector,
separate for DTB and let binman to merge them via standard powerpc
config binman file arch/powerpc/dts/u-boot.dtsi to output u-boot.bin."

From the code, this socrates is expected to build final binary
u-boot-socrates.bin (not u-boot.bin) via binman, but not via common
powerpc u-boot.dtsi, but rather via arch/powerpc/dts/socrates-u-boot.dtsi
So it does not use CONFIG_MPC85XX_HAVE_RESET_VECTOR symbol (which is
just for common powerpc binman stage).

I'm going to send a fix for socrates, so build process start again
building u-boot-socrates.bin binary and let it to v2022.04 state.

The long term solution for socrates should be:
1) Stop building broken and unused u-boot.bin
2) Rename u-boot-socrates.bin to u-boot.bin

PS: Similarly is broken also keymile board, but for this one I had
realized that is "custom" and months ago I sent patch for it for
conversion to use common powerpc binman rule, even before commit
5af42eafd7e1 which broke both keymile and socrates:
https://patchwork.ozlabs.org/project/uboot/patch/20220803112049.4287-1-pali@kernel.org/

> All of these defconfigs (by their names) boot from FLASH nor, so they
> must have reset vector included and so *NO_RESETVEC* must *not* be
> enabled. (Hope it is clear even with too many negations)

Re: Broken socrates board (Was: Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d)

[Simon Glass]

Hi Pali,

On Wed, 28 Dec 2022 at 11:51, Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 28 December 2022 17:50:43 Pali Rohár wrote:
> > And back to this issue...
> >
> > On Tuesday 02 August 2022 11:13:38 Pali Rohár wrote:
> > > Hello Tom!
> > >
> > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > >
> > > If you look at P1020RDB-PD_defconfig file change in this commit there is:
> > >
> > > --- a/configs/P1020RDB-PD_defconfig
> > > +++ b/configs/P1020RDB-PD_defconfig
> > > @@ -9,6 +9,7 @@ CONFIG_MPC85xx=y
> > >  # CONFIG_CMD_ERRATA is not set
> > >  CONFIG_TARGET_P1020RDB_PD=y
> > >  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
> > > +CONFIG_SYS_MPC85XX_NO_RESETVEC=y
> > >  CONFIG_MP=y
> > >  CONFIG_FIT=y
> > >  CONFIG_FIT_VERBOSE=y
> > >
> > > Which does not make sense to me.
> > >
> > > First thing is that CONFIG_MPC85XX_HAVE_RESET_VECTOR and
> > > CONFIG_SYS_MPC85XX_NO_RESETVEC are exclusive options. You can either
> > > disable generating of reset vector in image or enable it. What is
> > > expected from the result when you ask Kconfig to both enable and disable
> > > it? First specified option win? Or last specified win? Or random of
> > > those two options win? It is not really clear for me.
> >
> > Experiments proved that CONFIG_SYS_MPC85XX_NO_RESETVEC wins over
> > CONFIG_MPC85XX_HAVE_RESET_VECTOR. So problematic commit
> > de47ff536363289f92f85ed1e4901724d238432d effectively disabled reset
> > vectors in more defconfig files.
> >
> > > Second thing is that reset vector is required for (parallel) NOR booting
> > > and your change is adding CONFIG_SYS_MPC85XX_NO_RESETVEC=y to defconfig
> > > for NOR, which to my guess make image non-bootable and broken.
> >
> > And this is truth. CONFIG_SYS_MPC85XX_NO_RESETVEC=y in defconfig broke
> > booting from parallel FLASH NOR memory. Without reset vector, u-boot
> > from FLASH cannot be booted.
> >
> > When I manually disabled CONFIG_SYS_MPC85XX_NO_RESETVEC for P2020 then
> > together with CONFIG_SDCARD fix, I was able to boot U-Boot from FLASH.
> >
> > So kconfig conversion in commit de47ff536363289f92f85ed1e4901724d238432d
> > was done incorrectly. Because in 2022.04 CONFIG_SYS_MPC85XX_NO_RESETVEC
> > was really not enabled in config.h for FLASH defconfigs.
> >
> > > And seems that other defconfig files in that change have similar issues.
> >
> > Tom, would you fix this commit de47ff536363289f92f85ed1e4901724d238432d
> > too? I do not know how you did that kconfig conversion but fix could be
> > straightforward. By boolean logic CONFIG_MPC85XX_HAVE_RESET_VECTOR xor
> > CONFIG_SYS_MPC85XX_NO_RESETVEC can be defined. Not both at the same
> > time.
> >
> > By moveconfig.py following defconfigs are affected:
> >
> > $ ./tools/moveconfig.py -f MPC85XX_HAVE_RESET_VECTOR SYS_MPC85XX_NO_RESETVEC
> > 9 matches
> > P1020RDB-PC P1010RDB-PB_36BIT_NOR P1010RDB-PA_36BIT_NOR P1020RDB-PC_36BIT P1010RDB-PA_NOR P1010RDB-PB_NOR P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PD
>
> And there is one _interesting_ board:
>
> $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 's/.* //'`; do ./tools/moveconfig.py -f $arch ~MPC85XX_HAVE_RESET_VECTOR ~SYS_MPC85XX_NO_RESETVEC; done | grep -v ' matches\|^$'
> socrates
>
> (I do not know how to easily tell moveconfig.py to do OR, so I called in
> more times in loop).
>
> socrates_defconfig is the only one mpc85xx board which does not have
> enabled reset vectors nor disabled reset vectors.
>
> As it boots from flash too, it should have reset vector in its binary.
> I have looked into compiled u-boot ELF binary and reset vector is there.
> So good.
>
> But in u-boot.bin binary it is not, so it is broken.
>
> Checking with v2022.04 release and it is quite interesting. U-Boot build
> process produce more *.bin binaries:
>
> -rw-r--r-- 1 pali pali 530613 dec 28 17:57 u-boot.bin
> -rw-r--r-- 1 pali pali 530613 dec 28 17:57 u-boot-dtb.bin
> -rwxr-xr-x 1 pali pali 524288 dec 28 17:57 u-boot-nodtb.bin
> -rw-r--r-- 1 pali pali 655360 dec 28 17:57 u-boot-socrates.bin
>
> u-boot.bin and u-boot-dtb.bin are broken. u-boot-nodtb.bin is
> intermediate and u-boot-socrates.bin seems to be correct (contains reset
> vector at correct offset and also has DTB file in it).
>
> U-Boot master build only broken u-boot.bin and does *not* build correct
> u-boot-socrates.bin.
>
> I bisected this issue why u-boot-socrates.bin stopped being building.
> And reason is my commit 5af42eafd7e1 ("Makefile: Reduce usage of custom
> mpc85xx u-boot.bin target"). It is binman who built "correct" binary and
> that commit deselected it.
>
> I looked again at CONFIG_MPC85XX_HAVE_RESET_VECTOR symbol and its
> meaning is currently "build only intermediate binaries for binman,
> separate one for u-boot main code, separate one for reset vector,
> separate for DTB and let binman to merge them via standard powerpc
> config binman file arch/powerpc/dts/u-boot.dtsi to output u-boot.bin."
>
> From the code, this socrates is expected to build final binary
> u-boot-socrates.bin (not u-boot.bin) via binman, but not via common
> powerpc u-boot.dtsi, but rather via arch/powerpc/dts/socrates-u-boot.dtsi
> So it does not use CONFIG_MPC85XX_HAVE_RESET_VECTOR symbol (which is
> just for common powerpc binman stage).
>
> I'm going to send a fix for socrates, so build process start again
> building u-boot-socrates.bin binary and let it to v2022.04 state.
>
> The long term solution for socrates should be:
> 1) Stop building broken and unused u-boot.bin

Just a note on this...that file is produced by all boards. If a board
needs to create another file, e.g. u-boot-rockchip.bin then that is
fine. But the u-boot.bin file should remain.

> 2) Rename u-boot-socrates.bin to u-boot.bin

Please don't do that!

>
> PS: Similarly is broken also keymile board, but for this one I had
> realized that is "custom" and months ago I sent patch for it for
> conversion to use common powerpc binman rule, even before commit
> 5af42eafd7e1 which broke both keymile and socrates:
> https://patchwork.ozlabs.org/project/uboot/patch/20220803112049.4287-1-pali@kernel.org/
>
> > All of these defconfigs (by their names) boot from FLASH nor, so they
> > must have reset vector included and so *NO_RESETVEC* must *not* be
> > enabled. (Hope it is clear even with too many negations)

Regards,
Simon