Dear Miquel, In message <20181205153218.36f6ed4e@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: [email protected] An expert is a person who avoids the small errors while sweeping on to the grand fallacy. _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
