[U-Boot] Making U-Boot smaller

[Marek Vasut]

On 5/21/19 10:10 PM, Tom Rini wrote:
> On Tue, May 21, 2019 at 10:01:42PM +0200, Marek Vasut wrote:
>> 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 ?
> 
> For the cases where writing is required, OK, so not possible here,
> that's a fine trade-off.

Isn't there CONFIG_MMC_WRITE for that ?

>>> 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.
> 
> Where/how?  I don't see it from the code right away..

CCing Ezequiel, he was digging in that recently and he likes CI20 .

>>> 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.
> 
> Yes, and now I'm trying to get it understood, so we can update the
> Kconfig help if nothing else, how limited the driver is and how to
> switch to it.  So what would it look like to use this on SoCFPA, or
> some other platform you're familiar with and that uses SPL?  iMX6 is
> another "we have no SPL space!" platform that isn't using MMC_TINY, for
> example.

See above, I'll deflect this question to the expert(s).

-- 
Best regards,
Marek Vasut