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
