PPC Cache Flush and Invalidate Routines

PPC Cache Flush and Invalidate Routines

[Grant Erickson]

In trying to accomodate the 4xx-based code into the Linux kernel, I've
encountered an issue which relates to the cache flushing and invalidation
routines in misc.S.

Among the 4xx-based processors, the 403s have 16 byte cache lines and the
405s have 32 byte cache lines. Among the 8xx processors, all appear to
have 16 byte cache lines. All the rest seem to have 32 byte cache lines.

There are several solutions here:

 - Use ifdef's as is done at present.

 - Check the PVR on entry to each of these routines and "do the right
   thing".

 - Set global variables ppc_cache_linesize and ppc_cache_lineshift
   somewhere in MMU_init or setup_arch which then get loaded in the cache
   routines.

The first option keeps the code small and fast, but doesn't easily cover
the dichotomy between the line sizes in 403 and 405 with a simple
CONFIG_4xx.

The second option incurs a lot of unnecessary overhead per invocation of
the routines and adds a lot of special-case code to each routine.

The final option seems the best compromise, increasing kernel memory usage
by 8 bytes and adding a little code to load the values of
ppc_cache_line{size,shift}. All the overhead is then left to a one time
invocation in MMU_init or setup_arch.

Thoughts, opinions?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

RE: PPC Cache Flush and Invalidate Routines

[Gary Thomas]

On 08-Dec-99 Grant Erickson wrote:
> 
> In trying to accomodate the 4xx-based code into the Linux kernel, I've
> encountered an issue which relates to the cache flushing and invalidation
> routines in misc.S.
> 
> Among the 4xx-based processors, the 403s have 16 byte cache lines and the
> 405s have 32 byte cache lines. Among the 8xx processors, all appear to
> have 16 byte cache lines. All the rest seem to have 32 byte cache lines.
> 
> There are several solutions here:
> 
>  - Use ifdef's as is done at present.
> 
>  - Check the PVR on entry to each of these routines and "do the right
>    thing".
> 
>  - Set global variables ppc_cache_linesize and ppc_cache_lineshift
>    somewhere in MMU_init or setup_arch which then get loaded in the cache
>    routines.
> 
> The first option keeps the code small and fast, but doesn't easily cover
> the dichotomy between the line sizes in 403 and 405 with a simple
> CONFIG_4xx.
> 
> The second option incurs a lot of unnecessary overhead per invocation of
> the routines and adds a lot of special-case code to each routine.
> 
> The final option seems the best compromise, increasing kernel memory usage
> by 8 bytes and adding a little code to load the values of
> ppc_cache_line{size,shift}. All the overhead is then left to a one time
> invocation in MMU_init or setup_arch.
> 
> Thoughts, opinions?
> 

Perhaps calling these routines via a vector whose value is computed at
boot/setup time that DTRT (does the right thing).  This would keep the
overhead down to a single load and still provide the desired functionality.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Cache Flush and Invalidate Routines

[Grant Erickson]

On Wed, 8 Dec 1999, Dan Malek wrote:
> Grant Erickson wrote:
> > In trying to accomodate the 4xx-based code into the Linux kernel, I've
> > encountered an issue which relates to the cache flushing and invalidation
> > routines in misc.S.
> >
> > Thoughts, opinions?
> 
> We could simply create a configuration #define for the cache line size
> that is assigned in the 'make config' scripts when the processor type
> is chosen.

In general, I like that idea; however, the 4xx messes things up.

I'd like to have a kernel that will boot on any 4xx-based board (maybe or
maybe not realistic), so because the 403 uses 16 byte lines and the 405
uses 32 byte lines, I need a dynamic solution such as the one Gary
suggested.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Cache Flush and Invalidate Routines

[Dan Malek]

Grant Erickson wrote:


> I'd like to have a kernel that will boot on any 4xx-based board (maybe or
> maybe not realistic), so because the 403 uses 16 byte lines and the 405
> uses 32 byte lines, I need a dynamic solution such as the one Gary
> suggested.

So, let's just make them kernel variables and load them.  What's
a few extra cycles here and there :-).  You just end up moving
the #defines to one of the kernel setup files......

Another alternative that requires some investigation would be
using the 16 byte line size on the 405.  My concern is there may
be alignment restrictions, but if it works all it costs you is
an extra (and ignored) cache instruction.  If this would work
on all processors (and my puke green book indicates it should),
it would be a nice modification to the C library.  Those big-assed
processors won't care if they execute a few more instructions, and
the little kids will work with caches enabled.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Cache Flush and Invalidate Routines

