[U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected

Miquel Raynal miquel.raynal at bootlin.com
Wed Dec 5 14:32:18 UTC 2018


Hi Wolfgang,

Wolfgang Denk <wd at denx.de> wrote on Wed, 05 Dec 2018 13:06:10 +0100:

> Dear Miquel,
> 
> In message <20181204235714.11805-14-miquel.raynal at bootlin.com> you wrote:
> > MTD support must be enabled when the environment is in NOR.  
> 
> Naked-by: Wolfgang Denk <wd at denx.de>
> 
> Environment in NOR must not, I repeat: must not ever depend on MTD!
> 
> For more than 19 years we have been using environment in NOR flash
> without the need for MTD support, which makes a lot of sense
> especially on smaller systems where resources are low and MTD is an
> expensive, but not really needed feature.
> 
> It is not acceptable to create a dependency that costs so much.

I took a rather small configuration: stm32f429-discovery_defconfig
which uses CONFIG_MTD_NOR_FLASH. Without CONFIG_MTD, u-boot.bin is
209416 bytes. With CONFIG_MTD, u-boot.bin is 214540 bytes. This is an
additional 5124 bytes which represent about 2% of the entire size.

I am talking about U-Boot only, there is a CONFIG_SPL_MTD_SUPPORT
option that must be enabled to compile MTD in the SPL so the change
I propose do not enlarge the SPL.

Today, there are multiple boards having more than one type of MTD
device (eg. raw NAND and SPI-NOR). In this case you need to compile two
commands which interface only with the subsystem they have been written
for. We propose to kill this approach and instead use an 'mtd' command
which shares the same code for all MTD devices: less duplication, more
users, and in the end, a reduced size. And I am not event talking about
all the code that has been added over the years to "avoid using MTD"
which enlarges the binary as well.

The current situation is unmaintainable. Any change in U-Boot under the
drivers/mtd/ directory results in hours of debugging to fix broken
dependencies and crappy configurations. It took me one week to port the
SPI-mem/SPI-NAND layers (which rely on MTD) and to have a working 'mtd'
command. It took me and Boris almost 4 weeks to fix the fallouts. Now,
either we keep U-Boot MTD subsystem maintainable and in sync as much as
possible with Linux to continue to benefit from
evolutions/drivers/fixes at the cost of a little overhead, or we
continue in the current path, with the results we know.


Thanks,
Miquèl


More information about the U-Boot mailing list