[U-Boot] Making U-Boot smaller

[U-Boot] Making U-Boot smaller

[Simon Glass]

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.

Regards,
Simon

[U-Boot] Making U-Boot smaller

[Jagan Teki]

On Tue, May 21, 2019 at 10:14 PM Simon Glass <sjg@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.

[U-Boot] Making U-Boot smaller

[Marek Vasut]

On 5/21/19 6:43 PM, Simon Glass 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.

If it's a single-instance, then maybe we can somehow compile-out or
short-circuit the DM altogether ?

-- 
Best regards,
Marek Vasut

[U-Boot] Making U-Boot smaller

[Marek Vasut]

On 5/21/19 6:56 PM, Jagan Teki wrote:
> On Tue, May 21, 2019 at 10:14 PM Simon Glass <sjg@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.

-- 
Best regards,
Marek Vasut

[U-Boot] Making U-Boot smaller

[Tom Rini]

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

-- 
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/ff66df83/attachment.sig>

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

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

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

[U-Boot] Making U-Boot smaller

[Tom Rini]

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

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

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

-- 
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/0724e0c7/attachment.sig>

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

[U-Boot] Making U-Boot smaller

[Eugeniu Rosca]

cc: Yamada-san

I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which
would point out the culprit configs. This is hardly achievable, but
looks good on the paper!

      CONFIG           FILE SIZE
  ------------       --------------
  CONFIG_FEATURE_A    10.7Mi  37.1%
  CONFIG_FEATURE_B    5.39Mi  18.6%
  CONFIG_FEATURE_C    4.48Mi  15.5%
  CONFIG_FEATURE_D    1.86Mi   6.4%
  CONFIG_FEATURE_E    1.67Mi   5.8%
  CONFIG_FEATURE_F    1.61Mi   5.6%
  CONFIG_FEATURE_G     856Ki   2.9%
  CONFIG_FEATURE_H     470Ki   1.6%
  ....
  TOTAL               28.9Mi 100.0%

[1] https://github.com/google/bloaty

-- 
Best regards,
Eugeniu

[U-Boot] Making U-Boot smaller

[Tom Rini]

On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
> cc: Yamada-san
> 
> I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which
> would point out the culprit configs. This is hardly achievable, but
> looks good on the paper!
> 
>       CONFIG           FILE SIZE
>   ------------       --------------
>   CONFIG_FEATURE_A    10.7Mi  37.1%
>   CONFIG_FEATURE_B    5.39Mi  18.6%
>   CONFIG_FEATURE_C    4.48Mi  15.5%
>   CONFIG_FEATURE_D    1.86Mi   6.4%
>   CONFIG_FEATURE_E    1.67Mi   5.8%
>   CONFIG_FEATURE_F    1.61Mi   5.6%
>   CONFIG_FEATURE_G     856Ki   2.9%
>   CONFIG_FEATURE_H     470Ki   1.6%
>   ....
>   TOTAL               28.9Mi 100.0%
> 
> [1] https://github.com/google/bloaty

This is relatively easy to do today, with buildman and a local commit to
enable/disable CONFIG_FEATURE_A.

-- 
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/20190522/7cf20f1e/attachment.sig>

[U-Boot] Making U-Boot smaller

[Eugeniu Rosca]

Hi Tom,

On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote:
> On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
> > cc: Yamada-san
> > 
> > I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which
> > would point out the culprit configs. This is hardly achievable, but
> > looks good on the paper!
> > 
> >       CONFIG           FILE SIZE
> >   ------------       --------------
> >   CONFIG_FEATURE_A    10.7Mi  37.1%
> >   CONFIG_FEATURE_B    5.39Mi  18.6%
> >   CONFIG_FEATURE_C    4.48Mi  15.5%
> >   CONFIG_FEATURE_D    1.86Mi   6.4%
> >   CONFIG_FEATURE_E    1.67Mi   5.8%
> >   CONFIG_FEATURE_F    1.61Mi   5.6%
> >   CONFIG_FEATURE_G     856Ki   2.9%
> >   CONFIG_FEATURE_H     470Ki   1.6%
> >   ....
> >   TOTAL               28.9Mi 100.0%
> > 
> > [1] https://github.com/google/bloaty
> 
> This is relatively easy to do today, with buildman and a local commit to
> enable/disable CONFIG_FEATURE_A.

Being a valid choice doesn't make it necessarily appealing, especially
with 512 [1] configurations enabled in sandbox and knowing that U-Boot
is not really randconfig-grade [2] (the latter is being improved).

What I was alluding to is embedding the Kconfig symbol names into the
ELF objects, such that utilities like 'nm' (currently producing a nice
output of symbol sizes [3]) can also be made capable to report the exact
Kconfig symbols contributing to the size of the objects passed as input.
That would be, in my opinion, mind-blowingly useful.

[1] grep "CONFIG.*=" .config | wc -l
512

[2] https://patchwork.ozlabs.org/patch/1074420/

