[U-Boot] Making U-Boot smaller

[Marek Vasut]

On 5/21/19 9:59 PM, Tom Rini wrote:
> 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?

No, what for ?

> When you say "one MMC device", is that static
> at run-time or you can run-time init and use only one?

IIRC it's compile time.

> What would a
> patch look like that enabled this on SoCFPGA?  Thanks!

Like nothing , since SoCFPGA probes itself from DT in SPL and there's
enough space for that. However, if you want an example, CI20 is one.

-- 
Best regards,
Marek Vasut