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

[Schrempf Frieder]

On 05.12.18 15:32, Miquel Raynal wrote:
> 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.

I'm not really involved in U-Boot development, but watching the recent 
MTD changes and also from a user/board supplier point of view, I 
strongly support Miquèl's and Boris' approach.

Moving towards a unified MTD layer to replace all the historic solutions 
is definitely the right thing to do. Miquèl already mentioned the 
reasons in detail and saving a few bytes of binary size in my opinion 
does not justify enough for going without all the advantages.

Regards,
Frieder