linux support for freescale e5500 core?
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
Signature · 5 lines
Chris Friesen Software Developer GENBAND [email protected] www.genband.com
Quoted 2 lines · On Thu, 16 Sep 2010 14:06:37 -0600 Chris Friesen <[email protected]>…
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.
Quoted 2 lines
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
Quoted 9 lines · Scott Wood
Quoted 2 lines · On Thu, 16 Sep 2010 14:06:37 -0600 Chris Friesen <[email protected]>…
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.
Quoted 7 lines
Quoted 2 lines
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
Signature · 5 lines
Chris Friesen Software Developer GENBAND [email protected] www.genband.com
Quoted 7 lines · Chris Friesen
Quoted 6 lines · Scott Wood
Quoted 2 lines · On Thu, 16 Sep 2010 14:06:37 -0600 Chris Friesen <[email protected]>…
We're looking at maybe doing some work with an e5500-based system. Is there any support existing/planned for this core?
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
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 :-)
Quoted 2 lines
One last question--can you comment on the speed of an e5500 relative to a 970 for integer operations?
Cheers,
Ben.
Quoted 7 lines · Benjamin Herrenschmidt
Quoted 3 lines · Chris Friesen
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
Signature · 7 lines
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
Quoted 5 lines · Chris Friesen
Quoted 1 line
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.
Quoted 4 lines · Benjamin Herrenschmidt
Quoted 3 lines · Chris Friesen
Quoted 1 line
Sounds like a candidate for upstreaming the patch :-)
=20
As I recall we proposed upstreaming it a while back but there wasn't =
a
Quoted 4 lines
Quoted 2 lines
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
Quoted 3 lines
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=
Quoted 4 lines · Kumar Gala
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.
Quoted 9 lines · Benjamin Herrenschmidt
Quoted 4 lines · Kumar Gala
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
Signature · 5 lines
Chris Friesen Software Developer GENBAND [email protected] www.genband.com
Quoted 3 lines · Chris Friesen
Quoted 2 lines · Benjamin Herrenschmidt
Quoted 1 line · Kumar Gala
Not sure how the 970 bit worked, but this seems a bit problematic =
for
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
=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
Quoted 1 line
the control bit. This is a pain involving a loop that calls icbi on =
512
Quoted 1 line
cachelines.
I'm pretty sure on e500mc / e5500 you only need proper sync/isync/msync = after the change in the control register.
- k=