Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =
"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans

On 11/3/10 10:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =
"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

At this point we have no added any e500 support to Poky.

It would certainly be interesting to me to add/enable e500 support, as well as other spe optimizations that eglibc might provide.

--Mark

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

I can definitely guarantee that this would work in
the yocto kernel (with a small local step for you), in
fact, I've got a full BSP for this, and any of the extra
features in the kernel (SPE, IEEE float, lttng, etc) will
all work for any e500* board.

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Cheers,

Bruce

"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

2010/11/3 Bruce Ashfield <bruce.ashfield@...>:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

I can definitely guarantee that this would work in
the yocto kernel (with a small local step for you), in
fact, I've got a full BSP for this, and any of the extra
features in the kernel (SPE, IEEE float, lttng, etc) will
all work for any e500* board.

Sounds good. Is there anything you could share as a starting point?

Frans

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Cheers,

Bruce

"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

On 10-11-03 03:32 PM, Frans Meulenbroeks wrote:

2010/11/3 Bruce Ashfield<bruce.ashfield@...>:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

Hi,

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

I can definitely guarantee that this would work in
the yocto kernel (with a small local step for you), in
fact, I've got a full BSP for this, and any of the extra
features in the kernel (SPE, IEEE float, lttng, etc) will
all work for any e500* board.

Sounds good. Is there anything you could share as a starting point?

There is. And I'll clean it up a bit. The BSP bootstrap
currently has a couple of different steps that are local
to your build (but eventually merge to the kernel tree if
a board is supported) which allow you to work directly in
the kernel git repo for your board work.

In the near future I'll have some updates for BSP
bootstrapping, both code and documents. But I'm more
than happy to walk through this right now if there
is interest.

Cheers,

Bruce

Frans

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Cheers,

Bruce

"calamari"). but gcc-cross-initial fails in do_compile when it tries
to run configure for the libgcc subdir.
The problem is similar to http://patchwork.openembedded.org/patch/2026/

Basically gcc-cross-initial fails building libgcc, config.log has:
cc1: error: not configured for ABI: 'spe'

I feel this is related to the generation of the host triplet.
OE has conf/distro/include/sane-toolchain.inc which has a func
compute_os_portion_of_target_triplet
this one adds gnuspe to the host triplet (and maybe some other things).

poky does not give me that part of the triplet.

Anyone an idea what is wrong (I can provide machine description etc,
but it is also all in the OE git).

Best regards, Frans
_______________________________________________
yocto mailing list
yocto@...
https://lists.pokylinux.org/listinfo/yocto

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Was combo did you see problems with?

I added e500v2 support to OpenEmbedded more than one year ago and have
not seen issues yet in userspace GCC.
Recently been playing with SPE which also ran fine:
http://www.sidebranch.nl/spe-apu

Regards,
--
Leon

On 10-11-04 09:53 AM, Leon Woestenberg wrote:

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Was combo did you see problems with?

It was particular to the mpc8315e config.

I added e500v2 support to OpenEmbedded more than one year ago and have
not seen issues yet in userspace GCC.
Recently been playing with SPE which also ran fine:
http://www.sidebranch.nl/spe-apu

Runtime on the target is fine, since this is all well known
and working (we've had SPE/e500/e500v2 BSPs working for
quite some time), the issue was specific to -Os and gcc 4.5
bootstrap building.

These have all largely been resolved now, and a minor kernel
patch has the powerpc kernel boot code building and working,
and cleanups can happen in our post yocto 0.9 efforts.

Cheers,

Bruce

Regards,

On 11/4/10 8:53 AM, Leon Woestenberg wrote:

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@...> wrote:

On 10-11-03 11:34 AM, Frans Meulenbroeks wrote:

