[PATCH 0/5] Add support for PowerPC e500v2/SPE

[PATCH 0/5] Add support for PowerPC e500v2/SPE

[Kumar Gala]

The majority of support for the PowerPC e500v2/SPE target already
exists.  However some minor cleans are required to get things working
completely.

The e500v2 utilizes a unique floating point programming model / ABI from
other PowerPC targets and thus requires special handling.

- k

[PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

[Kumar Gala]

The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "spe" to distinguish this choice.  When building
the toolchain for this ABI we need configure gcc with --enable-e500_double.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 meta/recipes-devtools/gcc/gcc-4.6.inc    |    2 +-
 meta/recipes-devtools/gcc/gcc-common.inc |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 56064b5..b719155 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
 require gcc-common.inc
 
-PR = "r8"
+PR = "r9"
 
 # Third digit in PV should be incremented after a minor release
 # happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index 7bf036c..409ad01 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
 def get_gcc_fpu_setting(bb, d):
     if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
         return "--with-float=soft"
+    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
+        return "--enable-e500_double"
     return ""
 
 def get_gcc_mips_plt_setting(bb, d):
-- 
1.7.3.4

[PATCH 2/5] tclibc-*glibc: Utilize TARGET_FPU for gnuspe setting

[Kumar Gala]

Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
we build native toolchains.  So we can utilize TARGET_FPU being set to
"spe" to determine if we should enable the gnuspe ABI.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 meta/conf/distro/include/tclibc-eglibc.inc |    2 +-
 meta/conf/distro/include/tclibc-glibc.inc  |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/tclibc-eglibc.inc b/meta/conf/distro/include/tclibc-eglibc.inc
index e070aad..0cddcd4 100644
--- a/meta/conf/distro/include/tclibc-eglibc.inc
+++ b/meta/conf/distro/include/tclibc-eglibc.inc
@@ -5,7 +5,7 @@
 TARGET_OS = "linux"
 TARGET_OS_arm = "linux-gnueabi"
 TARGET_OS_armeb = "linux-gnueabi"
-TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"
+TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['spe']]}"
 
 # Add glibc overrides to the overrides for eglibc.
 OVERRIDES .= ":libc-glibc"
diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
index 5e7afc1..22f7d29 100644
--- a/meta/conf/distro/include/tclibc-glibc.inc
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -5,7 +5,7 @@
 TARGET_OS = "linux"
 TARGET_OS_arm = "linux-gnueabi"
 TARGET_OS_armeb = "linux-gnueabi"
-TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"
+TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['spe']]}"
 
 # Add glibc to the overrides.
 OVERRIDES =. "libc-glibc:"
-- 
1.7.3.4

[PATCH 3/5] tune-ppce500v2: Add a tune file for PowerPC e500v2 cores

[Kumar Gala]

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 meta/conf/machine/include/tune-ppce500v2.inc |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
 create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc

diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
new file mode 100644
index 0000000..9901045
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce500v2.inc
@@ -0,0 +1,5 @@
+TARGET_CC_ARCH = "-mcpu=8548 -mabi=spe -mspe"
+BASE_PACKAGE_ARCH = "ppce500v2"
+FEED_ARCH = "ppce500v2"
+PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
+TARGET_OS_powerpc = "linux-gnuspe"
-- 
1.7.3.4

[PATCH 4/5] openssl: Add handling for linux-gnuspe-powerpc

[Kumar Gala]

If trying to build for an e500v2 target openssl will fail to build since
the configure script didn't know how to handle a 'gnuspe' target.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 meta/recipes-connectivity/openssl/openssl.inc      |    3 +++
 .../recipes-connectivity/openssl/openssl_0.9.8r.bb |    2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc b/meta/recipes-connectivity/openssl/openssl.inc
index 39143ad..79620b3 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -80,6 +80,9 @@ do_configure () {
 	linux-powerpc)
 		target=linux-ppc
 		;;
+	linux-gnuspe-powerpc)
+		target=linux-ppc
+		;;
 	linux-supersparc)
 		target=linux-sparcv8
 		;;
diff --git a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb b/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
index ea83cb8..344747f 100644
--- a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
+++ b/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
@@ -1,6 +1,6 @@
 require openssl.inc
 
-PR = "r3"
+PR = "r4"
 SRC_URI += "file://debian/ca.patch \
             file://debian/config-hurd.patch;apply=no \
             file://debian/debian-targets.patch \
-- 
1.7.3.4

[PATCH 5/5] flac: fix build issues with e500v2 (gnuspe) toolchain

[Kumar Gala]

For a PPC target flac will try to build with altivec optimizations.
Altivec and SPE are mutually exclusive options.  Between flac's
configure choices and the ppce500v2 tune file options we'd end up with
a compile invocation with the following arguments:

-mabi=spe -mspe -mabi=altivec -maltivec

Which would cause the compile to fail due to the mutual exclusion.

Pulled in a patch from the debian SPE port that addresses this issue:

http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-June/010212.html

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 .../flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch   |   74 ++++++++++++++++++++
 meta/recipes-multimedia/flac/flac_1.2.1.bb         |    5 +-
 2 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch

