From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Thu, 3 Nov 2016 12:36:55 +0100 Subject: [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support In-Reply-To: References: <1478137001-847-1-git-send-email-andre.przywara@arm.com> <581AFA18.4040404@suse.de> <9b937016-4efb-4307-6afa-5537800efb18@redhat.com> <581B1318.7030401@suse.de> Message-ID: <581B2157.3090209@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: >>>> >>> 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