Hi all,

I am new to Yocto and to Distro work in general.

I want to use Yocto on the Kontron nanoETXexpressTT boards.
(http://de.kontron.com/products/computeronmodules/com+express/com+express+ultra/nanoetxexpresstt.html)

These boards are based on the Intel Atom E6xx and the EG20T platform
controller hub, so i think it is a good idea to start with the crownbay
BSP.

What would be the best, known to work, way to produce crownbay-noemgd images
for poky bernard?
Should i use git? Which branches should i use (the docs are contraditing
at least in parts)?

I read somewhere, that i should install Yocto to /usr/local/src/yocto.
Is this really necessary?

Thanks for any hints.

regards,

Andre

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

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

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> 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@...>
---
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

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

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> 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@...>
---
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

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

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:

Signed-off-by: Kumar Gala <galak@...>
---
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

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

diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
new file mode 100644
index 0000000..763ec1a
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -0,0 +1,4 @@
+TARGET_CC_ARCH = "-mcpu=e500mc"
+BASE_PACKAGE_ARCH = "ppce500mc"
+FEED_ARCH = "ppce500mc"
+PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
--
1.7.3.4

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> 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@...>
---
 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@...
https://lists.yoctoproject.org/listinfo/yocto

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> 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@...>
---
 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@...
https://lists.yoctoproject.org/listinfo/yocto

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:

Signed-off-by: Kumar Gala <galak@...>
---
 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@...
https://lists.yoctoproject.org/listinfo/yocto

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> 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@... as well

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

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@...>
---
.../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@...>
+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@...>
+---
+ 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

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@...>
---
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

Signed-off-by: Kumar Gala <galak@...>
---
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

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@...>
---
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

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@...>
---
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

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

All - I really don't like the direction this is trending. I don't think we have too much new development left in this cycle, but if you have bugs assigned can you please put additional effort into resolving these? Thanks...

Dave

On Mon, Jul 18, 2011 at 1:04 PM, Kumar Gala <galak@...> wrote:

On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala <galak@...> wrote:

On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala <galak@...> wrote:

You can try -fno-use-linker-plugin as a workaround. Does
liblto_plugin.so exist on target rfs ?
it might be then gcc driver bug if the library is not there then we
forgot to package it.

File appears to be there:
root@p2020-ds:/# file /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0
./usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70402, stripped

root@p2020-ds:~# ls -lstr /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/
total 31624
 9812 -rwxr-xr-x 1 root root 10046304 Jul 16 22:40 lto1
   28 -rwxr-xr-x 1 root root    26344 Jul 16 22:40 lto-wrapper
   60 -rwxr-xr-x 1 root root    60132 Jul 16 22:40 liblto_plugin.so.0.0.0
  124 -rwxr-xr-x 1 root root   124776 Jul 16 22:40 collect2
11208 -rwxr-xr-x 1 root root 11476244 Jul 16 22:40 cc1plus
10392 -rwxr-xr-x 1 root root 10640644 Jul 16 22:40 cc1
    0 lrwxrwxrwx 1 root root       22 Jul 17 15:07 liblto_plugin.so.0 ->  liblto_plugin.so.0.0.0

So not clear why its not finding it.

This looks similar to Yocto Bug 1233 (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1233

Can you confirm if you have the following commit in your branch?
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2429773613cb95b6a0541b5cce6ce1338d5cfc2b

It's possible you might be missing this and it's not finding the file correctly.

As Richard mentioned also, an strace output would be helpful if you do have the above commit.

Thanks
      Sau!

access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/../../../../powerpc-poky-linux-gnuspe/bin/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/../../../../powerpc-poky-linux-gnuspe/bin/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)

So it appears we are missing in the package 'liblto_plugin.so' link.

Does that symlink exist in your gcc install tree during build ? if not
then gcc makefiles need to generate it. if its just a case we
forgot to bundle it then we should add it to FILES var of gcc.

How do I tell?  Which gcc dir should I be looking at under build/tmp/work/* ?

For the MPC8315E-RDB build:

http://pastebin.com/yYSww5nK

[ the first three lines look interesting about packages-split/gcc-dev vs packages-split/gcc ]

For the e500v2 (P2020-DS) build:

http://pastebin.com/B1qyfbGE

- k

hmm the symlink goes into gcc-dev package since the package splitter
sees a sumlink xyz.so
but in this case this should be packages explicitly into gcc as we see
gcc depends on it for normal
execution or may be create a new package called liblto or somesuch

Can you install gcc-dev package on your device and see if this helps ?

Yes if I install gcc-dev it works.

OK thanks. So I think we just need to package this symlink along with gcc
and all is good.

Agreed, do you mind working up such a patch.  I'm not an expert in this area so feel a little concerned about not knowing enough to try and do this cleanly (or generically).

yes I will but may be a day or two

- k

On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala <galak@...> wrote:

On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala <galak@...> wrote:

You can try -fno-use-linker-plugin as a workaround. Does
liblto_plugin.so exist on target rfs ?
it might be then gcc driver bug if the library is not there then we
forgot to package it.

File appears to be there:
root@p2020-ds:/# file /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0
./usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70402, stripped

root@p2020-ds:~# ls -lstr /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/
total 31624
9812 -rwxr-xr-x 1 root root 10046304 Jul 16 22:40 lto1
28 -rwxr-xr-x 1 root root 26344 Jul 16 22:40 lto-wrapper
60 -rwxr-xr-x 1 root root 60132 Jul 16 22:40 liblto_plugin.so.0.0.0
124 -rwxr-xr-x 1 root root 124776 Jul 16 22:40 collect2
11208 -rwxr-xr-x 1 root root 11476244 Jul 16 22:40 cc1plus
10392 -rwxr-xr-x 1 root root 10640644 Jul 16 22:40 cc1
0 lrwxrwxrwx 1 root root 22 Jul 17 15:07 liblto_plugin.so.0 -> liblto_plugin.so.0.0.0

So not clear why its not finding it.

This looks similar to Yocto Bug 1233 (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1233

Can you confirm if you have the following commit in your branch?
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2429773613cb95b6a0541b5cce6ce1338d5cfc2b

It's possible you might be missing this and it's not finding the file correctly.

As Richard mentioned also, an strace output would be helpful if you do have the above commit.

Thanks
Sau!

access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/../../../../powerpc-poky-linux-gnuspe/bin/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/../../../../powerpc-poky-linux-gnuspe/bin/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)

So it appears we are missing in the package 'liblto_plugin.so' link.

Does that symlink exist in your gcc install tree during build ? if not
then gcc makefiles need to generate it. if its just a case we
forgot to bundle it then we should add it to FILES var of gcc.

How do I tell? Which gcc dir should I be looking at under build/tmp/work/* ?

For the MPC8315E-RDB build:

http://pastebin.com/yYSww5nK

[ the first three lines look interesting about packages-split/gcc-dev vs packages-split/gcc ]

For the e500v2 (P2020-DS) build:

http://pastebin.com/B1qyfbGE

- k

hmm the symlink goes into gcc-dev package since the package splitter
sees a sumlink xyz.so
but in this case this should be packages explicitly into gcc as we see
gcc depends on it for normal
execution or may be create a new package called liblto or somesuch

Can you install gcc-dev package on your device and see if this helps ?

Yes if I install gcc-dev it works.

OK thanks. So I think we just need to package this symlink along with gcc
and all is good.

Agreed, do you mind working up such a patch. I'm not an expert in this area so feel a little concerned about not knowing enough to try and do this cleanly (or generically).

- k