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

[Wolfgang Denk]

Dear Miquel,

In message <20181205153218.36f6ed4e at xps13> you wrote:
>
> 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.

So it's a 5 k code increase for zero benefit.

> 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.

This is even worse - the SPL is frequently at the size limits.

Please understand that there is a fundamental difference between
parallel NOR flash and things like NAND, SPI NOR etc. - the latter
are storage devices, which are usually handled as block device or
similar, i. e. you always need a driver to read data.  Parallel NOR
is not storage, it is _memory_, which is directly mapped int o
memory. You can execute code from it.

Reading data from parallel NOR comes at zero overhead (except maybe
for setting up the memory controller to map the NOR into the address
space).

Adding a dependency on the MTD layer is broken.

> 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.

This is perfectly fine.  But you must not break fundamental features
that have been there ever since the beginning of the project.

Simple things - like reading the environment from parallel NOR
(which boils down to calling ofa memcpy()) must not be bloated with
unneeded layers like MTD - even if these are needed and useful
elsewhere.

Please do not understand me wrong: I fully agree with the MTD rework
in general, and I'm happy to see it happen.  But please do it in a
way not to break existing basic use cases.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.