diff --git a/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch b/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch
new file mode 100644
index 0000000..8626336
--- /dev/null
+++ b/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch
@@ -0,0 +1,74 @@
+From f9b017c2c958d968cc5dfd36dc68fc8e5fb89a58 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Date: Fri, 11 Jun 2010 09:48:58 +0200
+Subject: [PATCH] No AltiVec on SPE
+
+Consider *gnuspe which matches powerpc-unknown-linux-gnuspe where
+AltiVec is not available at all. This triplet uses SPE which is
+incompatible with AltiVec shares the same opcode range and can't be used
+at all.
+
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+---
+ configure.in            |    8 ++++++++
+ src/libFLAC/Makefile.am |   10 +++++++++-
+ 2 files changed, 17 insertions(+), 1 deletions(-)
+
+diff --git a/configure.in b/configure.in
+index bfa6d8e..17b7c73 100644
+--- a/configure.in
++++ b/configure.in
+@@ -82,6 +82,14 @@ case "$host" in
+ 	*) OBJ_FORMAT=elf ;;
+ esac
+ AC_SUBST(OBJ_FORMAT)
++case "$host" in
++	*-gnuspe)
++		abi_spe=true
++		AC_DEFINE(FLAC__CPU_PPC_SPE)
++		AH_TEMPLATE(FLAC__CPU_PPC_SPE, [define if building for PowerPC with SPE ABI])
++		;;
++esac
++AM_CONDITIONAL(FLaC__CPU_PPC_SPE, test "x$abi_spe" = xtrue)
+ 
+ # only needed because of ntohl() usage, can get rid of after that's gone:
+ case "$host" in
+diff --git a/src/libFLAC/Makefile.am b/src/libFLAC/Makefile.am
+index cbfb0ac..5785372 100644
+--- a/src/libFLAC/Makefile.am
++++ b/src/libFLAC/Makefile.am
+@@ -40,8 +40,13 @@ if FLaC__SYS_DARWIN
+ CPUCFLAGS = -faltivec -force_cpusubtype_ALL -DFLAC__NO_ASM
+ else
+ # Linux-gcc for PPC does not have -force_cpusubtype_ALL, it is Darwin-specific
++CPUCFLAGS =
++if FLaC__CPU_PPC_SPE
++else
++CPUCFLAGS += -maltivec -mabi=altivec
++endif
+ #@@@ PPC optimizations temporarily disabled
+-CPUCFLAGS = -maltivec -mabi=altivec -DFLAC__NO_ASM
++CPUCFLAGS += -DFLAC__NO_ASM
+ endif
+ endif
+ 
+@@ -58,6 +63,8 @@ endif
+ if FLaC__CPU_PPC
+ ARCH_SUBDIRS = ppc
+ if FLaC__HAS_AS__TEMPORARILY_DISABLED
++if FLaC__CPU_PPC_SPE
++else
+ LOCAL_EXTRA_LIBADD = ppc/as/libFLAC-asm.la
+ LOCAL_EXTRA_LDFLAGS = "-Wl,-read_only_relocs,warning"
+ else
+@@ -68,6 +75,7 @@ endif
+ endif
+ endif
+ endif
++endif
+ 
+ libFLAC_la_LIBADD = $(LOCAL_EXTRA_LIBADD) @OGG_LIBS@
+ 
+-- 
+1.5.6.5
+
diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb b/meta/recipes-multimedia/flac/flac_1.2.1.bb
index 92bcec6..fc8e14f 100644
--- a/meta/recipes-multimedia/flac/flac_1.2.1.bb
+++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb
@@ -14,12 +14,13 @@ LIC_FILES_CHKSUM = "file://COPYING.FDL;md5=ad1419ecc56e060eccf8184a87c4285f \
                     file://include/FLAC/all.h;beginline=64;endline=69;md5=64474f2b22e9e77b28d8b8b25c983a48"
 DEPENDS = "libogg"
 
-PR = "r0"
+PR = "r1"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/flac/flac-${PV}.tar.gz \
            file://disable-xmms-plugin.patch;patch=1 \
            file://flac-gcc43-fixes.patch;patch=1 \
-           file://xmms.m4"
+           file://xmms.m4 \
+           file://0001-No-AltiVec-on-SPE.patch"
 
 SRC_URI[md5sum] = "153c8b15a54da428d1f0fadc756c22c7"
 SRC_URI[sha256sum] = "9635a44bceb478bbf2ee8a785cf6986fba525afb5fad1fd4bba73cf71f2d3edf"
-- 
1.7.3.4

Re: [PATCH 0/5] Add support for PowerPC e500v2/SPE

[Khem Raj]

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> The majority of support for the PowerPC e500v2/SPE target already
> exists.  However some minor cleans are required to get things working
> completely.
>
> The e500v2 utilizes a unique floating point programming model / ABI from
> other PowerPC targets and thus requires special handling.

Hi Kumar

Thanks for the patches

all these patches should be CCed to
openembedded-core@lists.openembedded.org as well

>
> - k
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [PATCH 3/5] tune-ppce500v2: Add a tune file for PowerPC e500v2 cores

[Khem Raj]

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>  meta/conf/machine/include/tune-ppce500v2.inc |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>  create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc
>
> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
> new file mode 100644
> index 0000000..9901045
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
> @@ -0,0 +1,5 @@
> +TARGET_CC_ARCH = "-mcpu=8548 -mabi=spe -mspe"
> +BASE_PACKAGE_ARCH = "ppce500v2"
> +FEED_ARCH = "ppce500v2"
> +PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
> +TARGET_OS_powerpc = "linux-gnuspe"

I think TARGET_OS is unwanted here


> --
> 1.7.3.4
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

