TARGET_FPU for mpc8315e-rdb listed as SPE??

TARGET_FPU for mpc8315e-rdb listed as SPE??

[Kumar Gala]

Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as SPE.  This isn't correct for an MPC8313 SoC.

- k

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Richard Purdie]

On Wed, 2010-11-10 at 00:46 -0600, Kumar Gala wrote:
> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
> SPE.  This isn't correct for an MPC8313 SoC.

I'm not familiar with that machine, please could you file a bug, maybe
with a patch showing what the correct values should be?

Cheers,

Richard

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Bruce Ashfield]

On 10-11-10 01:46 AM, Kumar Gala wrote:
> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as SPE.  This isn't correct for an MPC8313 SoC.

It isn't used at the moment, so we can safely
ignore this.

It was a hold over from when I initially created
the BSP, and I've since changed it locally, but
haven't sent the updated BSP yet.

Cheers,

Bruce

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

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Bruce Ashfield]

On 10-11-10 08:38 AM, Bruce Ashfield wrote:
> On 10-11-10 01:46 AM, Kumar Gala wrote:
>> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
>> SPE. This isn't correct for an MPC8313 SoC.
>
> It isn't used at the moment, so we can safely
> ignore this.
>
> It was a hold over from when I initially created
> the BSP, and I've since changed it locally, but
> haven't sent the updated BSP yet.

To clarify on this point, the kernel configuration
is NOT using SPE for this, and I was attempting to
use the FPU setting to trigger some different gcc
flags during development the base of that test was
an e500 board, so the SPE setting leaked in, but is
unused.

At the moment, it is actually using soft-float, and
I had planned to submit a change to clarify that.

If there's another option, let me know and I'll
rebase my patches and change it again.

Cheers,

Bruce

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

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Kumar Gala]

On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:

> On 10-11-10 08:38 AM, Bruce Ashfield wrote:
>> On 10-11-10 01:46 AM, Kumar Gala wrote:
>>> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
>>> SPE. This isn't correct for an MPC8313 SoC.
>> 
>> It isn't used at the moment, so we can safely
>> ignore this.
>> 
>> It was a hold over from when I initially created
>> the BSP, and I've since changed it locally, but
>> haven't sent the updated BSP yet.
> 
> To clarify on this point, the kernel configuration
> is NOT using SPE for this, and I was attempting to
> use the FPU setting to trigger some different gcc
> flags during development the base of that test was
> an e500 board, so the SPE setting leaked in, but is
> unused.
> 
> At the moment, it is actually using soft-float, and
> I had planned to submit a change to clarify that.
> 
> If there's another option, let me know and I'll
> rebase my patches and change it again.

We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).

Any plans to get an e500 based system going before the rev1.0 release?

- k

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Bruce Ashfield]

On 10-11-10 09:11 AM, Kumar Gala wrote:
>
> On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:
>
>> On 10-11-10 08:38 AM, Bruce Ashfield wrote:
>>> On 10-11-10 01:46 AM, Kumar Gala wrote:
>>>> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
>>>> SPE. This isn't correct for an MPC8313 SoC.
>>>
>>> It isn't used at the moment, so we can safely
>>> ignore this.
>>>
>>> It was a hold over from when I initially created
>>> the BSP, and I've since changed it locally, but
>>> haven't sent the updated BSP yet.
>>
>> To clarify on this point, the kernel configuration
>> is NOT using SPE for this, and I was attempting to
>> use the FPU setting to trigger some different gcc
>> flags during development the base of that test was
>> an e500 board, so the SPE setting leaked in, but is
>> unused.
>>
>> At the moment, it is actually using soft-float, and
>> I had planned to submit a change to clarify that.
>>
>> If there's another option, let me know and I'll
>> rebase my patches and change it again.
>
> We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).

Indeed. I fell back to a safe multilib. I'm willing
to try again and see if the gcc bootstrap phases will
build.

The kernel was fine, and is fine, it was userspace
that caused problems for me .. and that's definitely not
an area where my expertise lies :)

I needed something that worked, and had to excplicitly
chose to ignore the FPU temporarily, but revisiting that
now seems like a good idea.

>
> Any plans to get an e500 based system going before the rev1.0 release?

We've got tonnes of experience and BSPs to draw from
here. The selection of some of these BSPs was (largely)
based on cost and availability. If we can get our
hands on a suitable e500 replacement .. the switch is
trivial.

Cheers,

Bruce

>
> - k

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Kumar Gala]

On Nov 10, 2010, at 8:23 AM, Bruce Ashfield wrote:

