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

[Andre Przywara]

Hi,

On 03/11/16 09: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).
> 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.

Just a quick update: The 64-bit SPL patches were in a worse state than I
originally thought and I failed to resurrect them quickly again.

After spending some hours with debugging (the old way via writing to SD
cards) I discovered that there is apparently a regression in 2016.11-rc3
over the 2016.09 release with respect to these patches.
So my old 64-bit SPL patches work in the branch which is on top of
2016.09, but break after rebasing them to 2016.11-rc3. I now managed to
squash these patches in between the two releases, so I should be able to
bisect them later tonight. I keep you posted.

Cheers,
Andre.