[Khem Raj]

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> The e500v2 core utilizes a unique floating point programming model / ABI.
> We utilize TARGET_FPU = "spe" to distinguish this choice.  When building
> the toolchain for this ABI we need configure gcc with --enable-e500_double.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>  meta/recipes-devtools/gcc/gcc-4.6.inc    |    2 +-
>  meta/recipes-devtools/gcc/gcc-common.inc |    2 ++
>  2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
> index 56064b5..b719155 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
> @@ -1,6 +1,6 @@
>  require gcc-common.inc
>
> -PR = "r8"
> +PR = "r9"
>
>  # Third digit in PV should be incremented after a minor release
>  # happens from this branch on gcc e.g. currently its 4.6.0
> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
> index 7bf036c..409ad01 100644
> --- a/meta/recipes-devtools/gcc/gcc-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
> @@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
>  def get_gcc_fpu_setting(bb, d):
>     if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>         return "--with-float=soft"
> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
> +        return "--enable-e500_double"
>     return ""
>

this will enable e500_double even for e500v1 which IIRC does not have
DFP support
have you tried building for e500v1 with this ?

>  def get_gcc_mips_plt_setting(bb, d):
> --
> 1.7.3.4
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [PATCH 2/5] tclibc-*glibc: Utilize TARGET_FPU for gnuspe setting

[Khem Raj]

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
> we build native toolchains.  So we can utilize TARGET_FPU being set to
> "spe" to determine if we should enable the gnuspe ABI.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>  meta/conf/distro/include/tclibc-eglibc.inc |    2 +-
>  meta/conf/distro/include/tclibc-glibc.inc  |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

similar change is needed for tclibc-uclibc.inc as well. something like

TARGET_OS_powerpc =
"linux-uclibc${@['','spe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in
['ppce500', 'ppce500v2']]}"

> diff --git a/meta/conf/distro/include/tclibc-eglibc.inc b/meta/conf/distro/include/tclibc-eglibc.inc
> index e070aad..0cddcd4 100644
> --- a/meta/conf/distro/include/tclibc-eglibc.inc
> +++ b/meta/conf/distro/include/tclibc-eglibc.inc
> @@ -5,7 +5,7 @@
>  TARGET_OS = "linux"
>  TARGET_OS_arm = "linux-gnueabi"
>  TARGET_OS_armeb = "linux-gnueabi"
> -TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"
> +TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['spe']]}"
>
>  # Add glibc overrides to the overrides for eglibc.
>  OVERRIDES .= ":libc-glibc"
> diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
> index 5e7afc1..22f7d29 100644
> --- a/meta/conf/distro/include/tclibc-glibc.inc
> +++ b/meta/conf/distro/include/tclibc-glibc.inc
> @@ -5,7 +5,7 @@
>  TARGET_OS = "linux"
>  TARGET_OS_arm = "linux-gnueabi"
>  TARGET_OS_armeb = "linux-gnueabi"
> -TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"
> +TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['spe']]}"
>
>  # Add glibc to the overrides.
>  OVERRIDES =. "libc-glibc:"
> --
> 1.7.3.4
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [PATCH 3/5] tune-ppce500v2: Add a tune file for PowerPC e500v2 cores

[Kumar Gala]

On Jul 19, 2011, at 1:01 AM, Khem Raj wrote:

> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>>  meta/conf/machine/include/tune-ppce500v2.inc |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>  create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc
>> 
>> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
>> new file mode 100644
>> index 0000000..9901045
>> --- /dev/null
>> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
>> @@ -0,0 +1,5 @@
>> +TARGET_CC_ARCH = "-mcpu=8548 -mabi=spe -mspe"
>> +BASE_PACKAGE_ARCH = "ppce500v2"
>> +FEED_ARCH = "ppce500v2"
>> +PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
>> +TARGET_OS_powerpc = "linux-gnuspe"
> 
> I think TARGET_OS is unwanted here

Thanks, left over from my debug attempts.

- k

Re: [PATCH 2/5] tclibc-*glibc: Utilize TARGET_FPU for gnuspe setting

[Kumar Gala]

On Jul 19, 2011, at 1:08 AM, Khem Raj wrote:

> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>> Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
>> we build native toolchains.  So we can utilize TARGET_FPU being set to
>> "spe" to determine if we should enable the gnuspe ABI.
>> 
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> meta/conf/distro/include/tclibc-eglibc.inc |    2 +-
>> meta/conf/distro/include/tclibc-glibc.inc  |    2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>> 
> 
> similar change is needed for tclibc-uclibc.inc as well. something like
> 
> TARGET_OS_powerpc =
> "linux-uclibc${@['','spe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in
> ['ppce500', 'ppce500v2']]}"

I can add it, but unshure if anyone has e500/spe working with uclibc.

- k

Re: [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

[Kumar Gala]

On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:

> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>> The e500v2 core utilizes a unique floating point programming model / ABI.
>> We utilize TARGET_FPU = "spe" to distinguish this choice.  When building
>> the toolchain for this ABI we need configure gcc with --enable-e500_double.
>> 
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>>  meta/recipes-devtools/gcc/gcc-4.6.inc    |    2 +-
>>  meta/recipes-devtools/gcc/gcc-common.inc |    2 ++
>>  2 files changed, 3 insertions(+), 1 deletions(-)
>> 
>> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
>> index 56064b5..b719155 100644
>> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
>> @@ -1,6 +1,6 @@
>>  require gcc-common.inc
>> 
>> -PR = "r8"
>> +PR = "r9"
>> 
>>  # Third digit in PV should be incremented after a minor release
>>  # happens from this branch on gcc e.g. currently its 4.6.0
>> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
>> index 7bf036c..409ad01 100644
>> --- a/meta/recipes-devtools/gcc/gcc-common.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
>> @@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
>>  def get_gcc_fpu_setting(bb, d):
>>     if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>>         return "--with-float=soft"
>> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
>> +        return "--enable-e500_double"
>>     return ""
>> 
> 
> this will enable e500_double even for e500v1 which IIRC does not have
> DFP support
> have you tried building for e500v1 with this ?

I think you are correct.  Any suggestions on how to distinguish e500v1 vs e500v2?  Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.

I could do:

TARGET_FPU = "ppc-efs"  [Embedded scalar single-precision floating-point]
TARGET_FPU = "ppc-efd"  [Embedded scalar double-precision floating-point]

Than meta/recipes-devtools/gcc/gcc-common.inc:

 def get_gcc_fpu_setting(bb, d):
    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
        return "--with-float=soft"
+    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'ppc-efd' ]:
+        return "--enable-e500_double"
    return ""

