Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2

[Tom Rini]

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
-------------- 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/20221222/ede92c9f/attachment.sig>