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.
