Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

Sat Dec 24 17:13:41 CET 2022

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221224/8502f459/attachment.sig>