Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-core@lists.openembedded.org
Subject: qemuarm: should it really have TUNE_ARCH armv5te?
Date: Tue, 11 Sep 2012 15:01:55 +0200	[thread overview]
Message-ID: <20120911130155.GC14077@jama.jama.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

Hi,

when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz) 
or -mtune=arm926ej-s (when built for qemuarm).

From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended.

Does qemuarm use oe-core as it's intended?

Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right now
opkg upgrade can download some packages with xscale some with arm926ej-s.

$ ~/bitbake/bin/bitbake-diffsigs
  stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
  stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
  basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1
  Variable TUNE_CCARGS value changed from
  ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
  ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}
  to
  ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
  ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
  ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

             reply	other threads:[~2012-09-11 13:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 13:01 Martin Jansa [this message]
2012-09-11 13:48 ` qemuarm: should it really have TUNE_ARCH armv5te? Martin Jansa
2012-09-11 15:51   ` ARM-tuning -- was " Mark Hatle
2012-09-11 15:59     ` Martin Jansa
2012-09-11 16:09       ` Mark Hatle
2012-09-11 16:22         ` Martin Jansa
2012-09-11 16:13     ` Koen Kooi
2012-09-11 18:40       ` Khem Raj
2012-09-11 18:53         ` Phil Blundell
2012-09-11 19:58           ` Khem Raj
2012-09-11 16:46 ` Phil Blundell
2012-09-11 16:53   ` Martin Jansa
2012-09-11 17:14     ` Phil Blundell
2012-09-11 17:21       ` Martin Jansa
2012-09-11 17:35         ` Martin Jansa
2012-09-11 17:37           ` Phil Blundell
2012-09-11 17:43             ` Martin Jansa
2012-09-11 18:00               ` Mark Hatle
2012-09-12 14:33 ` Richard Purdie
2012-09-13  6:20   ` Martin Jansa
2012-09-13 10:42     ` Richard Purdie
2012-09-13 12:14       ` Martin Jansa
2012-09-13 12:58         ` Richard Purdie
2012-09-15  7:01           ` Martin Jansa
2012-09-21 15:52             ` Martin Jansa
2012-09-22 11:48               ` Richard Purdie
2012-09-13 16:47       ` Mark Hatle
2012-09-13 17:02         ` Phil Blundell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120911130155.GC14077@jama.jama.net \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox