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.)
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
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. :)
Quoting Bernhard Schuster <schuster.bernhard(a)googlemail.com>:
I think going for F14 (arm5tel ) and postponing anything else(armv7*)
F15+ is a good plan, as manpower is limited and (at least I) prefer one
stable than to wacky sub-architectures.