[OE-core] [PATCH 0/1] Change default for cortexa* to armv7at-neon.

Martin Jansa martin.jansa at gmail.com
Fri Aug 22 21:46:26 UTC 2014


On Fri, Aug 22, 2014 at 03:49:54PM -0500, Peter Seebach wrote:
> On Fri, 22 Aug 2014 21:39:10 +0200
> Martin Jansa <martin.jansa at gmail.com> wrote:
> 
> > Even enabling thumb seems wrong, because ARM_INSTRUCTION_SET is arm by
> > default, so this change is only renaming the feed, but still building
> > the same binaries (unless distro sets ARM_INSTRUCTION_SET).
> 
> I think that's okay, because the point is to correctly indicate that
> the CPU can run thumb binaries if someone had a reason to make them.
> 
> I mean, strictly speaking, I don't even *know of* an actual chip for which
> armv7a-neon is a correct descriptor. Because "armv7a-neon" is a chip which
> *cannot* run thumb binaries. Does anyone actually make a neon armv7a which
> can't run thumb binaries?
> 
> And yeah, the RFC and ensuing discussion gets to some sort of underlying
> questions about what the purpose of DEFAULTTUNE is. I am inclined to think
> that the DEFAULTTUNE for a given tune-foo should be either the baseline of
> that chipset or a somewhat optimized tune for it.

For me it's sane default for shared binary feed and DISTRO config is the
right place to decide common denominator for your MACHINEs (if all
MACHINEs you support are cortexa9 then yes, it would be better
DEFAULTTUNE, if you enable "thumb" in default ARM_INSTRUCTION_SET, then
yes it makes sense to enable it in DEFAULTTUNE as well, but changing
default DEFAULTTUNE (and TUNE_PKGARCH with that) to have thumb while
still building with -marm doesn't make much sense to me and is only
confusing.

Every distro can use something more "optimized" DEFAULTTUNEs for each
MACHINE they use, I do it for SHR:
https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr-distro/conf/distro/include/defaulttunes.inc

and for webOS-ports we used it for a while and then reverted back to
default, because the difference between cortexa8-neon, cortexa9-neon and
armv8a-neon wasn't worth building and maintaining separate binary feed
(see links in .inc file)
https://github.com/webOS-ports/meta-webos-ports/blob/master/conf/distro/include/defaulttunes.inc

> I note that tune-core2 and tune-corei7 both set tunes (core2-32, corei7-64)
> which include target-specific optimizations; this would be comparable to
> using cortexa9t-neon as the default tune for tune-cortexa9.inc.
> 
> I don't think the current state of tunings reflects a completely consistent
> view of what DEFAULTTUNE means in a tuning file.
> 
> -s
> -- 
> Listen, get this.  Nobody with a good compiler needs to be justified.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140822/e4b70d69/attachment-0002.sig>


More information about the Openembedded-core mailing list