[U-Boot] [PATCH v5 00/26]MTD defconfigs/Kconfigs/Makefiles heavy cleanup
Tom Rini
trini at konsulko.com
Thu Dec 5 03:50:50 CET 2019
On Thu, Oct 03, 2019 at 07:50:02PM +0200, Miquel Raynal wrote:
> Hello,
>
> A year ago, while working on SPI-NAND support in U-Boot, I discovered
> when modifying Makefiles a confusing organization where:
> * Sub-directories/files are compiled from the root Makefile
> * Commands are at the root of everything
>
> First I sent a series to move Makefile entries in their respective
> directories. Then, I decided to continue working on the clarification
> of the Makefile hierarchy in MTD and I sent four iterations of this
> series which did not got merge at that time. Anyway, I revived this
> series by rebasing all my work and updating everything that needed an
> update.
>
> Here are the main points of the re-organization:
> * Rename CONFIG_MTD into CONFIG_DM_MTD to reserve CONFIG_MTD to what
> is called today CONFIG_MTD_DEVICE.
> * Fix build dependencies in defconfigs, like: "UBI and NAND depend on MTD".
> * Fix the Kconfig files to reflect these dependencies (as defconfigs
> have been updated, nothing should break).
> * Simplify the Makefiles: compiling the drivers/mtd/nand/raw/
> sub-directory should just depend on MTD being compiled and the NAND
> core as well, there is absolutely no logic to make it depend on
> CMD_NAND.
>
> The New green Travis CI build for the fifth version of this series is
> there (yes, 53 iterations):
>
> Please note that the only red test fails because of timeout, not an
> actual error (at least I could not spot it). It is possible that this
> series will produce noticeable changes for the users. The only reason
> for that is because their configuration file was wrong. I have done my
> best to fix them one by one, but I am not omniscient.
>
> Thanks,
> Miquèl
>
>
> Note: as the number of Cc:'ed people reached 184 with
> get_maintainers.pl I decided to trim the list to:
> * People interested by the MTD subsystem.
> * A few maintainers: I had to tweak some defconfigs after more digging
> than with other boards (k2g, bcm11130, M54418TWR,
> ls104/108/208). Maintainers of these platforms are Cc:'ed.
>
>
> Changes since v4:
> =================
> * Rebased on top of v2019.10-rc4.
> * Fixed tens of configurations that got broken since the last version
> of this series several months ago.
> * Added a specific commit for ls104/108/208 configurations.
>
> Changes since v3:
> =================
> * As suggested by Vignesh, SPI_FLASH_MTD depends on MTD. Enforce this
> in Kconfig with a new patch. There is no defconfig to fix, all
> defconfigs with SPI_FLASH_MTD already use MTD.
> * s/coherent Makefile/appropriate Makefile/ in commit title of patch 1.
> * s/Kconfig/Makefile in commit message of "mtd: nand: remove
> dependency on commands in Kconfig" and "mtd: ubi: remove dependency
> on command in Kconfig".
> * Add Boris R-b tags.
> * Correct typos pointed by Boris.
> * Remove the if/endif in cmd/Kconfig about mtdparts, let the "depends
> on" that was already present.
> * Use an if/endif block to compile legacy-mtd-utils.c (to avoid
> failures when both 'sf' and 'nand' commands are compiled-in).
> * Merge all Makefile changes in one consistent commit as suggested by
> Boris.
>
> Changes since v2:
> =================
> * Cleanup also applied to the SPL in an additional patch.
> * NOR dependency on MTD extracted from the patch adding MTD
> dependencies on commands only to do it in a separate change.
> * Typo s/copile/compile/ in "rename CONFIG_MTD_DEVICE..." commit log.
> * No more MTD depencency on SPI_FLASH, only kept on SPI_FLASH_MTD.
> * Same applies to the sf command.
> * Avoid compiling the NAND core while it is not needed (not speaking
> about the raw NAND core, really what is in drivers/mtd/nand:).
> * Last patch dropping CONFIG_MTD_PARTITIONS forgotten. We need them in
> order to reduce the final binary size.
> * Additional fixes in cmd/Kconfig.
>
> Changes since v1:
> =================
> * Squashed both patches from the first series and included them in
> "mtd: simplify Makefiles".
> * Added all other patches.
> * Renamed CONFIG_NAND into CONFIG_MTD_RAW_NAND as suggested.
>
>
> Miquel Raynal (26):
> mtd: rename CONFIG_NAND -> CONFIG_MTD_RAW_NAND
> mtd: rename CONFIG_MTD -> CONFIG_DM_MTD
> mtd: rename CONFIG_MTD_DEVICE -> CONFIG_MTD
> mtd: ensure MTD is compiled when there is a NOR flash
> mtd: ensure MTD/the raw NAND core are compiled when there is a NAND
> flash
> mtd: ensure MTD is compiled when there is a SPI NOR flash using MTD
> mtd: ensure UBI is compiled when using fastmap
> mtd: ensure MTD is compiled when UBI is used
> mtd: ensure UBI is compiled when CMD_UBI is selected
> mtd: ensure UBI is compiled when ENV_IS_IN_UBI is selected
> mtd: ensure MTD_RAW_NAND is compiled when ENV_IS_IN_NAND is selected
> mtd: ensure CMD_NAND is compiled when its options are selected
> mtd: ensure MTD is compiled when CMD_MTDPARTS is selected
> configs: move CONFIG_MTD in defconfigs when set in arch includes
> configs: remove raw NAND core from k2g defconfigs
> configs: remove MTD support from bcm11130 and M54418TWR defconfigs
> configs: socfpga: mcvevk: Remove useless UBI infos
> configs: ls104x/ls108x/ls208x: Build the raw NAND core with TFABOOT
> mtd: nand: add includes in NAND core to avoid warnings
> dfu: add dependency on the raw NAND core
> mtd: nor: NOR flashes depend on MTD
> mtd: spi: SPI_FLASH_MTD depends on MTD
> cmd: mtdparts: Kconfig: join mtdparts command entry with its options
> cmd: nand/sf: isolate legacy code
> cmd: make MTD commands depend on MTD
> mtd: Makefile: deep cleanup
So, a feature of this series is that it exposes a problem of the
following PowerPC configurations:
P1022DS P1022DS_SDCARD P1022DS_SPIFLASH P1022DS_36BIT_SPIFLASH
P1022DS_36BIT P1022DS_36BIT_SDCARD T4240QDS_SRIO_PCIE_BOOT
T4240QDS_SDCARD T4160QDS_SECURE_BOOT T4160QDS T4240QDS T4160QDS_SDCARD
T4240QDS_SECURE_BOOT B4860QDS_SECURE_BOOT T4160RDB B4420QDS B4860QDS
B4860QDS_SRIO_PCIE_BOOT B4860QDS_SPIFLASH B4420QDS_SPIFLASH
T4240RDB_SDCARD T4240RDB P1025RDB_SPIFLASH P1025RDB_SDCARD
P1024RDB_SPIFLASH P1025RDB P1024RDB_SDCARD P1024RDB P1024RDB_36BIT
P1025RDB_36BIT P5020DS_SECURE_BOOT P3041DS_SRIO_PCIE_BOOT
P3041DS_SECURE_BOOT P5020DS_SDCARD P5020DS P5020DS_SRIO_PCIE_BOOT
P5020DS_SPIFLASH P5040DS_SECURE_BOOT P2041RDB_SECURE_BOOT
P2041RDB_SRIO_PCIE_BOOT P1021RDB-PC_SPIFLASH P1021RDB-PC
P1021RDB-PC_SDCARD P1021RDB-PC_36BIT_SPIFLASH P1021RDB-PC_36BIT_SDCARD
P1021RDB-PC_36BIT P1020RDB-PC_SDCARD P1020RDB-PC_SPIFLASH P1020RDB-PC
P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PC_36BIT_SDCARD P1020RDB-PC_36BIT
P5040DS_SDCARD P3041DS_SPIFLASH P3041DS_SDCARD P5040DS P5040DS_SPIFLASH
P2041RDB P2041RDB_SDCARD P2041RDB_SPIFLASH P3041DS P1020RDB-PD_SDCARD
P2020RDB-PC_SPIFLASH P1020RDB-PD P2020RDB-PC P2020RDB-PC_SDCARD
P1020RDB-PD_SPIFLASH P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SPIFLASH
P2020RDB-PC_36BIT_SDCARD C29XPCIE_NOR_SECBOOT C29XPCIE_SPIFLASH
C29XPCIE_SPIFLASH_SECBOOT C29XPCIE BSC9132QDS_SDCARD_DDRCLK133_SECURE
BSC9132QDS_NOR_DDRCLK133_SECURE BSC9132QDS_SDCARD_DDRCLK100_SECURE
BSC9132QDS_NOR_DDRCLK100_SECURE BSC9132QDS_SPIFLASH_DDRCLK133_SECURE
BSC9132QDS_SPIFLASH_DDRCLK100_SECURE BSC9132QDS_NOR_DDRCLK100
BSC9132QDS_SPIFLASH_DDRCLK133 BSC9132QDS_NAND_DDRCLK133_SECURE
BSC9132QDS_NOR_DDRCLK133 BSC9132QDS_SDCARD_DDRCLK100
BSC9132QDS_SPIFLASH_DDRCLK100 BSC9132QDS_NAND_DDRCLK100_SECURE
BSC9132QDS_SDCARD_DDRCLK133 P1010RDB-PA_SPIFLASH_SECBOOT
P1010RDB-PA_NAND_SECBOOT P1010RDB-PA_SPIFLASH P1010RDB-PA_NOR
P1010RDB-PA_SDCARD BSC9131RDB_SPIFLASH_SYSCLK100 BSC9131RDB_SPIFLASH
P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_36BIT_NOR_SECBOOT
P1010RDB-PA_36BIT_NOR_SECBOOT P1010RDB-PA_36BIT_SPIFLASH_SECBOOT
P1010RDB-PA_36BIT_SDCARD P1010RDB-PA_36BIT_NAND_SECBOOT
T2081QDS_SRIO_PCIE_BOOT T2080RDB_SRIO_PCIE_BOOT T1024QDS_DDR4 T2081QDS
T1042RDB T1040RDB_SDCARD T1040RDB T2081QDS_SPIFLASH T1042RDB_PI_SDCARD
T1042D4RDB_SECURE_BOOT T1023RDB_SECURE_BOOT T1023RDB T1040RDB_SPIFLASH
T1040D4RDB_SDCARD T1023RDB_SDCARD T1042RDB_PI T1040D4RDB T2081QDS_SDCARD
T2080RDB_SECURE_BOOT T1042RDB_PI_SPIFLASH T1023RDB_SPIFLASH
T1040D4RDB_SPIFLASH T1040QDS_SECURE_BOOT T1040QDS
T1024QDS_DDR4_SECURE_BOOT T1040QDS_DDR4 T1024QDS_SDCARD T1024QDS
T1024QDS_SECURE_BOOT T1024RDB_SECURE_BOOT T1040D4RDB_SECURE_BOOT
T1040RDB_SECURE_BOOT T1042RDB_SECURE_BOOT T1024QDS_SPIFLASH
T2080QDS_SRIO_PCIE_BOOT P1010RDB-PB_SPIFLASH_SECBOOT
P1010RDB-PB_NOR_SECBOOT P1010RDB-PB_SDCARD P1010RDB-PB_NAND_SECBOOT
P1010RDB-PB_SPIFLASH P1010RDB-PB_NOR P1010RDB-PB_36BIT_NOR
P1010RDB-PB_36BIT_NAND_SECBOOT P1010RDB-PB_36BIT_SPIFLASH_SECBOOT
P1010RDB-PB_36BIT_SDCARD P1010RDB-PB_36BIT_NOR_SECBOOT
P1010RDB-PB_36BIT_SPIFLASH T2080QDS_SECURE_BOOT T1042D4RDB
T1042D4RDB_SDCARD T2080RDB_SDCARD T2080RDB T1042D4RDB_SPIFLASH
T2080RDB_SPIFLASH T1024RDB_SDCARD T1024RDB T1024RDB_SPIFLASH
T2080QDS_SDCARD T2080QDS_SPIFLASH T2080QDS P1010RDB-PA_NOR_SECBOOT
And that is that before this series they do not fully enable NAND
support normally but do enable it partially and do enable CMD_NAND.
After this series they do not enable CMD_NAND. This is because if I do
enable CMD_NAND instead we see a large number of other changes wrt
things such as CONFIG_SYS_AMASK0/CONFIG_SYS_AMASK1 and change those
configs from pointing at NOR to pointing at NAND and that seems the
larger functional regression over removing the nand command. If the
NAND command really should be on in these boards then we do need to
figure out or otherwise rework the config files such that the rest of
the board functions the intended way still.
Also note that while there are a few *_NAND_* configs in that list,
investigation of the u-boot.cfg files shows that enabling
CONFIG_MTD_RAW_NAND (formerly CONFIG_NAND) leads to the other functional
changes noted above. My assumption currently is that those *_NAND_*
boards above have a latent bug that is now exposed.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191204/9c8cc262/attachment.sig>
More information about the U-Boot
mailing list