[U-Boot] Please pull u-boot-dm

[Hans de Goede]

Hi,

On 20-05-16 19:55, Tom Rini wrote:
> On Fri, May 20, 2016 at 05:53:34PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 20-05-16 17:23, Simon Glass wrote:
>>> Hi Tom,
>>>
>>> On 19 May 2016 at 10:02, Tom Rini <trini at konsulko.com> wrote:
>>>> On Thu, May 19, 2016 at 08:41:05AM -0600, Simon Glass wrote:
>>>>> Hi Tom,
>>>>>
>>>>> On 19 May 2016 at 06:09, Tom Rini <trini at konsulko.com> wrote:
>>>>>> On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote:
>>>>>>
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> This includes a refinement of the GPIO interface, soft SPI fixes,
>>>>>>> driver model block-device support (and a legacy driver for
>>>>>>> non-driver-model code) and a few other things. The changes are fairly
>>>>>>> major so I'd like to get the maximum possible test window.
>>>>>>>
>>>>>>>
>>>>>>> The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed:
>>>>>>>
>>>>>>>  Prepare v2016.05 (2016-05-16 10:40:32 -0400)
>>>>>>>
>>>>>>> are available in the git repository at:
>>>>>>>
>>>>>>>  git://git.denx.de/u-boot-dm.git
>>>>>>>
>>>>>>> for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30:
>>>>>>>
>>>>>>>  dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600)
>>>>>>>
>>>>>>
>>>>>> Applied to u-boot/master, thanks!
>>>>>>
>>>>>> But please note that this is starting to push some boards to or over the
>>>>>> SPL edge such as Cubietruck so we need to look into some waste areas
>>>>>> again.  Adding Hans in case there's also stuff we could simply be
>>>>>> dropping out of SPL but aren't today.
>>>>>
>>>>> Yes I saw that but the increase was much larger than it should have
>>>>> been. I meant to try it with the bug-fixed gcc and see if the increase
>>>>> was smaller. It does unfortunately add a few hundred bytes of code. I
>>>>> believe it might be possible to reduce this but I haven't yet figured
>>>>> out how.
>>>>
>>>> I've been happy when I can use gcc-6.x for all the free cost savings but
>>>> current Debian tools (and current Fedora, and current any other big
>>>> distro) toolchains matter too.  You can also see the size growth (but
>>>> not to fatal proportions) on CHIP or warp7 or MSI_Primo73
>>>
>>> OK thanks for the pointers. I will take a look. I spent quite a bit of
>>> time on this (it was pretty awful at the start!) but obviously I
>>> haven't quite nailed it.
>>
>> So I've run some quick tests on F-24 which is at gcc-6 (and it is unlikely
>> u-boot v2015.07 will be coming to older Fedora versions) and I got the
>> following u-boot-spl.bin increase for Cubietruck:
>>
>> v2015.05: 19696
>> master:   19932
>>
>> So if others are seeing some more extreme increase then that is probably
>> the good old tool-chain problem with not eliminating unused strings.
>>
>> The way to work around this is look at the linker.map, find out which
>> object files have grown considerably on master, and check if the patches
>> in one of those files perhaps has caused us to use some const string
>> in there, where before we were not using any. The problem with the toolchain
>> bug is that using a single const string in a .o file will make it link
>> in ALL const strings in the .o file, even the 99 other unused ones.
>>
>> In the past I've hacked around that in e.g. the malloc code, but TBH,
>> now that the upstream toolchain is fixed I'm not sure if we should
>> bother with kludging around this.
>
> I am a fan of gcc-6.x (as it saves us space on so many platforms), but
> with your sunxi hat on, rather than Fedora guy hat on, do you think
> telling people to just grab gcc-6.x is an OK solution for users?

With my sunxi custodian hat on, I'm divided on the issue, we've had
to jump through some hoops before because of the linker issue which
causes all strings in a .o file, including unused ones to get linked
into the SPL and I would really like to see us to be able to stop
worrying about this. OTOH the reality is that plenty of people are
still using older tool-chains.

The question is do we expect people to use older tool-chains, and
yet use the latest and greatest u-boot. For Fedora the answer is
no, for Debian I do not know and individual users are likely to
hit this problem too.

So having said all the above, then with my sunxi custodian hat
still on, I have to agree that the size increase with gcc-5
is indeed an issue.

Simon, if you've some time to look into this, that would be great.

As said before I suspect the culprit to be a .o file with lots
of strings in there, of which we ended up using 0 strings before
and are now using 1 or more strings, which brings in ALL the
strings with gcc-5.x . Note I could be completely of the mark
here, this was the problem the last time we had SPL size issues,
might be something different now.

Regards,

Hans