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