> On 10-11-10 09:11 AM, Kumar Gala wrote:
>> 
>> On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:
>> 
>>> On 10-11-10 08:38 AM, Bruce Ashfield wrote:
>>>> On 10-11-10 01:46 AM, Kumar Gala wrote:
>>>>> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
>>>>> SPE. This isn't correct for an MPC8313 SoC.
>>>> 
>>>> It isn't used at the moment, so we can safely
>>>> ignore this.
>>>> 
>>>> It was a hold over from when I initially created
>>>> the BSP, and I've since changed it locally, but
>>>> haven't sent the updated BSP yet.
>>> 
>>> To clarify on this point, the kernel configuration
>>> is NOT using SPE for this, and I was attempting to
>>> use the FPU setting to trigger some different gcc
>>> flags during development the base of that test was
>>> an e500 board, so the SPE setting leaked in, but is
>>> unused.
>>> 
>>> At the moment, it is actually using soft-float, and
>>> I had planned to submit a change to clarify that.
>>> 
>>> If there's another option, let me know and I'll
>>> rebase my patches and change it again.
>> 
>> We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).
> 
> Indeed. I fell back to a safe multilib. I'm willing
> to try again and see if the gcc bootstrap phases will
> build.
> 
> The kernel was fine, and is fine, it was userspace
> that caused problems for me .. and that's definitely not
> an area where my expertise lies :)
> 
> I needed something that worked, and had to excplicitly
> chose to ignore the FPU temporarily, but revisiting that
> now seems like a good idea.
> 
>> 
>> Any plans to get an e500 based system going before the rev1.0 release?
> 
> We've got tonnes of experience and BSPs to draw from
> here. The selection of some of these BSPs was (largely)
> based on cost and availability. If we can get our
> hands on a suitable e500 replacement .. the switch is
> trivial.

If we can get a toolchain and basic build I'm happy to help on the HW side and getting kernel, etc worked out.

I'd like to get a semi-generic setup going for an e500v2 based system.

- k

Re: TARGET_FPU for mpc8315e-rdb listed as SPE??

[Bruce Ashfield]

On 10-11-10 10:03 AM, Kumar Gala wrote:
>
> On Nov 10, 2010, at 8:23 AM, Bruce Ashfield wrote:
>
>> On 10-11-10 09:11 AM, Kumar Gala wrote:
>>>
>>> On Nov 10, 2010, at 7:58 AM, Bruce Ashfield wrote:
>>>
>>>> On 10-11-10 08:38 AM, Bruce Ashfield wrote:
>>>>> On 10-11-10 01:46 AM, Kumar Gala wrote:
>>>>>> Why does the meta/conf/machine/mpc8315e-rdb.conf list TARGET_FPU as
>>>>>> SPE. This isn't correct for an MPC8313 SoC.
>>>>>
>>>>> It isn't used at the moment, so we can safely
>>>>> ignore this.
>>>>>
>>>>> It was a hold over from when I initially created
>>>>> the BSP, and I've since changed it locally, but
>>>>> haven't sent the updated BSP yet.
>>>>
>>>> To clarify on this point, the kernel configuration
>>>> is NOT using SPE for this, and I was attempting to
>>>> use the FPU setting to trigger some different gcc
>>>> flags during development the base of that test was
>>>> an e500 board, so the SPE setting leaked in, but is
>>>> unused.
>>>>
>>>> At the moment, it is actually using soft-float, and
>>>> I had planned to submit a change to clarify that.
>>>>
>>>> If there's another option, let me know and I'll
>>>> rebase my patches and change it again.
>>>
>>> We should NOT be using soft-float for mpc8315e (it has HW floating point on this chip).
>>
>> Indeed. I fell back to a safe multilib. I'm willing
>> to try again and see if the gcc bootstrap phases will
>> build.
>>
>> The kernel was fine, and is fine, it was userspace
>> that caused problems for me .. and that's definitely not
>> an area where my expertise lies :)
>>
>> I needed something that worked, and had to excplicitly
>> chose to ignore the FPU temporarily, but revisiting that
>> now seems like a good idea.
>>
>>>
>>> Any plans to get an e500 based system going before the rev1.0 release?
>>
>> We've got tonnes of experience and BSPs to draw from
>> here. The selection of some of these BSPs was (largely)
>> based on cost and availability. If we can get our
>> hands on a suitable e500 replacement .. the switch is
>> trivial.
>
> If we can get a toolchain and basic build I'm happy to help on the HW side and getting kernel, etc worked out.

Agreed. For me, this is the slightly harder part. I'll
start a few builds and see if the errors are still here.

>
> I'd like to get a semi-generic setup going for an e500v2 based system.

Should be doable. I've already got a generic set of configs/
patches/features in place for all powerpc/FSL boards,
(largely due to the lineage of the base kernel we use).
But getting some assistance with  further tuning of the
options would be appreciated, since I can use that to springboard
the creation of new BSPs.

Cheers,

Bruce



>
> - k