On Saturday 24 December 2022 11:13:41 Tom Rini wrote:
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.
-- Tom
This is probably reason why u-boot from master branch did not work during my yesterday tests.
I created list of macros from include/configs/* files which value depends on CONFIG_SDCARD:
BOOT_PAGE_OFFSET CONFIG_ENV_RANGE CONFIG_FSL_FIXED_MMC_LOCATION CONFIG_RAMBOOT_TEXT_BASE CONFIG_RESET_VECTOR_ADDRESS CONFIG_SPL_COMMON_INIT_DDR CONFIG_SPL_FLUSH_IMAGE CONFIG_SPL_GD_ADDR CONFIG_SPL_INIT_MINIMAL CONFIG_SPL_MAX_SIZE CONFIG_SPL_NAND_INIT CONFIG_SPL_PAD_TO CONFIG_SPL_RELOC_MALLOC_ADDR CONFIG_SPL_RELOC_MALLOC_SIZE CONFIG_SPL_RELOC_STACK CONFIG_SPL_RELOC_TEXT_BASE CONFIG_SPL_SKIP_RELOCATE CONFIG_SPL_SPI_FLASH_MINIMAL CONFIG_SPL_TARGET CONFIG_SYS_CCSR_DO_NOT_RELOCATE CONFIG_SYS_INIT_L2_ADDR CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_END CONFIG_SYS_L2_SIZE CONFIG_SYS_MMC_U_BOOT_DST CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SYS_MMC_U_BOOT_SIZE CONFIG_SYS_MMC_U_BOOT_START CONFIG_SYS_MPC85XX_NO_RESETVEC CONFIG_SYS_NAND_U_BOOT_DST CONFIG_SYS_NAND_U_BOOT_SIZE CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_SPI_FLASH_U_BOOT_DST CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE CONFIG_SYS_SPI_FLASH_U_BOOT_START CONFIG_TPL_PAD_TO RESET_VECTOR_OFFSET SPL_ENV_ADDR
So if they were migrated then probably have wrong values, undefined value or completely missing after migration.