[U-Boot] Making U-Boot smaller

[Tom Rini]

On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
> On 5/21/19 9:53 PM, Tom Rini wrote:
> > On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
> >> On 5/21/19 6:56 PM, Jagan Teki wrote:
> >>> On Tue, May 21, 2019 at 10:14 PM Simon Glass <sjg at chromium.org> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> (moved from thread "U-Boot PXA support")
> >>>>
> >>>> We have of-platdata, which produces C data from the DT, for linking
> >>>> into U-Boot. It saves libfdt and DT space. But we still have the DM
> >>>> overhead.
> >>>>
> >>>> We have binman which can insert values into the binary after
> >>>> link-time. This is barely used at present, only for accessing the
> >>>> location of things in flash.
> >>>>
> >>>> Another thing is that every little tweak and feature adds a few bytes
> >>>> and there are dozens of them in each release. It would be interesting
> >>>> to build a board from 10 years ago (like PXA) and see where the growth
> >>>> is. My bet is that we could add Kconfig options to disable extra
> >>>> features (and enhancements of features) and make quite a difference.
> >>>>
> >>>> For DM, I think it would be interesting to revisit and compare against
> >>>> the initial release, and see if some features could be made optional
> >>>> in SPL.
> >>>>
> >>>> Finally I feel we could implement a single-device API for where
> >>>> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a
> >>>> single instance of tiny MMC for MMC, etc.
> >>>
> >>> This is what I'm looking for quite sometime, a tiny MMC which would
> >>> bypass the mmc stack and do the possible stuff in SPL, since we don't
> >>> have any option to use full DM in SPL (specifically for Allwinner 64
> >>> SoC's). API that would atleast compatible with DM with small
> >>> foot-print would help.
> >>
> >> It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
> > 
> > I want to start by saying I'm not criticizing MMC_TINY.  But I think
> > this highlights part of the problem of "lets do something that's not the
> > normal framework".  Developers come up with a one-off, do their best to
> > make others know about it, and then a year later when someone else has a
> > similar problem, they may or may not stumble into the alternate path
> > fix.
> > 
> > So, getting back to specifics, what would it take to do both:
> > - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use
> >   this for the "we just need MMC read, ROM probably already did enough
> >   init for us for this"
> > - NOT blow up CI20 which I know is super tight on space.
> 
> You can already do just that.
> 
> Isn't the current problem a good/searchable documentation then ?
> Like the readthedocs stuff ?

Oh?  Good!  So, yes, it's documented as:
          Enable MMC framework tinification support. This option is useful if
          if your SPL is extremely size constrained. Heed the warning, enable
          this option if and only if you know exactly what you are doing, if
          you are reading this help text, you most likely have no idea :-)

          The MMC framework is reduced to bare minimum to be useful. No malloc
          support is needed for the MMC framework operation with this option
          enabled. The framework supports exactly one MMC device and exactly
          one MMC driver. The MMC driver can be adjusted to avoid any malloc
          operations too, which can remove the need for malloc support in SPL
          and thus further reduce footprint.

So, is write supported?  When you say "one MMC device", is that static
at run-time or you can run-time init and use only one? What would a
patch look like that enabled this on SoCFPGA?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190521/cdf76763/attachment.sig>