Patchwork [1/4] base.bbclass: Add compatibility package name mapping handler

login
register
mail settings
Submitter Richard Purdie
Date July 27, 2011, 2:29 p.m.
Message ID <7cdd5b62608ae2047d4fdd2ee98e452398401b1e.1311776363.git.richard.purdie@linuxfoundation.org>
Download mbox | patch
Permalink /patch/8713/
State New, archived
Headers show

Comments

Richard Purdie - July 27, 2011, 2:29 p.m.
This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
to be "armv7a". Other compatibility mappings can be added as needed.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes/base.bbclass |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)
Mark Hatle - July 27, 2011, 2:44 p.m.
On 7/27/11 9:29 AM, Richard Purdie wrote:
> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> to be "armv7a". Other compatibility mappings can be added as needed.

There are multiple armv7 cores without neon...  I think there might even be one
or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
but people do that all of the time.)

--Mark

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/base.bbclass |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index f12b3cb..3ed1bb8 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -133,6 +133,13 @@ def generate_git_config(e):
>                  f.write(proxy_command)
>                  f.close
>  
> +def pkgarch_mapping(d):
> +    # Compatibility mappings of TUNE_PKGARCH (opt in)
> +    if d.getVar("PKGARCHCOMPAT_ARMV7A", True):
> +        if d.getVar("TUNE_PKGARCH", True) == "armv7a-vfp-neon":
> +            d.setVar("TUNE_PKGARCH", "armv7a")
> +
> +
>  addhandler base_eventhandler
>  python base_eventhandler() {
>  	from bb import note, error, data
> @@ -203,6 +210,7 @@ python base_eventhandler() {
>  
>          if name == "ConfigParsed":
>                  generate_git_config(e)
> +                pkgarch_mapping(e.data)
>  
>  	if not data in e.__dict__:
>  		return
Richard Purdie - July 27, 2011, 2:50 p.m.
On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
> On 7/27/11 9:29 AM, Richard Purdie wrote:
> > This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> > to be "armv7a". Other compatibility mappings can be added as needed.
> 
> There are multiple armv7 cores without neon...  I think there might even be one
> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
> but people do that all of the time.)

I know there are but for some distros in OE have established "armv7a"
with a specific meaning. This gives us some way of merging the tune code
yet defer fixing those conflicts which can then happen at a time of
their choosing.

Its assumed anyone enabling the option knows what it means (which
Angstrom does and is where the request came from).

FWIW I have just merged the tune changes and this workaround flag.

Cheers,

Richard
Phil Blundell - July 27, 2011, 3:02 p.m.
On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
> On 7/27/11 9:29 AM, Richard Purdie wrote:
> > This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> > to be "armv7a". Other compatibility mappings can be added as needed.
> 
> There are multiple armv7 cores without neon...  I think there might even be one
> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
> but people do that all of the time.)

Which spec are you thinking of?  As far as I know, VFP has always been
optional for both ARM11 and Cortex.

p.
Mark Hatle - July 27, 2011, 3:04 p.m.
On 7/27/11 10:02 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Other compatibility mappings can be added as needed.
>>
>> There are multiple armv7 cores without neon...  I think there might even be one
>> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
>> but people do that all of the time.)
> 
> Which spec are you thinking of?  As far as I know, VFP has always been
> optional for both ARM11 and Cortex.

I thought VFP was part of the instruction set as of ARMv7.  Neon is recommended
but options.  As I mentioned though, I know of chips in design that don't have
Neon, and I suspect also don't have VFP -- but they're ARMv7.. (they also have
stripped out the thumb2 part as well..)

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - July 27, 2011, 3:06 p.m.
Op 27 jul. 2011, om 17:02 heeft Phil Blundell het volgende geschreven:

> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Other compatibility mappings can be added as needed.
>> 
>> There are multiple armv7 cores without neon...  I think there might even be one
>> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
>> but people do that all of the time.)
> 
> Which spec are you thinking of?  As far as I know, VFP has always been
> optional for both ARM11 and Cortex.

From the conversations I had with ARM they implied that it isn't optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia tegra2). I haven't seen any black on white contracts saying that, though :)

regards,