And meta/conf/distro/include/tclibc-*libc.inc:

TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"

thoughts?

- k

Re: [PATCH 0/5] Add support for PowerPC e500v2/SPE

[Koen Kooi]

Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:

> The majority of support for the PowerPC e500v2/SPE target already
> exists.  However some minor cleans are required to get things working
> completely.
> 
> The e500v2 utilizes a unique floating point programming model / ABI from
> other PowerPC targets and thus requires special handling.


These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree

Re: [PATCH 0/5] Add support for PowerPC e500v2/SPE

[Kumar Gala]

On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:

> 
> Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:
> 
>> The majority of support for the PowerPC e500v2/SPE target already
>> exists.  However some minor cleans are required to get things working
>> completely.
>> 
>> The e500v2 utilizes a unique floating point programming model / ABI from
>> other PowerPC targets and thus requires special handling.
> 
> 
> These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree

Will do so, it was unclear to me how patches go from oe-core to/from yocto.

- k

Re: [yocto] [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

[Kumar Gala]

Adding openembedded-core to see if any feedback on my query.

- k

On Jul 19, 2011, at 1:47 AM, Kumar Gala wrote:

> 
> On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:
> 
>> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> The e500v2 core utilizes a unique floating point programming model / ABI.
>>> We utilize TARGET_FPU = "spe" to distinguish this choice.  When building
>>> the toolchain for this ABI we need configure gcc with --enable-e500_double.
>>> 
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> meta/recipes-devtools/gcc/gcc-4.6.inc    |    2 +-
>>> meta/recipes-devtools/gcc/gcc-common.inc |    2 ++
>>> 2 files changed, 3 insertions(+), 1 deletions(-)
>>> 
>>> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> index 56064b5..b719155 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> @@ -1,6 +1,6 @@
>>> require gcc-common.inc
>>> 
>>> -PR = "r8"
>>> +PR = "r9"
>>> 
>>> # Third digit in PV should be incremented after a minor release
>>> # happens from this branch on gcc e.g. currently its 4.6.0
>>> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
>>> index 7bf036c..409ad01 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-common.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
>>> @@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
>>> def get_gcc_fpu_setting(bb, d):
>>>    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>>>        return "--with-float=soft"
>>> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
>>> +        return "--enable-e500_double"
>>>    return ""
>>> 
>> 
>> this will enable e500_double even for e500v1 which IIRC does not have
>> DFP support
>> have you tried building for e500v1 with this ?
> 
> I think you are correct.  Any suggestions on how to distinguish e500v1 vs e500v2?  Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.
> 
> I could do:
> 
> TARGET_FPU = "ppc-efs"  [Embedded scalar single-precision floating-point]
> TARGET_FPU = "ppc-efd"  [Embedded scalar double-precision floating-point]
> 
> Than meta/recipes-devtools/gcc/gcc-common.inc:
> 
> def get_gcc_fpu_setting(bb, d):
>    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>        return "--with-float=soft"
> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'ppc-efd' ]:
> +        return "--enable-e500_double"
>    return ""
> 
> And meta/conf/distro/include/tclibc-*libc.inc:
> 
> TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"
> 
> thoughts?
> 
> - k
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

[Kumar Gala]

Adding openembedded-core to see if any feedback on my query.

- k

On Jul 19, 2011, at 1:47 AM, Kumar Gala wrote:

> 
> On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:
> 
>> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> The e500v2 core utilizes a unique floating point programming model / ABI.
>>> We utilize TARGET_FPU = "spe" to distinguish this choice.  When building
>>> the toolchain for this ABI we need configure gcc with --enable-e500_double.
>>> 
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> meta/recipes-devtools/gcc/gcc-4.6.inc    |    2 +-
>>> meta/recipes-devtools/gcc/gcc-common.inc |    2 ++
>>> 2 files changed, 3 insertions(+), 1 deletions(-)
>>> 
>>> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> index 56064b5..b719155 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> @@ -1,6 +1,6 @@
>>> require gcc-common.inc
>>> 
>>> -PR = "r8"
>>> +PR = "r9"
>>> 
>>> # Third digit in PV should be incremented after a minor release
>>> # happens from this branch on gcc e.g. currently its 4.6.0
>>> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
>>> index 7bf036c..409ad01 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-common.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
>>> @@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
>>> def get_gcc_fpu_setting(bb, d):
>>>    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>>>        return "--with-float=soft"
>>> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
>>> +        return "--enable-e500_double"
>>>    return ""
>>> 
>> 
>> this will enable e500_double even for e500v1 which IIRC does not have
>> DFP support
>> have you tried building for e500v1 with this ?
> 
> I think you are correct.  Any suggestions on how to distinguish e500v1 vs e500v2?  Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.
> 
> I could do:
> 
> TARGET_FPU = "ppc-efs"  [Embedded scalar single-precision floating-point]
> TARGET_FPU = "ppc-efd"  [Embedded scalar double-precision floating-point]
> 
> Than meta/recipes-devtools/gcc/gcc-common.inc:
> 
> def get_gcc_fpu_setting(bb, d):
>    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>        return "--with-float=soft"
> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'ppc-efd' ]:
> +        return "--enable-e500_double"
>    return ""
> 
> And meta/conf/distro/include/tclibc-*libc.inc:
> 
> TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"
> 
> thoughts?
> 
> - k
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Trying to create OpenDDS recipe

