From: Khem Raj <raj.khem@gmail.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH][RFC] cortexa8: use hard floating point
Date: Thu, 18 Aug 2011 22:54:56 -0700 [thread overview]
Message-ID: <4E4DFAB0.7080007@gmail.com> (raw)
In-Reply-To: <4E4CAE28.8050600@linux.intel.com>
On 8/17/2011 11:16 PM, Darren Hart wrote:
> From what I could gather, it makes sense to address using mfloat-abi=hard
> for the beagleboard in the cortexa8 tune file. Before I submit this as a pull
> request, I'd appreciate a sanity check from the Beagleboard experts.
>
> Is there any reason the cortexa8 tune file should not be using "hf" by default?
>
> Thanks,
>
> Darren
>
> --------
> Fixes [YOCTO #1203]
>
> mfloat-abi is currently set to soft for beagleboard (cortexa8) and needs to be
> set to hard to take advantage of the floating point hardware.
>
> Append "hf" to each of the cortexa8 TUNE_FEATURES and PACKAGE_EXTRA_ARCHS
> variables. This enables "callconvention-hard" from the included
> arch-armv7a.inc.
>
> Add a missing closing quote to the VFP AVAILTUNES append operation.
>
> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
> CC: Jason Kridner<jkridner@beagleboard.org>
> CC: Koen Kooi<koen@dominion.thruhere.net>
> ---
> meta/conf/machine/include/arm/arch-armv7a.inc | 2 +-
> meta/conf/machine/include/tune-cortexa8.inc | 10 +++++-----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
> index 704f86b..d508352 100644
> --- a/meta/conf/machine/include/arm/arch-armv7a.inc
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -20,7 +20,7 @@ PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a ar
> PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
>
> # VFP Tunes
> -AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon"
> TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
> TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
> TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index 02b560c..e7483b9 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -6,11 +6,11 @@ TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
>
> AVAILTUNES += "cortexa8 cortexa8t"
> -TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} cortexa8"
> -TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} cortexa8"
> +TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7ahf} cortexa8"
> +TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7athf} cortexa8"
> TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
>
> -PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> -PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> -PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon}"
>
It it could be made possible then you could work towards making hardfp
to be a multilib option along with softfp remaining the default. So
people can use certain applications with hardfp which will really
benefit from hardfp. General applications may not benefit so much from
hardfp ABI
prev parent reply other threads:[~2011-08-19 5:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 6:16 [PATCH][RFC] cortexa8: use hard floating point Darren Hart
2011-08-18 8:11 ` Koen Kooi
2011-08-18 11:20 ` Jason Kridner
2011-08-18 8:57 ` Phil Blundell
2011-08-19 5:54 ` Khem Raj [this message]
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=4E4DFAB0.7080007@gmail.com \
--to=raj.khem@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.