[OE-core] MIPS vs MIPS32 tunings -- summary and questions

[Robert Yang]

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.

// Robert

> expect this to be corrected before the release, or should anybody
> relying on mipsel package feeds stop using oe-core's
> meta/conf/machine/include/mips/arch-mips.inc?
>
> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>