On 11/29/2018 11:44 AM, Vignesh R wrote: > Hi Marek, Simon Hi,
> On 29/11/18 3:20 AM, Marek Vasut wrote: >> On 11/28/2018 09:34 PM, Simon Goldschmidt wrote: >>> On 28.11.2018 18:52, Marek Vasut wrote: >>>> On 11/28/2018 06:26 PM, Vignesh R wrote: >>>>> Enable tiny printf to reduce SPL foot print >>>> This should be enabled already on Gen2, no ? > > Right, its already enabled, please ignore this particular patch. I saw > sram overflow with this config when running buildman and therefore > though this change might help. > >>>> Anyway, what's the size growth on Gen2 with the new Linux SF framework ? >>> >>> After downloading the missing patch 1/6 from github and testing it on >>> socfpga gen5, my SPL got ~2500 byte larger. >>> > > I guess patch 1/6 took a bit more time to get across. I can see it in > patchworks: https://patchwork.ozlabs.org/patch/1004836/ > >>> 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. It's not really acceptable if the system cannot boot anymore since the SPL is larger than 16 kiB, which is the limit for this system. So this must be somehow made configurable or fixed. > 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). This doesn't help if there are systems which cannot boot in the meantime. > 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 > -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
