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.