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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
