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

- k

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

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

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

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

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

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

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