[U-Boot] [RFC PATCH 4/6] porter_defconfig: Enable tiny printf

From: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 4/6] porter_defconfig: Enable tiny printf
Date: Thu, 29 Nov 2018 12:18:30 +0100	[thread overview]
Message-ID: <CAAh8qszFKazMv62B=6ShtpgbD9tXzkkn29DaXRLR_hnFDk-LNg@mail.gmail.com> (raw)
In-Reply-To: <20181129115637.1eb613de@xps13>

On Thu, Nov 29, 2018 at 11:56 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> 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 think that would be a good idea. Simple read access should probably
be enough for SPL to load U-Boot. That would free some space I need to
verify FIT signatures...

Simon

>
> >
> > 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