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 -- Chris Friesen Software Developer GENBAND chris.frie...@genband.com www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On Thu, 16 Sep 2010 14:06:37 -0600 Chris Friesen 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
On 09/16/2010 03:39 PM, Scott Wood wrote: > On Thu, 16 Sep 2010 14:06:37 -0600 > Chris Friesen 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.frie...@genband.com www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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 :-) >> >> 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 :-) 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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.frie...@genband.com www.genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux support for freescale e5500 core?
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. >> >> 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. I'm pretty sure on e500mc / e5500 you only need proper sync/isync/msync after the change in the control register. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
