On 05.12.18 15:32, Miquel Raynal wrote: > Hi Wolfgang, > > Wolfgang Denk <w...@denx.de> wrote on Wed, 05 Dec 2018 13:06:10 +0100: > >> Dear Miquel, >> >> In message <20181204235714.11805-14-miquel.ray...@bootlin.com> you wrote: >>> MTD support must be enabled when the environment is in NOR. >> >> Naked-by: Wolfgang Denk <w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
