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

[Alexander Graf]

On 11/03/2016 11:49 AM, Hans de Goede wrote:
> Hi,
>
> On 03-11-16 11:36, Alexander Graf wrote:
>> On 11/03/2016 10:51 AM, Andre Przywara wrote:
>>> 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?
>>
>> Andreas Faerber was working on cross compilers in openSUSE, but I 
>> don't think they're part of the distribution yet.
>
> Fedora does have cross-compilers (for kernel and u-boot use, no
> support for userland stuff). But as I outlined in my other mail,
> with modern rpm you can do a build on all archs (which you want
> to do anyways to get a native mkimage everywhere) and then use
> %ifarch armv7hl / %ifarch aarch64 to build u-boot binaries
> when doing a native build on armv7 / aarch64 and store all the
> build binaries (one binary per supported board) under
> /usr/share/u-boot and put /usr/share/u-boot in a noarch sub-pkg,
> and Fedora's compose tools will then make that noarch sub-pkg from
> that one specific arch build available in the repos for all archs.
>
> Combine this with an extra noarch package which depends on the
> noarch u-boot-images rpms generated by both the 32 and 64 bit build
> and that extra package can generate a combined img ready for
> dd-ing to a sdcard. If you solve it like this you do not need
> cross compilation. Yes this is not pretty, but it will work
> (at least for Fedora, I do not know how Suse's tools deal
> with noarch sub-packages of a non noarch rpm, rpm itself can
> handle this, but something needs to copy the generated noarch
> sub-rpm to the other archs).

Yes, it's possible, but means that we need to build armv7l and aarch64 
in the same repository. It also means that we actually *have* to build 
armv7l at all to compile a pine64 SPL, which I'd rather not want to 
limit myself to ;).


Alex