[fedora-arm] Support for ARMv7, hardware math

[omalleys at msu.edu]

First.
The Marvell Feroceon core which is what the plug computers are based  
on supposedly is cortex-8 compatible which is armv7. I am assuming  
this is using the sheeva "tri-core" technology which means it has a  
arm5tel, armv6 and armv7 compatible core (not 3 cores). (and I am  
=guessing= marvell really didnt want to pay a bigger license fee to  
the ARM group for saying more then arm5tel. xscale did it for years.)

Second.
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.)

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.   
Tablets, laptops, embedded servers would be more realistic, and  
=really= we need to be getting ready for the Cortex-A15 which are  
designed to be in low-power servers which Fedora is typically an  
excellent distribution for early adopters and could be in this  
instance also.

The only exception I can possibly think of would be Qemu/libvirtd  
which doesnt have that great of support for arm but it does make a  
decent VM testing. And we could just default the libvirtd to v7 in F15  
right off the bat instead of defaulting to arm5tel.

As far as the FPU's moving forward. Instead of supporting 8-bit FPU  
instructions, can we convert them to 16-bit instructions? So when the  
8-bit fpu math is dropped in later releases of the ARM processors we  
are still compatible?

Another sticky spot is going to be the vectorization routines where  
Marvell support MMX and samsung/apple all support Neon. I'm not sure  
if the cortex spec moving forward will include a spec for a vector  
unit as well or not. Can these be taken care of in by replacing say  
glibc so we don't run into issues?

As far as actually moving forward...

If it is possible to cross-compile RPMS, and get sane results, it  
would be in our best interest to start cross-compiling F15-rawhide to  
look for and fix bugs. I understand having to recompile the whole dist  
on the actual arm hardware. But if we can catch 90% of the issues on  
fast systems before hitting the arm hardware buildbot, then we should  
be doing that (if we aren't). Are there instructions on the Wiki?

I'm not sure some of my assumptions are correct go ahead and flame me  
if I made an error. :)

sean

Quoting Bernhard Schuster <schuster.bernhard at googlemail.com>:

> I think going for F14 (arm5tel ) and postponing anything else(armv7*) to
> F15+ is a good plan, as manpower is limited and (at least I) prefer one
> stable than to wacky sub-architectures.
>
> Bernhard
>