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.