Re: [ECOS] ppc603e cache sync

Re: [ECOS] ppc603e cache sync

[Daniel Kahlin]

Jesper Skov wrote:
> The few other CPUs that have to do this use either a dedicated chunk
> of the address space or read from the ROM. See the TX39 var_cache.h
> file.

Ok, but I have the FLASH marked as cache-inhibited for now, and then it
doesn't work. :(

> The only other place were we do this by steam is in the kcache
> tests. There the array is called 'dca' - data cache array or some
> such. Not something that has been blessed with official policy (yet).

I will have to put and ifdef:ed array somewhere in the hal. 
maybe in arch/hal_misc.c.
 cyg_uint8 hal_data_cache_array[HAL_DCACHE_SIZE]

> Doesn't it have the implementation specific flush-all command as the
> 603? I don't have my manuals close by, unfortunately, but the 603
> definitely has a one-shot operation for flushing (or is it clearing?)
> the cache.

You probably mean the DCFI bit in HID0.  It invalidates the cache, and
that would be fine, if it wasn't for the cache being writeback.
But maybe I've missed something in the documentation.

> If not, maybe something like the below would be better (from my
> Linux/APUS sources):

The problem with using the 'dcbz' (and all other) cache instructions is
that the operate on memory addresses instead of indexes into the cache.
Normally that is what you want, but if you want to flush all cache
entries into memory you would have to scan the entire 32 bit address
range.   
Trick: Allocate all entries of the cache to an unused area.  

/Daniel

-- 
Daniel Kahlin <daniel.kahlin@netinsight.se>
Hardware System Designer
Net Insight AB
URL: http://www.netinsight.se/

Re: [ECOS] ppc603e cache sync

[Jesper Skov]

daniel> Maybe this isn't the right forum for this but:

daniel> I need to flush the cache on an MPC8240, which is basicly a
daniel> ppc603e.  One way of doing this is to zero the cache with a
daniel> dummy area, this area need not be specially aligned, and could
daniel> be put into the .bss section.
 
daniel> - - In which source file would it be logical to place it?

daniel> - - and what should that area be named?

The few other CPUs that have to do this use either a dedicated chunk
of the address space or read from the ROM. See the TX39 var_cache.h
file.

The only other place were we do this by steam is in the kcache
tests. There the array is called 'dca' - data cache array or some
such. Not something that has been blessed with official policy (yet).

daniel> Maybe someone could suggest a neater solution?

Doesn't it have the implementation specific flush-all command as the
603? I don't have my manuals close by, unfortunately, but the 603
definitely has a one-shot operation for flushing (or is it clearing?)
the cache.

If not, maybe something like the below would be better (from my
Linux/APUS sources):

#define L1_CACHE_BYTES 32
#define MAX_CACHE_SIZE 8192
__apus
void cache_push(__u32 addr, int length)
{
        addr = mm_ptov(addr);

        if (MAX_CACHE_SIZE < length)
                length = MAX_CACHE_SIZE;

        while(length > 0){
                __asm ("dcbf 0,%0\n\t"
                       : : "r" (addr));
                addr += L1_CACHE_BYTES;
                length -= L1_CACHE_BYTES;
        }
        /* Also flush trailing block */
        __asm ("dcbf 0,%0\n\t"
               "sync \n\t"
               : : "r" (addr));
}

Jesper

Re: [ECOS] ppc603e cache sync

[Jesper Skov]

>>>>> "Daniel" == Daniel Kahlin <tlr@netinsight.se> writes:

>> The only other place were we do this by steam is in the kcache
>> tests. There the array is called 'dca' - data cache array or some
>> such. Not something that has been blessed with official policy
>> (yet).

Daniel> I will have to put and ifdef:ed array somewhere in the hal.
Daniel> maybe in arch/hal_misc.c.  cyg_uint8
Daniel> hal_data_cache_array[HAL_DCACHE_SIZE]

Looks good to me. Remember to use GCC attributes to ensure proper
alignment.

>> Doesn't it have the implementation specific flush-all command as
>> the 603? I don't have my manuals close by, unfortunately, but the
>> 603 definitely has a one-shot operation for flushing (or is it
>> clearing?)  the cache.

Daniel> You probably mean the DCFI bit in HID0.  It invalidates the
Daniel> cache, and that would be fine, if it wasn't for the cache
Daniel> being writeback.  But maybe I've missed something in the
Daniel> documentation.

