[fedora-arm] Support for ARMv7, hardware math

omalleys at msu.edu omalleys at msu.edu
Wed Dec 1 18:37:04 UTC 2010

Quoting Andy Green <andy at warmcat.com>:

> On 11/30/10 19:49, Somebody in the thread at some point said:
> Hi -
>> I understand we probably will have logistic issues releasing v7 arch
>> for F14 since it has already been released (for x86), I assume it
>> isn't trivial to add compiler flags for the 13k packages in both F14
>> and rawhide(F15. That sounds like a lot work. It is easier to put them
>> directly into rawhide rather then in both places so they are there
>> moving forward (still a lot of work but it only needs to be done once
>> and you probably can easily script it.)
> Compiler flags and so on are mainly handled by rpmbuild based on the  
> macros for the architecture it's building on.  So it's not like  
> patching thousands of packages.
>> We could branch out a cortex or a v7 release, but that is more
>> logistic issues, and honestly by dropping arm5tel support. I dont
>> think we are dropping much hardware that people are actually
>> interested in running Fedora on and especially by the F15 release.
> I am very interested in running Fedora on armv5tel as we can today.
>> Tablets, laptops, embedded servers would be more realistic, and
> There is a quite wide spread of arm hardware about, it is not going  
> to be the case that suddenly everything is Cortex.  For example  
> these last days I have been using Arm Fedora on NXP LPC3250 which is  
> a new, cheap chip based on the ARM926EJ core which is armv5; Fedora  
> is working great on SD Card.  The last thing I worked on uses Fedora  
> on an iMX31 CPU which is ARM1136 / armv6.
> If it makes a big difference to build for high end cortex  
> specifically, then I hope we're able to keep armv5 while the chips  
> are still current and being designed into things along the lines of  
> i386 / x86_64.
>> As far as actually moving forward...
>> If it is possible to cross-compile RPMS, and get sane results, it
> I think trying to make Fedora build cross is a whole other issue.
> Building stuff cross is a trickier business than you might think.   
> Many packages with recent autotools can build cross OK, plus or  
> minus some magic needed to work with rpmbuild like that, but there  
> is no point doing all that work if there are fast ARM high-end  
> machines available that can build them native.  Surely it's clear  
> that high end arm machines are clearly going to approach x86 kinds  
> of speed anyway in the next years reducing any pay back from the  
> effort of going cross.

I don't believe ARM is going to reach top end x86 speeds in the next  
couple of years. I think MIPS64 has a better chance. I do believe it  
can be a cost effective, energy efficient way to replace lower-end  
systems like desktops and can get some traction in the data centers as  
a replacement for low-end systems and caching type of servers.

I don't disagree with a split, but what concerns me is we don't have  
enough resources to get F13-ARM out the door, much less two versions  
of the distro. We don't have enough people nor the hardware to pull it  

If you can cross-compile, and knock out 50% of the bugs out in a  
"pre-build" system before they hit the actual build system. It  
increases the overall speed of development. I am fully aware it isn't  
going to be simpler then using real hardware, but I was wondering if  
it would be simpler then trying to get qemu-arm with virtio and the  
plan9 layer working (i failed the first time).

Distributing a VM "image" with all the build tools set up and  
everything configured is a lot simpler then setting up a full blown  
dev environment.

More information about the arm mailing list