I'm trying to add my powerpc board to yocto (as a test). This board
mpc8536ds has an e500v2 core. It works under OE (MACHINE =

When doing the initial freescale board work, I ran into
similar (same) problems with userspace (and gcc), and
ended up backing off to a more generic optimization level
to get things working. So there are a definitely few things
to do. I was experimenting with FPU settings, but haven't
gone back to look again.

Was combo did you see problems with?

I added e500v2 support to OpenEmbedded more than one year ago and have
not seen issues yet in userspace GCC.
Recently been playing with SPE which also ran fine:
http://www.sidebranch.nl/spe-apu

Regards,

I'm not sure we have all of the pieces in place yet in the toolchain.

My quick looking of my own e500v1 & e500v2 support includes both libc patches and compiler patches.

Just an FYI.. the compiler flags for e500v1:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

and for e500v2:

-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe

Neither of those would be compatible with the existing "ppc" packaging arch. We will need to generate at least one new packaging arch type, likely 2 (one for each). Maybe called ppc_spe or something similar?

The key thing is that each of these cpu's has not only additional SPE instructions, but also additional registers, specific to those instructions, to pass values from function to function. It's not just using the PPC soft-float ABI..

--Mark

Hello Mark,

On Thu, Nov 4, 2010 at 6:20 PM, Mark Hatle <mark.hatle@...> wrote:

On 11/4/10 8:53 AM, Leon Woestenberg wrote:
Just an FYI.. the compiler flags for e500v1:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

and for e500v2:

-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe

Neither of those would be compatible with the existing "ppc" packaging arch.
 We will need to generate at least one new packaging arch type, likely 2
(one for each).  Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

Regards,
--
Leon 'likewise' Woestenberg

On 11/4/10 1:02 PM, Leon Woestenberg wrote:

Hello Mark,

On Thu, Nov 4, 2010 at 6:20 PM, Mark Hatle<mark.hatle@...> wrote:

On 11/4/10 8:53 AM, Leon Woestenberg wrote:
Just an FYI.. the compiler flags for e500v1:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

and for e500v2:

-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe

Neither of those would be compatible with the existing "ppc" packaging arch.
We will need to generate at least one new packaging arch type, likely 2
(one for each). Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

Regards,

I think this is an area we need to coordinate.. I'm not against calling is ppce500v2 for right now. However, I think this is a place we need to coordinate efforts. I'm going to attempt to pull together a list of Linux ABIs & potential optimizations in the Yocto wiki.

The reason I bring this up is that over the years at Wind River, and my previous experience at MontaVista... and watching Emdebian and other projects.. _everyone_ names their package architectures differently.. because people only have a small view on the problem. We finally have enough history to have a chance at indicating what the actual ABIs are, and how the compatibility matrix may fill out. (also giving us a change to finally give these architectures reasonable naming schemes!)

--Mark

Hello Mark,

On Thu, Nov 4, 2010 at 7:18 PM, Mark Hatle <mark.hatle@...> wrote:

On 11/4/10 1:02 PM, Leon Woestenberg wrote:

and for e500v2:
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
Neither of those would be compatible with the existing "ppc" packaging
arch.
 We will need to generate at least one new packaging arch type, likely 2
(one for each).  Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

I think this is an area we need to coordinate.. I'm not against calling is
ppce500v2 for right now.  However, I think this is a place we need to
coordinate efforts.  I'm going to attempt to pull together a list of Linux
ABIs & potential optimizations in the Yocto wiki.

The reason I bring this up is that over the years at Wind River, and my
previous experience at MontaVista... and watching Emdebian and other
projects.. _everyone_ names their package architectures differently..
because people only have a small view on the problem.  We finally have
enough history to have a chance at indicating what the actual ABIs are, and
how the compatibility matrix may fill out.  (also giving us a change to
finally give these architectures reasonable naming schemes!)

I don't see how we could be "final" on this, it seems a returning
topic every few years.

To bring in the OpenEmbedded arch namespace and our optimizations,
from the "master" branch at OpenEmbedded:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/conf/machine/include?h=master

Regards,
--
Leon

On 11/4/10 1:43 PM, Leon Woestenberg wrote:

Hello Mark,

On Thu, Nov 4, 2010 at 7:18 PM, Mark Hatle<mark.hatle@...> wrote:

On 11/4/10 1:02 PM, Leon Woestenberg wrote:

and for e500v2:
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
Neither of those would be compatible with the existing "ppc" packaging
arch.
We will need to generate at least one new packaging arch type, likely 2
(one for each). Maybe called ppc_spe or something similar?

In OpenEmbedded we use the core variant as the packaging name:

TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
-mfloat-gprs=double"
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"

Does that make sense?

I think this is an area we need to coordinate.. I'm not against calling is
ppce500v2 for right now. However, I think this is a place we need to
coordinate efforts. I'm going to attempt to pull together a list of Linux
ABIs& potential optimizations in the Yocto wiki.

The reason I bring this up is that over the years at Wind River, and my
previous experience at MontaVista... and watching Emdebian and other
projects.. _everyone_ names their package architectures differently..
because people only have a small view on the problem. We finally have
enough history to have a chance at indicating what the actual ABIs are, and
how the compatibility matrix may fill out. (also giving us a change to
finally give these architectures reasonable naming schemes!)

I don't see how we could be "final" on this, it seems a returning
topic every few years.

To bring in the OpenEmbedded arch namespace and our optimizations,
from the "master" branch at OpenEmbedded:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/conf/machine/include?h=master

This is a place where I think the Yocto Project can help. We're likely never going to have a final answer.. but what we'll be able to do is give these impromptu ABIs reasonable names so when people talk, everyone can be talking about the same thing..

Then within the Yocto Project's build environment we can promote these namings as part of the implementation...

Open Embedded, and everyone else has legacy associated with their names, which we can try to either coordinate -- or at least help document...

--Mark

Regards,