linux support for freescale e5500 core?

linux support for freescale e5500 core?

[Chris Friesen]

Hi,

We're looking at maybe doing some work with an e5500-based system.  Is
there any support existing/planned for this core?

Also, do we know what the cache line size is--we have some legacy apps
that assume 32-byte.

Thanks,
Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com

Re: linux support for freescale e5500 core?

[Scott Wood]

On Thu, 16 Sep 2010 14:06:37 -0600
Chris Friesen <chris.friesen@genband.com> wrote:

> We're looking at maybe doing some work with an e5500-based system.  Is
> there any support existing/planned for this core?

Check with whoever you'd be getting the hardware from about a BSP.

And yes, it should be supported upstream at some point.

> Also, do we know what the cache line size is--we have some legacy apps
> that assume 32-byte.

The cache line is 64 bytes.  As with e500mc, there is a "dcbz32" mode
for compatibility, though you probably lose much of the performance
benefit of dcbz, and it might upset other software that properly checks
for the cache line size but doesn't use dcbzl.

-Scott

Re: linux support for freescale e5500 core?

[Chris Friesen]

On 09/16/2010 03:39 PM, Scott Wood wrote:
> On Thu, 16 Sep 2010 14:06:37 -0600
> Chris Friesen <chris.friesen@genband.com> wrote:
> 
>> We're looking at maybe doing some work with an e5500-based system.  Is
>> there any support existing/planned for this core?
> 
> Check with whoever you'd be getting the hardware from about a BSP.
> 
> And yes, it should be supported upstream at some point.

We haven't settled on a vendor yet, so I was just wondering in general
what the story was around support.

>> Also, do we know what the cache line size is--we have some legacy apps
>> that assume 32-byte.
> 
> The cache line is 64 bytes.  As with e500mc, there is a "dcbz32" mode
> for compatibility, though you probably lose much of the performance
> benefit of dcbz, and it might upset other software that properly checks
> for the cache line size but doesn't use dcbzl.

Right.  We currently use a 970-series cpu and have implemented a
per-process flag to indicate whether 32-byte mode is needed or not.
We'd have to do something similar with the new cpu.

One last question--can you comment on the speed of an e5500 relative to
a 970 for integer operations?

Thanks,

Chris


-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com

Re: linux support for freescale e5500 core?

[Benjamin Herrenschmidt]

On Thu, 2010-09-16 at 15:44 -0600, Chris Friesen wrote:
> On 09/16/2010 03:39 PM, Scott Wood wrote:
> > On Thu, 16 Sep 2010 14:06:37 -0600
> > Chris Friesen <chris.friesen@genband.com> wrote:
> > 
> >> We're looking at maybe doing some work with an e5500-based system.  Is
> >> there any support existing/planned for this core?
> > 
> > Check with whoever you'd be getting the hardware from about a BSP.
> > 
> > And yes, it should be supported upstream at some point.
> 
> We haven't settled on a vendor yet, so I was just wondering in general
> what the story was around support.

Well, the "core" support for 64-bit BookE is upstream (and has been for
a little while) so +/- specific tweaks FSL may have done and the usual
SoC/board support, it shouldn't be too far off.

> Right.  We currently use a 970-series cpu and have implemented a
> per-process flag to indicate whether 32-byte mode is needed or not.
> We'd have to do something similar with the new cpu.

Sounds like a candidate for upstreaming the patch :-)

> One last question--can you comment on the speed of an e5500 relative to
> a 970 for integer operations?

Cheers,
Ben.

Re: linux support for freescale e5500 core?

[Chris Friesen]

On 09/16/2010 04:03 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-16 at 15:44 -0600, Chris Friesen wrote:

>> Right.  We currently use a 970-series cpu and have implemented a
>> per-process flag to indicate whether 32-byte mode is needed or not.
>> We'd have to do something similar with the new cpu.
> 
> Sounds like a candidate for upstreaming the patch :-)

As I recall we proposed upstreaming it a while back but there wasn't a
lot of interest since it's most useful in supporting poorly-written
legacy apps. :)

Chris



