Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2
Pali Rohár
pali at kernel.org
Sat Dec 24 18:03:24 CET 2022
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.
More information about the U-Boot
mailing list