On 16.04.2012 16:37, Robert Yang wrote: > > > On 04/16/2012 09:55 PM, Andreas Oberritter wrote: >> On 10.04.2012 21:28, Andreas Oberritter wrote: >>> On 10.04.2012 19:53, Mark Hatle wrote: >>>> We still do not have a clean answer for how to resolve the concerns in >>>> the recent thread "conf/machine/include: Cleanup MIPS tunings to match >>>> README". The following is in response to a request I received to >>>> summarize the discussion so far, and include the options to resolve the >>>> issue for the current OE-Core release. >>>> >>>> If you are interested in this, please be sure to read until the end >>>> before commenting. >>>> >>>> Background: >>>> >>>> About 2 weeks ago, in response to a number of patches sent for PowerPC >>>> issues, I set to the task of documenting and cleaning up the various >>>> tune files. It was discovered that since they were originally >>>> implemented, a number of minor conflicts and defects had crept into the >>>> system. The recent patch set added a number of README files and >>>> attempted to resolve any duplication, or confusion between items. >>>> >>>> During this work it was discovered that there were two tunings that >>>> produced the same package architecture: >>>> >>>> mips (tune), optimized for mips1 - o32 ABI, produced packages with a >>>> "mips" arch >>>> >>>> mips32 (tune), optimized for mips32 - o32 ABI, produced packages also >>>> with a "mips" arch. >>>> >>>> While "mips1" should work on a "mips32" system, the reverse is not >>>> true. There was no way to distinguish, in a package feed, the >>>> difference between the two sets of binaries. >>>> >>>> I updated the MIPS tune files to resolve this issue. The result was: >>>> >>>> mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch >>>> >>>> mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch >>>> >>>> This lead to the thread mentioned above. At first there were concerns >>>> that the GNU target arch had changed (from mips to mips32), this was >>>> not >>>> the case. The only change is in the produced package arch names. So >>>> the package feeds and image generation are the only components affected >>>> by this change. >>>> >>>> After various discussion with folks, such as Khem Raj, it is unlikely >>>> that anyone would be using oe-core with a "mips1" target. There may be >>>> some mips3 or mips4 targets, but we find it highly unlikely based on >>>> our >>>> current experience. Khem suggested resolving this my simply making the >>>> "mips" include mips32 as the default optimization. >>>> >>>> Image generation was verified to produce the same images before and >>>> after this change for the qemumips target. I am unable to verify the >>>> package feeds, as I do not have a suitable setup for this. >>>> >>>> So possible solutions to this particular issue, which we do need on >>>> prior to the upcoming release: >>>> >>>> 1) Revert the behavior and match that last release. We have two tunes >>>> that produce different binaries w/ the same "mips" package arch. >>>> * This preserves previous behavior, but IMHO continues to implement >>>> the defect >>>> >>>> mips (tune) - mips1 processor, o32 ABI - mips package arch >>>> mips32 (tune) - mips32 processor, o32 ABI - mips package arch >>>> >>>> 2) Keep it as it is currently checked in. Provide the ability to build >>>> a basic "mips" and a more optimized "mips32" tuned target and >>>> package set. >>>> * This fixes the defect and provides the opportunity for "mips" >>>> to be >>>> a basic common package arch, while mips32 (or additional mips3? mips4? >>>> mips32r2?) tunes could be used to augment this for specific systems. >>>> >>>> mips (tune) - mips1 processor, o32 ABI - mips package arch >>>> mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch >>> >>> If the tune should reflect the optimization, then mips should be renamed >>> to mips1 and specified explicitly using -march=mips1, in order to >>> protect against changing defaults when using a newer compiler. However, >>> as Phil pointed out, there are many more optimization settings, e.g. -O2 >>> vs. -Os, that aren't encoded into the package arch, so the goal to have >>> distinct package archs for different binaries won't be reached. >>> >>> I don't see what a common "mips" package arch would give us. Within OE, >>> you'd usually compile all your applications for the package arch of your >>> target system. Adding compatible package archs to the feed just >>> increases the complexity of online updates. >>> >>>> 3) Define only one mips tune, with a target package arch of "mips". >>>> Changing the basic mips tune, and corresponding mips package arch to >>>> include mips32 optimizations and instructions. >>>> * This preserves the "mips" tune, but changes the behavior of the >>>> tune from default compiler, to mips32 optimization >>>> * Anyone requiring mips3 or mips4 will need to add a tune, and that >>>> tune will not be compatible with "mips" >>> >>> Also, mips1 could be added back anytime if anybody starts using it. >>> >>>> mips (tune) - mips32 processor, o32 ABI - mips package arch >>>> >>>> 3a) Preserve the mips32 tune entries, but define it as being >>>> equal to >>>> mips >>>> * Preserves the tune entries for compatibility, but is anyone >>>> directly using them? >>>> >>>> 3b) Remove the mips32 tune entries -- effectively eliminating mips32 >>>> as a tune >>>> * Removes the tune entries (cleans up the tunes), no >>>> compatibility >>>> -- but it's unlikely anyone was directly specifying "mips32" as their >>>> machine's DEFAULTTUNE. >>> >>> Actually I have (had) machines specifying mips32el and mips32el-nf as >>> their DEFAULTTUNEs, which your first patch, that got applied upstream, >>> broke. But I've already switched to use your latest patch using mipsel >>> and mipsel-nf instead, (which I prefer over the former). >>> >>>> My recommendation is either 2 or 3. The 3a/b variation is simply an >>>> implementation detail to me, and I will be happy to implement it either >>>> way if this is the chosen direction. >>> >>> I'm fine with either way that restores mips/mipsel for mips32 targets >>> *before the release*, because the online update feeds broke and all >>> packages had to be built again from scratch. >> >> Richard, can you please state your opinion about this issue? >> >> The mips package feed (e.g. qemumips) is now broken since weeks. Can I > > I'm a little confused with this, I've just done a build with > MACHINE = "qemumips", both build and runqemu worked well.
The feed arch changed from mips* to mips32*, so online updates broke. Regards, Andreas _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
