toolchain queries

toolchain queries

[Kumar Gala]

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc 
* e5500 (64-bit embedded ppc)
* e5500 - multilib support for 32/64-bit

- k

Re: toolchain queries

[NiQingliang]

may be meta/conf/machine/include.

On Fri, 2011-07-15 at 10:36 +0800, Kumar Gala wrote:
> Where is the best place to ask questions and try and get support for adding some toolchain variations in?
> 
> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
> 
> * e500v2 (gcc needs --enable-e500_double, eglibc
> * e5500 (64-bit embedded ppc)
> * e5500 - multilib support for 32/64-bit
> 
> - k
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: toolchain queries

[Bruce Ashfield]

On 11-07-14 10:36 PM, Kumar Gala wrote:
> Where is the best place to ask questions and try and get support for adding some toolchain variations in?

Here can work, or the oe-core lists.

>
> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
>
> * e500v2 (gcc needs --enable-e500_double, eglibc
> * e5500 (64-bit embedded ppc)

There are oe and oe-dev references for at least the e500v2
(that's what I've been working on importing .. slowly), and
I haven't looked for others yet. So that's a good place to
look for real world examples.

Once I get a few kernel-3.0 issues sorted out, I'll be back
to this and could definitely collaborate on these items.

Cheers,

Bruce

> * e5500 - multilib support for 32/64-bit
>
> - k
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: toolchain queries

[Kumar Gala]

On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote:

> Where is the best place to ask questions and try and get support for adding some toolchain variations in?
> 
> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
> 
> * e500v2 (gcc needs --enable-e500_double, eglibc 
> * e5500 (64-bit embedded ppc)
> * e5500 - multilib support for 32/64-bit
> 

The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu.

Wondering who is the expect on these recipes to discuss such issues with.

- k

Re: toolchain queries

[Richard Purdie]

On Fri, 2011-07-15 at 08:33 -0500, Kumar Gala wrote:
> On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote:
> 
> > Where is the best place to ask questions and try and get support for adding some toolchain variations in?
> > 
> > I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
> > 
> > * e500v2 (gcc needs --enable-e500_double, eglibc 
> > * e5500 (64-bit embedded ppc)
> > * e5500 - multilib support for 32/64-bit
> > 
> 
> The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu.
> 
> Wondering who is the expect on these recipes to discuss such issues with.

The tune files (conf/machine/include/tune*) usually set the march and
mcpu options which are added to CFLAGS. Does that provide the
functionality you're looking for?

Cheers,

Richard

Re: toolchain queries

[Kumar Gala]

On Jul 15, 2011, at 8:37 AM, Richard Purdie wrote:

> On Fri, 2011-07-15 at 08:33 -0500, Kumar Gala wrote:
>> On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote:
>> 
>>> Where is the best place to ask questions and try and get support for adding some toolchain variations in?
>>> 
>>> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
>>> 
>>> * e500v2 (gcc needs --enable-e500_double, eglibc 
>>> * e5500 (64-bit embedded ppc)
>>> * e5500 - multilib support for 32/64-bit
>>> 
>> 
>> The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu.
>> 
>> Wondering who is the expect on these recipes to discuss such issues with.
> 
> The tune files (conf/machine/include/tune*) usually set the march and
> mcpu options which are added to CFLAGS. Does that provide the
> functionality you're looking for?
> 

No, I'm dealing with different configure issues for gcc, eglibc for these targets:

PPC e500v2
PPC e5500 (64-bit, multilib)

- k

Re: toolchain queries

[Khem Raj]

On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Where is the best place to ask questions and try and get support for adding some toolchain variations in?
>
> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
>
> * e500v2 (gcc needs --enable-e500_double, eglibc

this means ABI change especially due to double formats. This should be
doable in machine.conf
files or tune files.

> * e5500 (64-bit embedded ppc)

this is new I guess. Its like adding a new arch to OE. See around
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html
is roughly what can be helpful in getting ppc64 going

> * e5500 - multilib support for 32/64-bit

there is some thought and work RP has been doing on multilib.

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

Re: toolchain queries

[Kumar Gala]

On Jul 15, 2011, at 2:28 PM, Khem Raj wrote:

> On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>> Where is the best place to ask questions and try and get support for adding some toolchain variations in?
>> 
>> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
>> 
>> * e500v2 (gcc needs --enable-e500_double, eglibc
> 
> this means ABI change especially due to double formats. This should be
> doable in machine.conf
> files or tune files.

how so?  What can I set in there that would actually get passed into gcc's configure (not really seeing anything).  Also what exactly do you mean by a machine.conf

>> * e5500 (64-bit embedded ppc)
> 
> this is new I guess. Its like adding a new arch to OE. See around
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html
> is roughly what can be helpful in getting ppc64 going

Thanks, will take a look at that.

- k

Re: toolchain queries

[Khem Raj]

On Fri, Jul 15, 2011 at 2:13 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 15, 2011, at 2:28 PM, Khem Raj wrote:
>
>> On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> Where is the best place to ask questions and try and get support for adding some toolchain variations in?
>>>
>>> I'm wanting to add support in for a few different flavors of PPC that are not currently supported:
>>>
>>> * e500v2 (gcc needs --enable-e500_double, eglibc
>>
>> this means ABI change especially due to double formats. This should be
>> doable in machine.conf
>> files or tune files.
>
> how so?  What can I set in there that would actually get passed into gcc's configure (not really seeing anything).  Also what exactly do you mean by a machine.conf

Well as I see not so easily which is since we share toolchain for
architectures and if
we let machines add ABI conflicting options then we will be in trouble
think of using
I could have suggested using something like GLIBC_EXTRA_OECONF but I
would not encourage that

So one way to go about this is that we use -gnuspe in target triplet
which will differentiate
SPE targets from classic ppc and then in gcc recipe include files

you can do something like

EXTRA_OECONF_append_linux-gnuspe = " --enable-e500_double "

>
>>> * e5500 (64-bit embedded ppc)
>>
>> this is new I guess. Its like adding a new arch to OE. See around
>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html
>> is roughly what can be helpful in getting ppc64 going
>
> Thanks, will take a look at that.
>
> - k