[U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Marek Vasut]

On 04/12/2018 10:01 AM, Alexander Graf wrote:
> 
> 
> On 11.04.18 16:43, Dinh Nguyen wrote:
>> On Wed, Apr 11, 2018 at 7:55 AM, Alexander Graf <agraf at suse.de> wrote:
>>> On 04/11/2018 02:37 PM, Marek Vasut wrote:
>>>>
>>>> On 04/11/2018 02:26 PM, Tom Rini wrote:
>>>>>
>>>>> On Wed, Apr 11, 2018 at 10:12:42AM +0200, Marek Vasut wrote:
>>>>>>
>>>>>> On 04/11/2018 04:52 AM, Dinh Nguyen wrote:
>>>>>> [...]
>>>>>>
>>>>>>>>>> u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la
>>>>>>>>>> spl/u-boot-spl.bin
>>>>>>>>>> HEAD is now at f3dd87e0b9 Prepare v2018.01
>>>>>>>>>> -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin
>>>>>>>>>>
>>>>>>>>>> u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la
>>>>>>>>>> spl/u-boot-spl.bin
>>>>>>>>>> HEAD is now at f95ab1fb6e Prepare v2018.03
>>>>>>>>>> -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin
>>>>>>>>>>
>>>>>>>>>> Try bisecting out the commit which caused this 7 kiB growth between
>>>>>>>>>> 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it
>>>>>>>>>> was
>>>>>>>>>> at 53 kiB for a while (2017.05 is also ~53 kiB)
>>>>>
>>>>> Do you have a size constraint and are not setting the correct CONFIG
>>>>> options so that it becomes a build failure?
>>>>>
>>>>>>>>> Doing the bisect points me to this commit:
>>>>>>>>>
>>>>>>>>> commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2
>>>>>>>>> Author: Tom Rini <trini at konsulko.com>
>>>>>>>>> Date:   Sat Feb 10 16:54:38 2018 -0500
>>>>>>>>>
>>>>>>>>>      configs: Re-sync with CONFIG_DISTRO_DEFAULTS
>>>>>>>>>
>>>>>>>>>      A number of platforms include config_distro_defaults.h but do
>>>>>>>>> not enable
>>>>>>>>>      CONFIG_DISTRO_DEFAULTS.  As they plainly intended to, set that
>>>>>>>>> flag and
>>>>>>>>>      re-sync config files.
>>>>>>>>>
>>>>>>>>>      Signed-off-by: Tom Rini <trini at konsulko.com>
>>>>>>>>>
>>>>>>>>> Doing a revert of the above commit shrinks the SPL back down to ~7
>>>>>>>>> kiB.
>>>>>>>>>
>>>>>>>>> Dinh
>>>>>>>>>
>>>>>>>> It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these
>>>>>>>> configs:
>>>>>>>>
>>>>>>>> CONFIG_ISO_PARTITION=y
>>>>>>>> CONFIG_SPL_ISO_PARTITION=y
>>>>>>>> # CONFIG_AMIGA_PARTITION is not set
>>>>>>>> # CONFIG_SPL_AMIGA_PARTITION is not set
>>>>>>>> CONFIG_EFI_PARTITION=y
>>>>>>>> CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128
>>>>>>>> CONFIG_EFI_PARTITION_ENTRIES_OFF=0
>>>>>>>> CONFIG_SPL_EFI_PARTITION=y
>>>>>>>> CONFIG_PARTITION_UUIDS=y
>>>>>>>> CONFIG_SPL_PARTITION_UUIDS=y
>>>>>>>> # CONFIG_PARTITION_TYPE_GUID is not set
>>>>>>>>
>>>>>>>> Which is contributing to the SPL growth.
>>>>>>>>
>>>>>>> Turning the following config options off subtracts 7k from the SPL:
>>>>>>>
>>>>>>> +# CONFIG_SPL_ISO_PARTITION is not set
>>>>>>> +# CONFIG_SPL_EFI_PARTITION is not set
>>>>>>>
>>>>>>> Not sure if these are needed?
>>>>>>
>>>>>> IMO not on SoCFPGA. Also CCing Tom.
>>>>>
>>>>> Yes, all of those options are part of CONFIG_DISTRO_DEFAULTS and are
>>>>> needed so that booting from various distro media works.
>>>>
>>>> In SPL on boards which usually boot from SDMMC or QSPI NOR ? How is EFI
>>>> or ISO partition needed there ?
>>>
>>>
>>>
>>> I don't think ISO partitioning is needed in SPL. However, for GPT I'm not
>>> 100% sure. People tend to go with GPT more often than not these days - and
>>> to be able to fetch U-Boot proper from a GPT partition may make sense.
>>>
>>> How much reduction do you get when you only disable
>>> CONFIG_SPL_ISO_PARTITION?
>>>
>>
>> ~3 kiB
> 
> Ok, so that's not enough to get us back to reasonable space, but it's at
> least a step in the right direction. I sent a patch to disable
> CONFIG_SPL_ISO_PARTITION for everyone by default ;).
> 
> If we remove all printfs from part_efi.c we could for example gain
> another 1.5kb. But I'm not sure that's worth it - and if feels like
> we're shaving on the wrong end at this point.
> 
> Is there any other big chunk in there that wastes space?

The entire EFI support, which is never used on SoCFPGA to my knowledge,
esp. in SPL .

> Also, Marek, could you maybe tell the linker that we only have 64-8kb
> space available, so it fails compilation? That way we could catch these
> issues in Travis already.

Dinh, can you send a patch for that ?

-- 
Best regards,
Marek Vasut