Koen
Phil Blundell - July 27, 2011, 3:13 p.m.
On Wed, 2011-07-27 at 17:06 +0200, Koen Kooi wrote:
> From the conversations I had with ARM they implied that it isn't optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia tegra2). I haven't seen any black on white contracts saying that, though :)

The spec on the web seems to say fairly clearly that it's optional, at
least in theory.  I guess they might have commercial reasons for not
wanting to sell it without VFP in any given situation.

See:

http://www.arm.com/products/processors/cortex-a/cortex-a5.php?tab=Specifications

for example

p.
Koen Kooi - July 27, 2011, 3:45 p.m.
Op 27 jul. 2011, om 16:50 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Other compatibility mappings can be added as needed.
>> 
>> There are multiple armv7 cores without neon...  I think there might even be one
>> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
>> but people do that all of the time.)
> 
> I know there are but for some distros in OE have established "armv7a"
> with a specific meaning. This gives us some way of merging the tune code
> yet defer fixing those conflicts which can then happen at a time of
> their choosing.
> 
> Its assumed anyone enabling the option knows what it means (which
> Angstrom does and is where the request came from).
> 
> FWIW I have just merged the tune changes and this workaround flag.

I think we might need a armv5e -> armv5te one and a slightly more tricky armv4 -> armv4t.

The armv4t without thumb case is interesting since we do want to use the EABI bx,lr but not other thumb instructions. My main reason for avoiding t1 is that the toolchain is perpetually broken for it. If gcc fixes a bug binutils will introduce a new one. 

regards,

Koen
Khem Raj - July 30, 2011, 6:43 p.m.
On Wednesday, July 27, 2011 04:13:47 PM Phil Blundell wrote:
> On Wed, 2011-07-27 at 17:06 +0200, Koen Kooi wrote:
> > From the conversations I had with ARM they implied that it isn't
> > optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia
> > tegra2). I haven't seen any black on white contracts saying that,
> > though :)
> The spec on the web seems to say fairly clearly that it's optional, at
> least in theory.  I guess they might have commercial reasons for not
> wanting to sell it without VFP in any given situation.
> 
> See:
> 
> http://www.arm.com/products/processors/cortex-a/cortex-a5.php?tab=Specificat
> ions
> 
> for example

thats only for for a5. For procesors koen mentioned VFP is mandatory
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 30, 2011, 8:01 p.m.
On Sat, 2011-07-30 at 11:43 -0700, Khem Raj wrote:
> On Wednesday, July 27, 2011 04:13:47 PM Phil Blundell wrote:
> > On Wed, 2011-07-27 at 17:06 +0200, Koen Kooi wrote:
> > > From the conversations I had with ARM they implied that it isn't
> > > optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia
> > > tegra2). I haven't seen any black on white contracts saying that,
> > > though :)
> > The spec on the web seems to say fairly clearly that it's optional, at
> > least in theory.  I guess they might have commercial reasons for not
> > wanting to sell it without VFP in any given situation.
> > 
> > See:
> > 
> > http://www.arm.com/products/processors/cortex-a/cortex-a5.php?tab=Specificat
> > ions
> > 
> > for example
> 
> thats only for for a5. For procesors koen mentioned VFP is mandatory

Oh yeah, you're right.  Sorry, I didn't read his email carefully enough.

The original question, though, was whether VFP is mandatory for the
ARMv7-A architecture.  Irrespective of what the situation is with
A8/A9/A15, Cortex-A5 is still an ARMv7-A processor and hence VFP can't
be mandatory for the architecture as a whole.

p.

Patch

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f12b3cb..3ed1bb8 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -133,6 +133,13 @@  def generate_git_config(e):
                 f.write(proxy_command)
                 f.close
 
+def pkgarch_mapping(d):
+    # Compatibility mappings of TUNE_PKGARCH (opt in)
+    if d.getVar("PKGARCHCOMPAT_ARMV7A", True):
+        if d.getVar("TUNE_PKGARCH", True) == "armv7a-vfp-neon":
+            d.setVar("TUNE_PKGARCH", "armv7a")
+
+
 addhandler base_eventhandler
 python base_eventhandler() {
 	from bb import note, error, data
@@ -203,6 +210,7 @@  python base_eventhandler() {
 
         if name == "ConfigParsed":
                 generate_git_config(e)
+                pkgarch_mapping(e.data)
 
 	if not data in e.__dict__:
 		return