Yup, that's what I was thinking about. If there's only the DCFI bit,
that's probably all. Too bad.

>> If not, maybe something like the below would be better (from my
>> Linux/APUS sources):

Daniel> The problem with using the 'dcbz' (and all other) cache
Daniel> instructions is that the operate on memory addresses instead
Daniel> of indexes into the cache.  Normally that is what you want,
Daniel> but if you want to flush all cache entries into memory you
Daniel> would have to scan the entire 32 bit address range.  Trick:
Daniel> Allocate all entries of the cache to an unused area.

You are right. I've been bitten by that before - but I do think we
found some way around it. I forget.

Your solution is fine if it works.

Jesper

Re: [ECOS] ppc603e cache sync

[Gary Thomas]

On 13-Aug-99 Jesper Skov wrote:
>>>>>> "Daniel" == Daniel Kahlin <tlr@netinsight.se> writes:
> 
>>> The only other place were we do this by steam is in the kcache
>>> tests. There the array is called 'dca' - data cache array or some
>>> such. Not something that has been blessed with official policy
>>> (yet).
> 
> Daniel> I will have to put and ifdef:ed array somewhere in the hal.
> Daniel> maybe in arch/hal_misc.c.  cyg_uint8
> Daniel> hal_data_cache_array[HAL_DCACHE_SIZE]
> 
> Looks good to me. Remember to use GCC attributes to ensure proper
> alignment.
> 
>>> Doesn't it have the implementation specific flush-all command as
>>> the 603? I don't have my manuals close by, unfortunately, but the
>>> 603 definitely has a one-shot operation for flushing (or is it
>>> clearing?)  the cache.
> 
> Daniel> You probably mean the DCFI bit in HID0.  It invalidates the
> Daniel> cache, and that would be fine, if it wasn't for the cache
> Daniel> being writeback.  But maybe I've missed something in the
> Daniel> documentation.
> 
> Yup, that's what I was thinking about. If there's only the DCFI bit,
> that's probably all. Too bad.
> 

There is no magic "flush and invalidate all entries" operation on any
PowerPC I know about.  The DCFI only invalidates, no flush.

>>> If not, maybe something like the below would be better (from my
>>> Linux/APUS sources):
> 
> Daniel> The problem with using the 'dcbz' (and all other) cache
> Daniel> instructions is that the operate on memory addresses instead
> Daniel> of indexes into the cache.  Normally that is what you want,
> Daniel> but if you want to flush all cache entries into memory you
> Daniel> would have to scan the entire 32 bit address range.  Trick:
> Daniel> Allocate all entries of the cache to an unused area.
> 

This isn't strictly true.  Given that each cache line has a tag which
is comprised in part of only a few address bits, you can use 'dcbz' or
'dcbtst' as long as you cover a range of addresses which are sufficiently
large to cause all lines in the cache to be touched.  It's not necessary
to actually access the address that's in the cache, only some address
whose cache tag matches.

[ECOS] ppc603e cache sync

[Daniel Kahlin]

Maybe this isn't the right forum for this but:

I need to flush the cache on an MPC8240, which is basicly a ppc603e.
One way of doing this is to zero the cache with a dummy area, this area
need not be specially aligned, and could be put into the .bss section.
 
- In which source file would it be logical to place it?

- and what should that area be named?

Maybe someone could suggest a neater solution?

BTW. the 'sync' is probably only needed once after the for loop.


/Daniel

hal/powerpc/arch/current/include/hal_cache.h
---------------------
// Synchronize the contents of the cache with memory.
// a bit brain damaged... assumes, no write modify on area defined
#define HAL_DCACHE_DUMMYAREA 0x20000
#define HAL_DCACHE_SYNC()                                              
\
    CYG_MACRO_START                                                    
\
    cyg_int32 __offset;                                                
\
    cyg_uint32 __base = HAL_DCACHE_DUMMYAREA;                          
\
    for (__offset=0;                                                   
\
         __offset < HAL_DCACHE_SIZE;                                   
\
         __offset+=HAL_DCACHE_LINE_SIZE) {                             
\
        asm volatile ("dcbz 0,%0;sync;" : : "r" (__base + __offset));  
\
    }                                                                  
\
    CYG_MACRO_END
---------------------


-- 
Daniel Kahlin <daniel.kahlin@netinsight.se>
Hardware System Designer
Net Insight AB
URL: http://www.netinsight.se/