-- 
The author works for GENBAND Corporation (GENBAND) who is solely
responsible for this email and its contents. All enquiries regarding
this email should be addressed to GENBAND. Nortel has provided the use
of the nortel.com domain to GENBAND in connection with this email solely
for the purpose of connectivity and Nortel Networks Inc. has no
liability for the email or its contents. GENBAND's web site is
http://www.genband.com

Re: linux support for freescale e5500 core?

[Benjamin Herrenschmidt]

On Thu, 2010-09-16 at 16:26 -0600, Chris Friesen wrote:
> > Sounds like a candidate for upstreaming the patch :-)
> 
> As I recall we proposed upstreaming it a while back but there wasn't a
> lot of interest since it's most useful in supporting poorly-written
> legacy apps. :) 

Heh. Well as long as only 970 had that bit ... but with e5500 coming up
with that too, I suppose it makes -some- sense. Let's at least look at
the approach you took and we can decide based on how invasive/ugly it
is :-)

Cheers,
Ben.

Re: linux support for freescale e5500 core?

[Kumar Gala]

On Sep 16, 2010, at 7:03 PM, Benjamin Herrenschmidt wrote:

> On Thu, 2010-09-16 at 16:26 -0600, Chris Friesen wrote:
>>> Sounds like a candidate for upstreaming the patch :-)
>>=20
>> As I recall we proposed upstreaming it a while back but there wasn't =
a
>> lot of interest since it's most useful in supporting poorly-written
>> legacy apps. :)=20
>=20
> Heh. Well as long as only 970 had that bit ... but with e5500 coming =
up
> with that too, I suppose it makes -some- sense. Let's at least look at
> the approach you took and we can decide based on how invasive/ugly it
> is :-)

Not sure how the 970 bit worked, but this seems a bit problematic for =
switching between kernel and application for how we do this on =
e500mc/e5500.  We'd have to touch the control bit on every exception =
path which seems ugly to me.

- k=

Re: linux support for freescale e5500 core?

[Benjamin Herrenschmidt]

On Fri, 2010-09-17 at 00:17 -0500, Kumar Gala wrote:
> Not sure how the 970 bit worked, but this seems a bit problematic for
> switching between kernel and application for how we do this on
> e500mc/e5500.  We'd have to touch the control bit on every exception
> path which seems ugly to me.

Unless the kernel uses dcbzl (feature fixup replacement ?)

In that case it's on context switch only.

Cheers,
Ben.

Re: linux support for freescale e5500 core?

[Chris Friesen]

On 09/16/2010 11:33 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-09-17 at 00:17 -0500, Kumar Gala wrote:
>> Not sure how the 970 bit worked, but this seems a bit problematic for
>> switching between kernel and application for how we do this on
>> e500mc/e5500.  We'd have to touch the control bit on every exception
>> path which seems ugly to me.
> 
> Unless the kernel uses dcbzl (feature fixup replacement ?)
> 
> In that case it's on context switch only.

This is basically what we did.  Kernel and system libraries (glibc and
friends) always use dcbzl, process flag indicates compatibility, touch
the control bit on task context switch if the prev and next processes
have different compatibility modes.

On the 970 you have to invalidate the entire icache whenever you change
the control bit.  This is a pain involving a loop that calls icbi on 512
cachelines.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com

Re: linux support for freescale e5500 core?

[Kumar Gala]

On Sep 17, 2010, at 1:36 AM, Chris Friesen wrote:

> On 09/16/2010 11:33 PM, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-09-17 at 00:17 -0500, Kumar Gala wrote:
>>> Not sure how the 970 bit worked, but this seems a bit problematic =
for
>>> switching between kernel and application for how we do this on
>>> e500mc/e5500.  We'd have to touch the control bit on every exception
>>> path which seems ugly to me.
>>=20
>> Unless the kernel uses dcbzl (feature fixup replacement ?)
>>=20
>> In that case it's on context switch only.
>=20
> This is basically what we did.  Kernel and system libraries (glibc and
> friends) always use dcbzl, process flag indicates compatibility, touch
> the control bit on task context switch if the prev and next processes
> have different compatibility modes.
>=20
> On the 970 you have to invalidate the entire icache whenever you =
change
> the control bit.  This is a pain involving a loop that calls icbi on =
512
> cachelines.

I'm pretty sure on e500mc / e5500 you only need proper sync/isync/msync =
after the change in the control register.

- k=