Hi Vignesh, > >> While I think porting this from Linux is the right thing to do, I can't > >> say I'm happy with losing yet another 2.5 kB for SPL when it is already > >> too stuffed to add secure boot via FIT signatures. > > > > Indeed. Can we somehow trim things down a bit for SPL ? > > > > I am able to trim overall size delta to within 1KB for porter_defconfig. > Pushed new set of patches to github[1] > > With new this new SF framework and porter_defconfig: > size spl/u-boot-spl > text data bss dec hex filename > 15749 184 1100 17033 4289 spl/u-boot-spl > > Current mainline: > size spl/u-boot-spl > text data bss dec hex filename > 14881 184 1100 16165 3f25 spl/u-boot-spl > > Typical increase in code delta is ~1K to ~1.2KB wrt SPL on different > platforms depending on flash devices supports enabled. > > I am not sure if its possible to trim this down further, as there is > addition of new code to handle 4 Byte addressing feature and moving to > spi-mem framework to support direct mapping capable SPI controllers. > These features will add to code size and I hope that's an acceptable > tradeoff. > > I believe, once SPI NOR is completely integrated with MTD framework, > there will be some size reduction(such as due to getting rid of sf_mtd.c > and spi_flash_* APIs completely. Also, loading of U-Boot images across > NAND/SPI NOR can be consolidated).
There are already multiple SPL-specific drivers out there. While I don't see a problem building MTD in U-Boot, I wonder if building MTD in the SPL is a good idea. Instead, Why not just build a tiny "SPL MTD stack", a lightweight MTD stack just with minimal features? > > I will post revised patches to mailing list after travis ci report. > > [1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-v2 > Thanks, Miquèl _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
