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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot