[U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support

[Hans de Goede]

Hi,

On 03-11-16 10:38, Andre Przywara wrote:
> Hi,
>
> On 03/11/16 08:49, Alexander Graf wrote:
>> On 11/03/2016 02:36 AM, Andre Przywara wrote:
>>> Hi,
>>>
>>> this is my first take on the SPL support for the Allwinner A64 SoC.
>>> The actual meat - the DRAM initialization code - has been provided
>>> by Jens - many thanks for that!
>>> The rest of the patches mostly deal with the 32-bit/64-bit switch.
>>>
>>> While it is possible and seems natural to let the SPL also run in 64-bit,
>>> this creates a really large binary (32600 Bytes in my case). With some
>>> hacks (plus some fixes to make the SPL 64-bit safe) I got this to work,
>>
>> So how about we merge the 64bit version first (since that's *way* easier
>> to compile for everyone) and then consider the move to 32bit afterwards?
>
> Mmmh, interesting idea, may be worth a try alone for the sake of the
> 64-bit fixes to the SPL code I have done in this process.
> But I am not sure it doesn't already break for people using just a
> different compiler. I even started to chop of some bytes here and there
> to bring the size down (I gained 200 Bytes at the ctype implementation,
> yeah!)
>
>> I don't even want to start to imagine how to squeeze a 32bit SPL build
>> into the build process for our U-Boot binaries.
>
> I totally agree, even for me it's quite a pain, because a "make clean"
> (which you need in between) removes the build result of that other
> bitness, so you always have to remember to copy the binaries first (and
> then up using stale copies afterwards).
>
>>> but any addition will probably break it and exceed the 32KB limit that
>>> the BROM imposes. Debug is the first obvious victim here.
>>
>> Do you have some section size comparisons between the two?
>
> I spent some time into looking at readelf dumps to find the reason for
> the bigger size, but nothing really stood out. Still it is a bit odd,
> since the size ratio for U-Boot proper is much better (like +20% for
> 64-bit).

IIRC we build the SPL as thumb2, and u-boot proper as regular armv7,
which may explain why the impact on the SPL for going 64 bit is much
larger.

Anyways I'm a fan of just going with 64 bits for now + trying to
squeeze some bytes of the size left and right too.

Have you looked at the size(s) of the C-string sections? In the past
we've had linker bugs where unused C-strings where kept in the final
linked binary, and even if you're not hitting that bug then strings
may make up for a significant chunk of the size and we could try
to make various (error) messages less verbose (or add some CONFIG
option to do so) to make things smaller.

Regards,

Hans


> A promising approach I then tried was to use -mabi=ilp32, which GCC
> itself supports for quite a while already. But that was running into
> ICEs, with no obviously bogus code. If someone more compiler-savvy could
> take a look later, I'd be grateful.
>
> That being said I will try to revive the AArch64 port tonight and push
> this somewhere, so that people can have a look.
>
> Cheers,
> Andre.
>