Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96

[Jun Sun <jsun@mvista.com>]

Jon Burgess wrote:

> 
>>>I don't wonder if other IDT CPUs also require this, including those that
>>>conform MIPS32.
>>>Basically, requirement of uncached run makes hadrware logic much simpler
>>>and allows  to save silicon a bit.
>>>
>>That could be true, but then again I suggest making specific cache routines for
>>
> those
> 
>>CPUs.
>>It would be a real performance hit for the rest of us, if we have to operate
>>
> from
> 
>>uncached space.
>>
> 
> I pulled together the relevant code to generate a module to test this problem
> and it looks like the CPU always misses 1 instruction following the end of the
> cache loop. If I add some nop's to change the alignment of the code it doesn't
> seem to make any difference. The same thing seems to happen even if I change the
> cache flush to a 'Hit_invalidate' of some completely different memory region.
> One thing I thought might happen is the CPU ending the loop early as soon as it
> invalidates the cacheline containing the current instructions, but this doesn't
> seem to be the case, the 'end' address is always correct. Perhaps this really is
> a hardware problem.
> 
> The test module below does a blast_icache then a few well known instructions and
> signifies if anything has been missed. I typically get the following on our
> board.
>      Cacheop skipped 1 instructions, end = 0x80004000



Here is the test results from Malta 4kc

Cacheop skipped 0 instructions, end = 0x80004000

root@10.0.18.6:~# cat /proc/cpuinfo
processor               : 0
cpu model               : MIPS 4Kc V0.1
BogoMIPS                : 79.66
wait instruction        : no
microsecond timers      : yes
extra interrupt vector  : yes
hardware watchpoint     : yes
VCED exceptions         : not available
VCEI exceptions         : not available


Jun