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

[Andre Przywara]

Hi,

On 03/11/16 09:34, Hans de Goede wrote:
> <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's even nastier is the requirement of a cross compiler even for a
native build. Do Fedora and Suse offer packaged cross-compilers for the
other ARM bitness, respectively?

> 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.

Indeed providing the two options seems like a sensible approach, even
with the hacks needed to package it. I will try to bake a joint series
so that people can play with it.

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

I am afraid that the SPL build is already quite minimal, at least I
couldn't find any really useless function in the dump.
But lets keep the hope up ;-)

> 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 :)

Don't forget ATF ;-)

I still wonder why _every_ distribution aims to build the firmware for
_every_ board, but I think we had this discussion already. And having an
automated way of building it which gets exercised regularly isn't a bad
thing, I guess.

Cheers,
Andre.

> 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