[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
off.
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