[Daniel L. Taylor]

Although we're investigating linuxPPC by working on an MTX
(not quite all ready, yet) which can have either '603s or
'604s, our ultimate target devices are still being selected.
In the interest of longterm embedded solutions, I like
Mr. Thomas' idea of the common entry with "TRT" determined
at system setup, rather than runtime.

Gary Thomas wrote:
> 
> On 08-Dec-99 Grant Erickson wrote:
> >
> > In trying to accomodate the 4xx-based code into the Linux kernel, I've
> > encountered an issue which relates to the cache flushing and invalidation
> > routines in misc.S.
> >
> > Among the 4xx-based processors, the 403s have 16 byte cache lines and the
> > 405s have 32 byte cache lines. Among the 8xx processors, all appear to
> > have 16 byte cache lines. All the rest seem to have 32 byte cache lines.
> >
> > There are several solutions here:
> >
> >  - Use ifdef's as is done at present.
> >
> >  - Check the PVR on entry to each of these routines and "do the right
> >    thing".
> >
> >  - Set global variables ppc_cache_linesize and ppc_cache_lineshift
> >    somewhere in MMU_init or setup_arch which then get loaded in the cache
> >    routines.
> >
> > The first option keeps the code small and fast, but doesn't easily cover
> > the dichotomy between the line sizes in 403 and 405 with a simple
> > CONFIG_4xx.
> >
> > The second option incurs a lot of unnecessary overhead per invocation of
> > the routines and adds a lot of special-case code to each routine.
> >
> > The final option seems the best compromise, increasing kernel memory usage
> > by 8 bytes and adding a little code to load the values of
> > ppc_cache_line{size,shift}. All the overhead is then left to a one time
> > invocation in MMU_init or setup_arch.
> >
> > Thoughts, opinions?
> >
> 
> Perhaps calling these routines via a vector whose value is computed at
> boot/setup time that DTRT (does the right thing).  This would keep the
> overhead down to a single load and still provide the desired functionality.

-- 
Dan Taylor
dtaylor@atlp.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Cache Flush and Invalidate Routines

[Dan Malek]

Grant Erickson wrote:
> 
> In trying to accomodate the 4xx-based code into the Linux kernel, I've
> encountered an issue which relates to the cache flushing and invalidation
> routines in misc.S.

> Thoughts, opinions?


We could simply create a configuration #define for the cache line size
that is assigned in the 'make config' scripts when the processor type
is chosen.

A further, and more challenging, problem arises in the library
relocation functions.  When writing instructions to memory, the data
caches have to be pushed, instruction caches invalidated, and the
functions assume a 32 byte cache line.  This doesn't work well on the
16 byte line processors.  We discussed this a long time ago without
resolution.  The old C libraries on the ppc.kernel.org server that I
built for the 8xx have this corrected.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Cache Flush and Invalidate Routines

[Noah Misch]

>On Wed, 8 Dec 1999, Dan Malek wrote:
>> Grant Erickson wrote:
>> > In trying to accomodate the 4xx-based code into the Linux kernel, I've
>> > encountered an issue which relates to the cache flushing and invalidation
>> > routines in misc.S.
>> >
>> > Thoughts, opinions?
>>
>> We could simply create a configuration #define for the cache line size
>> that is assigned in the 'make config' scripts when the processor type
>> is chosen.
>
>In general, I like that idea; however, the 4xx messes things up.
>
>I'd like to have a kernel that will boot on any 4xx-based board (maybe or
>maybe not realistic), so because the 403 uses 16 byte lines and the 405
>uses 32 byte lines, I need a dynamic solution such as the one Gary
>suggested.

Instead of stuff like this:

#ifdef CONFIG_403
...
#endif

you could write the code like this:

if(CONFIG_403) {
...
}

and then remove it with optimization when you wanted to make the slimmest
possible kernel.  Otherwise, don't optimize and it will run on both boards.


>

Noah Misch
nmisch@erols.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PPC Cache Flush and Invalidate Routines

[Dan Malek]

Noah Misch wrote:

> Instead of stuff like this:
> 
> #ifdef CONFIG_403
> ...
> #endif
> 
> you could write the code like this:
> 
> if(CONFIG_403) {
> ...
> }


Except that most of the code under discussion is written
in assembly language.......


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/