[fedora-arm] ARMv7 rootfs/repository?

[Gordan Bobic]

Chris Tyler wrote:
> On Wed, 2010-12-22 at 14:19 +0000, Gordan Bobic wrote:
>> Is there such a thing available? So far I have been working with a 
>> Sheeva Plug which is ARMv5 (Marvell Kirkwood) based, so the armv5tel was 
>> a good match.
>>
>> But this morning, my Genesi Efika Smartbook arrived in the post, which 
>> is ARMv7 (Freescale i.MX515 Cortex-A8), and I think there might be 
>> considerably more performance to be extracted from it if an ARMv7 
>> compiled distro is used. I have found mentions of a F10 armv7l build for 
>> a Beagle Board, but I was hoping for a more recent distro. Is there such 
>> a thing available with a recent version of Fedora (ideally F12)? Or am I 
>> going to have to build one myself?
> 
> There are two separate issues involved in going to armv7l from armv5tel
> -- first, optimizing for the arm v7 architecture, and secondly,
> switching from softfp (optional use of the FPU with fp function
> arguments passed in CPU registers) to hardfp (mandatory use of the FPU
> with fp function arguments passed in FPU registers).
> 
> I just recently got a report from a Seneca student studying the arm v5
> vs. arm v7 (softfp) performance on a BeagleBoard xM, and his conclusion
> was that there is little or no appreciable performance gain.

That is interesting. Presumably this is with a recent (CodeSourcery?) 
GCC? Is the lack of obvious improvement down to a GCC deficiency?

> There is an expected performance gain with the switch to hardfp, but
> that's a big challenge: you can't mix softfp and hardfp

Ah - I hadn't realized that. I thought a hardfp binary could work on a 
softfp distro with a hardfp kernel.

> so switching to
> hardfp is like bootstrapping an entirely new architecture.

Just out of interest, is there documentation on how to do that for RPM 
based distros? Or is it just he obvious packageless cross-build, then 
packaged re-build?

> The other
> challenge is that the gcc used in Fedora does not yet support hardfp
> with vfp; using another compiler might be possible, but could lead to
> compatibility challenges with the primary arch.

Undoubtedly. I've been playing with rolling my own repository for ICC 
build x86 RPMs (because I have recently seen ICC produce up to 8x 
performance improvements compared to GCC produced code when it comes to 
number crunching). The performance is quite spectacular in some cases. 
On the other hand, I don't think anyone has yet managed to get glibc to 
build with anything other than GCC. One encouraging thing is that there 
is now some success with getting the kernel to build using ICC.

The reason I mention this is because given the relative maturity of ICC 
in this sense with such major outstanting issues, it will likely be some 
years before a whole distro will build with the likes of RVCT or TI 
compilers.

The performance improvements aren't as great compared to ICC on x86, but 
probably still worthwhile. But I'm not going to hold my breath.

> Thus, my leaning is to hold off on the armv7l move until our gcc
> provides arm v7 hardfp+vfp, which is probably F15 territory.

I think you're right. Trying to build a GNU/Linux distro with something 
other than GCC isn't really plausible at the moment. Pitty - the lack of 
workable hardfp is really going to cripple things like my Efika and the 
Toshiba AC100.

Gordan