[Ourada, Paul]

I hope this is the correct place to post this. If not, please let me
know.

I'm trying to create a recipe for OpenDDS. The recipe works so far as
fetching, unpacking, and configuration. Or it seems to. :) Part of the
configuration piece is that it also pulls down ACE+TAO real-time CORBA.
This part works fine as well.

I set S as follows to match the unpacking directories enforced by the
tar file:

S = ${WORKINGDIR}/DDS

The package comes with a configuration script pre-built, and it expects
to be told where glibc is. So, I write do_configure as follows:

EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"

do_configure() {
    ${S}/configure ${EXTRA_OECONF}
}

The problem that I run into is during compilation. I write the following
for do_compile()

do_compile() {
    oenote ${STAGING_DIR}
    cd ${S} && make
}

This works right up until there is a compile error in ACE+TAO. Of
course, I build the entire DDS package, including ACE+TAO, with no
hiccups in Ubuntu, so I understand that this is a
cross-compile/environment issue.

The compile error is that it cannot find features.h, which is clearly in
${STAGING_LIBDIR}/${MACHINE}/usr/include. The compile command which is
being executed is as follows (this is going to be ugly, let me know if
there's a better way to include this, such as a pastebin somewhere):

| make[1]: Entering directory
`/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
_wrappers/TAO/TAO_IDL'
| 
| GNUmakefile:
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/TAO/TAO_IDL/GNUmakefile.TAO_IDL_EXE MAKEFLAGS=w
| 
| i586-poky-linux-g++ -march=i586
--sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86
-fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith
-ggdb -pipe -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE
-I/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/AC
E_wrappers -DACE_HAS_EXCEPTIONS -DACE_NO_INLINE -I../.. -Iinclude
-Ibe_include -Ife -I.. -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++
-march=i586 --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"
-c -o .obj/driver/drv_preproc.o driver/drv_preproc.cpp
| <command-line>:0:22: warning: missing terminating " character
| In file included from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-linux-common.h:30:0,
|                  from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-linux.h:14,
|                  from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config.h:1,
|                  from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-macros.h:24,
|                  from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-lite.h:24,
|                  from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/os_include/os_limits.h:21,
|                  from include/idl_defines.h:70,
|                  from driver/drv_preproc.cpp:70:
|
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-posix.h:7:20: fatal error: unistd.h: No such file or
directory
| compilation terminated.
| make[1]: *** [.obj/driver/drv_preproc.o] Error 1
| make[1]: Leaving directory
`/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
_wrappers/TAO/TAO_IDL'
| make: *** [TAO_IDL_EXE] Error 2
| ERROR: Function 'do_compile' failed (see
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/temp
/log.do_compile.17412 for further information)
NOTE: package opendds-2.3-r0: task do_compile: Failed
ERROR: Task 5
(/opt/yocto/poky-bernard-5.0.1/meta/recipes-middleware/opendds/opendds_2
.3.bb, do_compile) failed with exit code '1'

The thing that is puzzling me is that --sysroot seems to be pointing in
the general direction of ${STAGING_DIR} and so the include directive,
#include <features.h> should be good. I have checked, and features.h is
in the /usr/include subdirectory there.

Does anyone have a clue they could lend me?

Thanks,

Paul E. Ourada
Sr. Principal Software Engineer
Covidien, Energy-based Devices
5920 Longbow Drive
Boulder, CO 80301
paul.ourada@covidien.com
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741

Re: [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

[Khem Raj]

On Mon, Jul 18, 2011 at 11:47 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:
>
>> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> The e500v2 core utilizes a unique floating point programming model / ABI.
>>> We utilize TARGET_FPU = "spe" to distinguish this choice.  When building
>>> the toolchain for this ABI we need configure gcc with --enable-e500_double.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>>  meta/recipes-devtools/gcc/gcc-4.6.inc    |    2 +-
>>>  meta/recipes-devtools/gcc/gcc-common.inc |    2 ++
>>>  2 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> index 56064b5..b719155 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
>>> @@ -1,6 +1,6 @@
>>>  require gcc-common.inc
>>>
>>> -PR = "r8"
>>> +PR = "r9"
>>>
>>>  # Third digit in PV should be incremented after a minor release
>>>  # happens from this branch on gcc e.g. currently its 4.6.0
>>> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
>>> index 7bf036c..409ad01 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-common.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
>>> @@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
>>>  def get_gcc_fpu_setting(bb, d):
>>>     if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>>>         return "--with-float=soft"
>>> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
>>> +        return "--enable-e500_double"
>>>     return ""
>>>
>>
>> this will enable e500_double even for e500v1 which IIRC does not have
>> DFP support
>> have you tried building for e500v1 with this ?
>
> I think you are correct.  Any suggestions on how to distinguish e500v1 vs e500v2?  Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.
>
> I could do:
>
> TARGET_FPU = "ppc-efs"  [Embedded scalar single-precision floating-point]
> TARGET_FPU = "ppc-efd"  [Embedded scalar double-precision floating-point]

thats fine. using spfp or dpfp is another option.
however you have to make sure that TARGET_FPU is not checking for spe
anywhere in whole tree

>
> Than meta/recipes-devtools/gcc/gcc-common.inc:
>
>  def get_gcc_fpu_setting(bb, d):
>    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
>        return "--with-float=soft"
> +    if bb.data.getVar('TARGET_FPU', d, 1) in [ 'ppc-efd' ]:
> +        return "--enable-e500_double"
>    return ""
>
> And meta/conf/distro/include/tclibc-*libc.inc:
>
> TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"
>
> thoughts?
>
> - k

Re: [PATCH 0/5] Add support for PowerPC e500v2/SPE

[Saul Wold]

On 07/19/2011 06:17 AM, Kumar Gala wrote:
>
> On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:
>
>>
>> Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:
>>
>>> The majority of support for the PowerPC e500v2/SPE target already
>>> exists.  However some minor cleans are required to get things working
>>> completely.
>>>
>>> The e500v2 utilizes a unique floating point programming model / ABI from
>>> other PowerPC targets and thus requires special handling.
>>
>>
>> These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
>
> Will do so, it was unclear to me how patches go from oe-core to/from yocto.
>
Kumar,

If it goes into the meta/recipes or meta/conf area then it goes to 
oe-core, if the patch is the PPC machine-specific and changes are in 
meta-yocto, then it should go to the yocto ml.

As mentioned above, all these patches should go to oe-core

I hope that clears things up.

Sau!

> - k
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [PATCH 0/5] Add support for PowerPC e500v2/SPE

[Kumar Gala]

On Jul 19, 2011, at 10:32 AM, Saul Wold wrote:

> On 07/19/2011 06:17 AM, Kumar Gala wrote:
>> 
>> On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:
>> 
>>> 
>>> Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:
>>> 
>>>> The majority of support for the PowerPC e500v2/SPE target already
>>>> exists.  However some minor cleans are required to get things working
>>>> completely.
>>>> 
>>>> The e500v2 utilizes a unique floating point programming model / ABI from
>>>> other PowerPC targets and thus requires special handling.
>>> 
>>> 
>>> These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
>> 
>> Will do so, it was unclear to me how patches go from oe-core to/from yocto.
>> 
> Kumar,
> 
> If it goes into the meta/recipes or meta/conf area then it goes to oe-core, if the patch is the PPC machine-specific and changes are in meta-yocto, then it should go to the yocto ml.
> 
> As mentioned above, all these patches should go to oe-core
> 
> I hope that clears things up.
> 
> Sau!

Its a start, how to things go from oe-core git to yocto git?

- k

Re: [PATCH 0/5] Add support for PowerPC e500v2/SPE

[Saul Wold]

On 07/19/2011 08:40 AM, Kumar Gala wrote:
>
> On Jul 19, 2011, at 10:32 AM, Saul Wold wrote:
>
>> On 07/19/2011 06:17 AM, Kumar Gala wrote:
>>>
>>> On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:
>>>
>>>>
>>>> Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:
>>>>
>>>>> The majority of support for the PowerPC e500v2/SPE target already
>>>>> exists.  However some minor cleans are required to get things working
>>>>> completely.
>>>>>
>>>>> The e500v2 utilizes a unique floating point programming model / ABI from
>>>>> other PowerPC targets and thus requires special handling.
>>>>
>>>>
>>>> These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
>>>
>>> Will do so, it was unclear to me how patches go from oe-core to/from yocto.
>>>
>> Kumar,
>>
>> If it goes into the meta/recipes or meta/conf area then it goes to oe-core, if the patch is the PPC machine-specific and changes are in meta-yocto, then it should go to the yocto ml.
>>
>> As mentioned above, all these patches should go to oe-core
>>
>> I hope that clears things up.
>>
>> Sau!
>
> Its a start, how to things go from oe-core git to yocto git?
>
Richard Purdie the maintainer for both has a process he uses to merge 
changes from oe-core to yocto. Anything in oe-core will be merged into 
yocto's meta directory.

Sau!

> - k

Re: Trying to create OpenDDS recipe

[Darren Hart]

Hi Paul,

On 07/19/2011 07:41 AM, Ourada, Paul wrote:
> I hope this is the correct place to post this. If not, please let me
> know.

This is the right place. In the future please don't reply to an existing
post as your message then gets threaded with the one you replied to
(likely why you didn't receive a response so far - that I see anyway).

> 
> I'm trying to create a recipe for OpenDDS. The recipe works so far as
> fetching, unpacking, and configuration. Or it seems to. :) Part of the
> configuration piece is that it also pulls down ACE+TAO real-time CORBA.
> This part works fine as well.
> 
> I set S as follows to match the unpacking directories enforced by the
> tar file:
> 
> S = ${WORKINGDIR}/DDS
> 
> The package comes with a configuration script pre-built, and it expects
> to be told where glibc is. So, I write do_configure as follows:
> 
> EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"
> 
> do_configure() {
>     ${S}/configure ${EXTRA_OECONF}
> }
> 
> The problem that I run into is during compilation. I write the following
> for do_compile()
> 
> do_compile() {
>     oenote ${STAGING_DIR}
>     cd ${S} && make
> }

Is there a reason you are overriding configure and compile? These appear
to be autoconf projects, which should just work for recipes using
autotools.bbclass.

> 
> This works right up until there is a compile error in ACE+TAO. Of
> course, I build the entire DDS package, including ACE+TAO, with no
> hiccups in Ubuntu, so I understand that this is a
> cross-compile/environment issue.
> 
> The compile error is that it cannot find features.h, which is clearly in
> ${STAGING_LIBDIR}/${MACHINE}/usr/include. The compile command which is
> being executed is as follows (this is going to be ugly, let me know if
> there's a better way to include this, such as a pastebin somewhere):

This is better - the pastebin isn't as reliable, and having it inline to
review and for future reference is much preferred.

> 
> | make[1]: Entering directory
> `/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
> _wrappers/TAO/TAO_IDL'
> | 
> | GNUmakefile:
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/TAO/TAO_IDL/GNUmakefile.TAO_IDL_EXE MAKEFLAGS=w
> | 
> | i586-poky-linux-g++ -march=i586
> --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86
> -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith
> -ggdb -pipe -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE
> -I/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/AC
> E_wrappers -DACE_HAS_EXCEPTIONS -DACE_NO_INLINE -I../.. -Iinclude
> -Ibe_include -Ife -I.. -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++
> -march=i586 --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"
> -c -o .obj/driver/drv_preproc.o driver/drv_preproc.cpp
> | <command-line>:0:22: warning: missing terminating " character
> | In file included from
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/config-linux-common.h:30:0,
> |                  from
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/config-linux.h:14,
> |                  from
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/config.h:1,
> |                  from
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/config-macros.h:24,
> |                  from
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/config-lite.h:24,
> |                  from
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/os_include/os_limits.h:21,
> |                  from include/idl_defines.h:70,
> |                  from driver/drv_preproc.cpp:70:
> |
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
> wrappers/ace/config-posix.h:7:20: fatal error: unistd.h: No such file or
> directory

Do you see unistd.h under /opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86 ?


> | compilation terminated.
> | make[1]: *** [.obj/driver/drv_preproc.o] Error 1
> | make[1]: Leaving directory
> `/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
> _wrappers/TAO/TAO_IDL'
> | make: *** [TAO_IDL_EXE] Error 2
> | ERROR: Function 'do_compile' failed (see
> /opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/temp
> /log.do_compile.17412 for further information)
> NOTE: package opendds-2.3-r0: task do_compile: Failed
> ERROR: Task 5
> (/opt/yocto/poky-bernard-5.0.1/meta/recipes-middleware/opendds/opendds_2
> .3.bb, do_compile) failed with exit code '1'
> 
> The thing that is puzzling me is that --sysroot seems to be pointing in
> the general direction of ${STAGING_DIR} and so the include directive,
> #include <features.h> should be good. I have checked, and features.h is
> in the /usr/include subdirectory there.

I see unistd.h missing, not features.h.

--
Darren

> 
> Does anyone have a clue they could lend me?
> 
> Thanks,
> 
> Paul E. Ourada
> Sr. Principal Software Engineer
> Covidien, Energy-based Devices
> 5920 Longbow Drive
> Boulder, CO 80301
> paul.ourada@covidien.com
> www.covidien.com
> Main: 303-530-2300
> Ofc: 303-581-6940
> Fax: 303-581-6741
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Trying to create OpenDDS recipe

[Ourada, Paul]

Hi Darren -

Thanks for getting back to me. I have been able to get a lot further with the recipe. It turns out that the problem is in the makefiles for OpenDDS. I'll detail further below.

Paul E. Ourada
Sr. Principal Software Engineer
Covidien, Energy-based Devices
5920 Longbow Drive
Boulder, CO 80301
paul.ourada@covidien.com
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741


> Hi Paul,

On 07/19/2011 07:41 AM, Ourada, Paul wrote:
>> I hope this is the correct place to post this. If not, please let me
>> know.

> This is the right place. In the future please don't reply to an existing
> post as your message then gets threaded with the one you replied to
> (likely why you didn't receive a response so far - that I see anyway).

I guess I thought that changing the subject would have fixed that. Guess the 
mail list s/w is smarter than that. :)

>> 
>> I'm trying to create a recipe for OpenDDS. The recipe works so far as
>> fetching, unpacking, and configuration. Or it seems to. :) Part of the
>> configuration piece is that it also pulls down ACE+TAO real-time CORBA.
>> This part works fine as well.
>> 
>> I set S as follows to match the unpacking directories enforced by the
>> tar file:
>> 
>> S = ${WORKINGDIR}/DDS
>> 
>> The package comes with a configuration script pre-built, and it expects
>> to be told where glibc is. So, I write do_configure as follows:
>> 
>> EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"
>> 
>> do_configure() {
>>     ${S}/configure ${EXTRA_OECONF}
>> }
>> 
>> The problem that I run into is during compilation. I write the following
>> for do_compile()
>> 
>> do_compile() {
>>     oenote ${STAGING_DIR}
>>     cd ${S} && make
>> }

> Is there a reason you are overriding configure and compile? These appear
> to be autoconf projects, which should just work for recipes using
> autotools.bbclass.

I had tried that initially. The configuration file is already supplied, so running autotools to create the configure script is not necessary, but running ./configure is. Is there a better way to do that?

	:
	:
<< most of the compiler command line gobblety-gook snipped>>

>> -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++
>> -march=i586 --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"


>> The thing that is puzzling me is that --sysroot seems to be pointing in
>> the general direction of ${STAGING_DIR} and so the include directive,
>> #include <features.h>> should be good. I have checked, and features.h is
>> in the /usr/include subdirectory there.

> I see unistd.h missing, not features.h.

You're right, it was complaining about unistd.h, but it turns out that the real culprit was the TAO_IDL_PREPROCESSOR macro above. When I compared it to what was being emitted in the Ubuntu compile, I saw that the long, nasty, compound, double-quoted thing should have just been "i586-poky-linux-g++." TAO_ID_PREPROCESSOR was being assigned the value of ${CXX}. 

It appears that instead of pre-pending the ${CPPFLAGS} variable, yocto/poky recipes were appending the cross-compile build variables to ${CXX}. I patched the OpenDDS makefile(s) to look for the first word in the ${CXX} macro, and substituted that in the assignment of TAO_IDL_PREPROCESSOR. Dunno if that's the "right" way to do it, or if there's a bug in ${CXX} assignment?

Anyway, I think that I'm getting there w/the recipe. I'm sure that there are some things I'm doing wrong. For instance, I'm no longer cd'ing to ${S}, as OE already takes me there. I'm also using oe_runmake in do_compile().

I expect that I'll be running some version of "make install" at some point. 

I'm sure I'll have more questions as I go along.

Thanks for helping an OE/Yocto N00b!

Paul

Re: Trying to create OpenDDS recipe

[Darren Hart]

Nitin, Khem, some toolchain related (I think) questions inline below.

On 07/28/2011 04:16 PM, Ourada, Paul wrote:
> Hi Darren -
> 
> Thanks for getting back to me. I have been able to get a lot further
> with the recipe. It turns out that the problem is in the makefiles
> for OpenDDS. I'll detail further below.
> 
> Paul E. Ourada Sr. Principal Software Engineer Covidien, Energy-based
> Devices 5920 Longbow Drive Boulder, CO 80301 
> paul.ourada@covidien.com www.covidien.com Main: 303-530-2300 Ofc:
> 303-581-6940 Fax: 303-581-6741
> 
> 
>> Hi Paul,
> 
> On 07/19/2011 07:41 AM, Ourada, Paul wrote:
>>> I hope this is the correct place to post this. If not, please let
>>> me know.
> 
>> This is the right place. In the future please don't reply to an
>> existing post as your message then gets threaded with the one you
>> replied to (likely why you didn't receive a response so far - that
>> I see anyway).
> 
> I guess I thought that changing the subject would have fixed that.
> Guess the mail list s/w is smarter than that. :)

In case you're actually curious :-) it's your mail client. It inserts
the following header:

In-Reply-To: <E7D51FCF-F5DC-448D-8354-410E0217D10F@kernel.crashing.org>

Which a compliant mail reader will thread with that message.

> 
>>> 
>>> I'm trying to create a recipe for OpenDDS. The recipe works so
>>> far as fetching, unpacking, and configuration. Or it seems to. :)
>>> Part of the configuration piece is that it also pulls down
>>> ACE+TAO real-time CORBA. This part works fine as well.
>>> 
>>> I set S as follows to match the unpacking directories enforced by
>>> the tar file:
>>> 
>>> S = ${WORKINGDIR}/DDS
>>> 
>>> The package comes with a configuration script pre-built, and it
>>> expects to be told where glibc is. So, I write do_configure as
>>> follows:
>>> 
>>> EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"
>>> 
>>> do_configure() { ${S}/configure ${EXTRA_OECONF} }
>>> 
>>> The problem that I run into is during compilation. I write the
>>> following for do_compile()
>>> 
>>> do_compile() { oenote ${STAGING_DIR} cd ${S} && make }
> 
>> Is there a reason you are overriding configure and compile? These
>> appear to be autoconf projects, which should just work for recipes
>> using autotools.bbclass.
> 
> I had tried that initially. The configuration file is already
> supplied, so running autotools to create the configure script is not
> necessary, but running ./configure is. Is there a better way to do
> that?