[3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o
0000000000000421 0000000000000024 T clk_free
0000000000000961 0000000000000027 T clk_disable
0000000000000888 0000000000000027 T clk_enable
0000000000000000 0000000000000027 T clk_request
0000000000000503 0000000000000027 T clk_set_parent
0000000000000445 0000000000000029 T clk_get_rate
0000000000000474 0000000000000029 T clk_set_rate
...

-- 
Best regards,
Eugeniu.

[U-Boot] Making U-Boot smaller

[Tom Rini]

On Wed, May 22, 2019 at 06:50:36PM +0200, Eugeniu Rosca wrote:
> Hi Tom,
> 
> On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote:
> > On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
> > > cc: Yamada-san
> > > 
> > > I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which
> > > would point out the culprit configs. This is hardly achievable, but
> > > looks good on the paper!
> > > 
> > >       CONFIG           FILE SIZE
> > >   ------------       --------------
> > >   CONFIG_FEATURE_A    10.7Mi  37.1%
> > >   CONFIG_FEATURE_B    5.39Mi  18.6%
> > >   CONFIG_FEATURE_C    4.48Mi  15.5%
> > >   CONFIG_FEATURE_D    1.86Mi   6.4%
> > >   CONFIG_FEATURE_E    1.67Mi   5.8%
> > >   CONFIG_FEATURE_F    1.61Mi   5.6%
> > >   CONFIG_FEATURE_G     856Ki   2.9%
> > >   CONFIG_FEATURE_H     470Ki   1.6%
> > >   ....
> > >   TOTAL               28.9Mi 100.0%
> > > 
> > > [1] https://github.com/google/bloaty
> > 
> > This is relatively easy to do today, with buildman and a local commit to
> > enable/disable CONFIG_FEATURE_A.
> 
> Being a valid choice doesn't make it necessarily appealing, especially
> with 512 [1] configurations enabled in sandbox and knowing that U-Boot
> is not really randconfig-grade [2] (the latter is being improved).
> 
> What I was alluding to is embedding the Kconfig symbol names into the
> ELF objects, such that utilities like 'nm' (currently producing a nice
> output of symbol sizes [3]) can also be made capable to report the exact
> Kconfig symbols contributing to the size of the objects passed as input.
> That would be, in my opinion, mind-blowingly useful.
> 
> [1] grep "CONFIG.*=" .config | wc -l
> 512
> 
> [2] https://patchwork.ozlabs.org/patch/1074420/
> 
> [3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o
> 0000000000000421 0000000000000024 T clk_free
> 0000000000000961 0000000000000027 T clk_disable
> 0000000000000888 0000000000000027 T clk_enable
> 0000000000000000 0000000000000027 T clk_request
> 0000000000000503 0000000000000027 T clk_set_parent
> 0000000000000445 0000000000000029 T clk_get_rate
> 0000000000000474 0000000000000029 T clk_set_rate

Right.  More numbers, and more easily readable is good.  But to be
clear, since we use -ffunction-sections / -fdata-sections (and the
kernel doesn't normally), we get can get a lot more detail than I might
have implied.  It's not just that you'll see that U-Boot shrank X bytes
with CONFIG_FEATURE_A disabled, it's that you'll see which functions
shrank by how much.  What we don't have is the link between
"CONFIG_OPTION_X" and "is part of functions A/B/C".   But we have a lot
of information like you would get out of nm already in u-boot*.map which
also includes "and we discarded these functions".

-- 
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/20190522/de93c4c3/attachment.sig>

[U-Boot] Making U-Boot smaller

[Eugeniu Rosca]

On Wed, May 22, 2019 at 02:50:58PM -0400, Tom Rini wrote:
> On Wed, May 22, 2019 at 06:50:36PM +0200, Eugeniu Rosca wrote:
[..]
> > 0000000000000421 0000000000000024 T clk_free
> > 0000000000000961 0000000000000027 T clk_disable
> > 0000000000000888 0000000000000027 T clk_enable
> > 0000000000000000 0000000000000027 T clk_request
> > 0000000000000503 0000000000000027 T clk_set_parent
> > 0000000000000445 0000000000000029 T clk_get_rate
> > 0000000000000474 0000000000000029 T clk_set_rate
> 
> Right.  More numbers, and more easily readable is good.  But to be
> clear, since we use -ffunction-sections / -fdata-sections (and the
> kernel doesn't normally), we get can get a lot more detail than I might
> have implied.  It's not just that you'll see that U-Boot shrank X bytes
> with CONFIG_FEATURE_A disabled, it's that you'll see which functions
> shrank by how much.

Thanks for the useful highlights.

> What we don't have is the link between
> "CONFIG_OPTION_X" and "is part of functions A/B/C". 

Yes, that's the key part. I think the magnitude to have such a feature
is reflected by the number of touched components:
 - Kconfig/Kbuild, and possibly additional components on top of these,
   to decide which line in the C file is guarded by which configuration
 - Compiler/linker to inject that information into the ELF files
 - readelf/nm, to avoid manual parsing of U-Boot map files

A superhero or a motivated small team can possibly do it one day :-)

> But we have a lot
> of information like you would get out of nm already in u-boot*.map which
> also includes "and we discarded these functions".

-- 
Best Regards,
Eugeniu.