[U-Boot] Making U-Boot smaller

[Marek Vasut]

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 ?

-- 
Best regards,
Marek Vasut