[OE-core] [PATCH 1/2] armv8: update to use armv8-a tune

[Mark Hatle]

On 8/3/17 10:56 AM, akuster808 wrote:
> 
> 
> On 08/01/2017 08:46 AM, Khem Raj wrote:
>> On Tue, Aug 1, 2017 at 8:24 AM, Mark Hatle <mark.hatle at windriver.com> wrote:
>>> On 8/1/17 10:20 AM, Khem Raj wrote:
>>>> On Tue, Aug 1, 2017 at 8:17 AM, akuster808 <akuster808 at gmail.com> wrote:
>>>>>
>>>>> On 07/31/2017 12:04 PM, Khem Raj wrote:
>>>>>>
>>>>>> On 7/31/17 10:51 AM, Mark Hatle wrote:
>>>>>>> On 7/31/17 12:40 PM, akuster808 wrote:
>>>>>>>>
>>>>>>>> On 07/31/2017 10:31 AM, Mark Hatle wrote:
>>>>>>>>> On 7/31/17 12:16 PM, Armin Kuster wrote:
>>>>>>>>>> Signed-off-by: Armin Kuster <akuster808 at gmail.com>
>>>>>>>>>> ---
>>>>>>>>>>    meta/conf/machine/include/arm/arch-armv8.inc | 25
>>>>>>>>>> +++++++++++++++++++++++++
>>>>>>>>>>    1 file changed, 25 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc
>>>>>>>>>> b/meta/conf/machine/include/arm/arch-armv8.inc
>>>>>>>>>> index 5e832fa..dc1ba5e 100644
>>>>>>>>>> --- a/meta/conf/machine/include/arm/arch-armv8.inc
>>>>>>>>>> +++ b/meta/conf/machine/include/arm/arch-armv8.inc
>>>>>>>>>> @@ -1 +1,26 @@
>>>>>>>>>> +DEFAULTTUNE ?= "armv8-a"
>>>>>>>>> do we want the '-a'?  The other arm (7) are of the format armv7a (no
>>>>>>>>> '-').
>>>>>>>> works for me either way.
>>>>>>>>
>>>>>>>> While we are at it. How would we want ‘armv8.1-a’, ‘armv8.2-a’,
>>>>>>>> ‘armv8.3-a'
>>>>>>>> formated as?
>>>>>>> My preference is to drop the '-'.  As for the '.', I'm not sure.. not
>>>>>>> something
>>>>>>> we've run across before.
>>>>>>>
>>>>>>> We could just drop it (the '.'), but it really depends on if armv81a
>>>>>>> would
>>>>>>> confuse someone (familiar with arm) or not.
>>>>>> I would suggest to also sync  with other distros and ensure that we dont
>>>>>> do something different. Its very costly later. Since applications get
>>>>>> ported to most common combination
>>>>> Sync what part? naming of file? ( sorry lost regarding your comment)
>>>> naming convention for arch e.g.
>>>>
>>> I'd say Debian/Ubuntu -- Fedora/RH would be the two primary sources I'd look at.
>>>   Between debian package names and RPM package names, it should give a clue if
>>> there is any community standard forming for those names.
>>>
>>> (May still be too premature for those environments for the armv8.X-a naming...
>>> and I've not seen it discussed on any other lists either.)
>> yeah, it will be good to not go through the pain of community doing
>> something else later
>> like *-*-gnueabihf triplet was invented and to date we keep fixing
>> packages for OE
>> to account for gnueabihf can be gnueabi + -mfloat-abi=hard but
>> packages just assume
> 
> I think I now understand the issue. Any interest in having additional 
> tune files warehoused somewhere so folks don't have to reinvent the 
> wheel? Something like "meta-extra-tunes" ?
> 
> I prefer fostering contributions for additional tune files that get 
> vetted by the community rather than the multitude of unseen 
> implementations I have found sitting around.

I wouldn't be against it.  The original thought was that new tunes (and related
configurations) would be housed in the BSP until submitted to the YP.  But I'm
not sure in hindsight that is very robust..

Having a general meta-* layer that can just collect arch settings would be
useful to help coordinate people, but keep out in-progress stuff from the base.
The only issue is someone will have to further coordinate acceptance into the
extra layer, and help push them into the oe-core proper when the tune quality is
at a correct level --or-- the tune becomes prevalent in the world.

(I just don't want it to become a dumping ground and it never ends up in the
core...  Similarly moving older tunes out of the core might some day be useful
as well.)

Key of course is this should include tunes, as well as things like
siteinfo.bbclass and insane.bbclass or other extensions.  (via:
PACKAGEQA_EXTRA_MACHDEFFUNCS and similar.)

While the toolchains, arch recipe patches, etc should be elsewhere...

--Mark

> regards,
> armin
> 
>>
>>
>>> --Mark
>