Does regenerating .configure actually cause a problem? If not, I would
still suggest using the autotools base and simplify your recipe.

> 
> : : << most of the compiler command line gobblety-gook snipped>>
> 
>>> -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++ -march=i586
>>> --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"
> 
> 
>>> The thing that is puzzling me is that --sysroot seems to be
>>> pointing in the general direction of ${STAGING_DIR} and so the
>>> include directive, #include <features.h>> should be good. I have
>>> checked, and features.h is in the /usr/include subdirectory
>>> there.
> 
>> I see unistd.h missing, not features.h.
> 
> You're right, it was complaining about unistd.h, but it turns out
> that the real culprit was the TAO_IDL_PREPROCESSOR macro above. When
> I compared it to what was being emitted in the Ubuntu compile, I saw
> that the long, nasty, compound, double-quoted thing should have just
> been "i586-poky-linux-g++." TAO_ID_PREPROCESSOR was being assigned
> the value of ${CXX}.
> 
> It appears that instead of pre-pending the ${CPPFLAGS} variable,
> yocto/poky recipes were appending the cross-compile build variables
> to ${CXX}. I patched the OpenDDS makefile(s) to look for the first
> word in the ${CXX} macro, and substituted that in the assignment of
> TAO_IDL_PREPROCESSOR. Dunno if that's the "right" way to do it, or if
> there's a bug in ${CXX} assignment?

These are good toolchain questions for Nitin or Khem, now on CC.

> 
> Anyway, I think that I'm getting there w/the recipe. I'm sure that
> there are some things I'm doing wrong. For instance, I'm no longer
> cd'ing to ${S}, as OE already takes me there. I'm also using
> oe_runmake in do_compile().

If you're running oe_runmake from do_compile then you might be able to
omit do_compile and use the base class implementation.

> 
> I expect that I'll be running some version of "make install" at some
> point.

Again, should be automagic.

> 
> I'm sure I'll have more questions as I go along.
> 
> Thanks for helping an OE/Yocto N00b!
> 
> Paul
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel