On 08/01/2017 08:46 AM, Khem Raj wrote:
On Tue, Aug 1, 2017 at 8:24 AM, Mark Hatle <mark.ha...@windriver.com> wrote:
On 8/1/17 10:20 AM, Khem Raj wrote:
On Tue, Aug 1, 2017 at 8:17 AM, akuster808 <akuster...@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 <akuster...@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.
regards,
armin
--Mark
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
