From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yi0-f47.google.com ([209.85.218.47]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1QmgJa-0003Pd-1n for openembedded-core@lists.openembedded.org; Fri, 29 Jul 2011 08:12:54 +0200 Received: by yib18 with SMTP id 18so2444036yib.6 for ; Thu, 28 Jul 2011 23:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1Ok+ZvK0sRa/spT5ZzqE0uXECrJ7LUGOvh5MoPTj/+8=; b=wciaPL+YxruEeXcq7RUQp+kpSWHmJCMtbp/hx0aXPENufogCSyGs+xC4czv1tm/tDT 4qEJ1IDsVUQrQnr0Jw4NhXXZivG3UpNYpQ5QTNUodZNxJsB5h6NacK23VFL2jd8NRCFx BfMbVvkHKMq+5Uvx4w5AtZjBMuyn8b55L6vYw= Received: by 10.142.63.6 with SMTP id l6mr518362wfa.407.1311919716878; Thu, 28 Jul 2011 23:08:36 -0700 (PDT) Received: from [192.168.1.70] (99-57-141-118.lightspeed.sntcca.sbcglobal.net [99.57.141.118]) by mx.google.com with ESMTPS id p3sm1046541wfh.8.2011.07.28.23.08.35 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 23:08:36 -0700 (PDT) Message-ID: <4E324E62.1080601@gmail.com> Date: Thu, 28 Jul 2011 23:08:34 -0700 From: Khem Raj User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: openembedded-core@lists.openembedded.org References: <346abefc87d21d0cc111ef87a6e48f40c5b6cb0b.1311683981.git.richard.purdie@linuxfoundation.org> <1311769062.30326.322.camel@phil-desktop> <1311773637.2344.365.camel@rex> In-Reply-To: <1311773637.2344.365.camel@rex> Subject: Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 06:12:54 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/27/2011 06:33 AM, Richard Purdie wrote: > On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote: >> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote: >>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}" >> >> This seems a bit backwards. Shouldn't TARGET_FPU be the primary >> variable and then the package suffix be computed from that, rather than >> vice versa? > > It's been "fun" to use the rather limited constructs we have in these > variables to construct the end result. I suspect this way around, it was > the easiest way to get the right variables in the right places. > >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}" >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}" >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}" >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}" >> >> This is wrong: ARMv6 doesn't imply Thumb-2. > > Ah, yes. I'll fix this. > >>> +# Whether to compile with code to allow interworking between the two >>> +# instruction sets. This allows thumb code to be executed on a primarily >>> +# arm system and vice versa. It is strongly recommended that DISTROs not >>> +# turn this off - the actual cost is very small. >>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions" >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}" >>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}" >> >> This is only relevant for v4t, I guess. Interworking is basically >> always on for v5 and later and (CeSI aside) it's impossible on v4, so >> hardly anybody is going to be flipping this switch. I'm not sure it >> really merits an OVERRIDE. > > I'd be happy to remove this option if there are no objections. It was > left for compatibility with the existing tune-thumb file but as you say, > it likely doesn't make much sense. I know SHR uses armv4t but I dont know of armv4 usecases. May be we could may armv4t as oldest supported arm arch and leave armv4 out.