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@xxxxxxxxxxxxxx>: > 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 > _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
