On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > Shouldn't spitz produce something like armv5te-xscale and qemuarm > armv5te-arm926ejs?
That's a DISTRO policy decision really. "armv5te", in common with most of the PACKAGE_ARCHes, represents an ISA. That is, it is guaranteed to only contain instructions which are supported by all v5TE cores (which includes both ARM926EJ-S and XScale). It obviously follows from this that packages with PACKAGE_ARCH=armv5te are suitable for running on both qemuarm and xscale MACHINEs. Note that a binary that was built with -mtune=arm926ej-s is still an ARMv5TE binary and will run just fine on xscale. It won't run quite as fast as one that was built -mtune=xscale, though the performance difference is not so great as to be completely crippling. With current gcc, the reverse is true as well: a binary built -mtune=xscale is also still ARMv5TE and will run just fine on ARM926EJ-S, and in fact the performance penalty is less this way around. Now, if your DISTRO feels that the performance difference is important enough to be worth distinguishing the packages, you can certainly arrange for those two tunings to get separate PACKAGE_ARCHes and maintain parallel feeds. But in the general case it's not totally obvious that this would be worthwhile, and I'm not sure it is a very useful thing to do by default. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
