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

Hans de Goede hdegoede at redhat.com
Thu Nov 3 11:49:45 CET 2016


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

Regards,

Hans


More information about the U-Boot mailing list