From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Wed, 5 Dec 2018 15:32:18 +0100 Subject: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected In-Reply-To: <20181205120610.79153242268@gemini.denx.de> References: <20181204235714.11805-1-miquel.raynal@bootlin.com> <20181204235714.11805-14-miquel.raynal@bootlin.com> <20181205120610.79153242268@gemini.denx.de> Message-ID: <20181205153218.36f6ed4e@xps13> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi Wolfgang, Wolfgang Denk wrote on Wed, 05 Dec 2018 13:06:10 +0100: > Dear Miquel, >=20 > In message <20181204235714.11805-14-miquel.raynal@bootlin.com> you wrote: > > MTD support must be enabled when the environment is in NOR. =20 >=20 > Naked-by: Wolfgang Denk >=20 > Environment in NOR must not, I repeat: must not ever depend on MTD! >=20 > 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. >=20 > 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=C3=A8l