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/... 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.