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

[Hans de Goede]

<Adding Peter Robinson to the Cc to see how much he will
  object my packaging ideas>

Hi,

First of all cool stuff! Thank you Andre and all others
involved for making this happen.

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

Later down in the mail Andre says that in 32 bit (thumb) mode
the size goes down to 20KB which gives us a lot more head-room
then the 32600 out of 32768 bytes available for the 64 bit
version.

With that said I agree with you (Alex) that having a 32 bit
SPL + 64 bit u-boot proper is worry-some from a distro pov.

What I would like to see is:

1) Ensure we keep a pure 64 bit build working, which should
lead to a fully functional u-boot-sunxi-with-spl.bin just like
how things work for current 32 bit boards. This will give
distros an easy way to deal with this and is also easier
for users who built from source (like people who to the
occasional contribution but are not really into u-boot).

2) Offer the 32 bit option in the do 2 builds, combine 32 bit
SPL with 64 bit u-boot proper (and ATF) as Andre is suggesting
as an option.

We may need to strip some features from "1" in the future,
e.g. no NAND support.

For distros we could then still opt to use 2, to e.g. get
NAND support. One solution I have in mind is:

a) Do a native 32 bit build for the 32 bit SPL, store the SPL
somewhere (just like we store u-boot-sunxi-with-spl.bin for
end users to dd for other 32 bit boards), on Fedora this
build would generate uboot-images-armv7.noarch.rpm
(we already put all the generated u-boot-sunxi-with-spl.bin
files in this noarch rpm).

b) Do a native 64 bit build which stores both a 64 bit
u-boot-sunxi-with-spl.bin as well as just a u-boot.bin
(unless we can extract the latter easy enough), on fedora
this build would generate uboot-images-armv8.noarch.rpm
(as we already do).

c) Have a separate noarch (in rpm terms) package which
depends on the 2 packages build from a. and b. this is
This can then just combine the results from a. and b.
into a mixed 32 + 64 bit u-boot-sunxi-with-spl.bin
we could call this uboot-images-arm-mixed.noarch.rpm :)

So although not pretty from the Fedora pov I can see
ways to work around things and even be able to use "2"
in Fedora.

Regards,

Hans