ppc e500v2 support?

ppc e500v2 support?

[Frans Meulenbroeks]

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

Re: ppc e500v2 support?

[Mark Hatle]

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@yoctoproject.org
> https://lists.pokylinux.org/listinfo/yocto

Re: ppc e500v2 support?

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

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@yoctoproject.org
> https://lists.pokylinux.org/listinfo/yocto

Re: ppc e500v2 support?

[Frans Meulenbroeks]

2010/11/3 Bruce Ashfield <bruce.ashfield@windriver.com>:
> 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@yoctoproject.org
>> https://lists.pokylinux.org/listinfo/yocto
>
>

Re: ppc e500v2 support?

[Bruce Ashfield]

On 10-11-03 03:32 PM, Frans Meulenbroeks wrote:
> 2010/11/3 Bruce Ashfield<bruce.ashfield@windriver.com>:
>> 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@yoctoproject.org
>>> https://lists.pokylinux.org/listinfo/yocto
>>
>>

Re: ppc e500v2 support?

[Leon Woestenberg]

Hello Bruce,

On Wed, Nov 3, 2010 at 4:49 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> 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

Re: ppc e500v2 support?

[Bruce Ashfield]

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@windriver.com>  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,

Re: ppc e500v2 support?

[Mark Hatle]

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

Re: ppc e500v2 support?

[Leon Woestenberg]

Hello Mark,

On Thu, Nov 4, 2010 at 6:20 PM, Mark Hatle <mark.hatle@windriver.com> 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

Re: ppc e500v2 support?

[Mark Hatle]

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

Re: ppc e500v2 support?

[Leon Woestenberg]

Hello Mark,

On Thu, Nov 4, 2010 at 7:18 PM, Mark Hatle <mark.hatle@windriver.com> 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

Re: ppc e500v2 support?

[Mark Hatle]

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@windriver.com>  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,