Dominic Sweetman wrote:
> Jun Sun (firstname.lastname@example.org) writes:
> > The first issue is multi-way cache support. DDB5476 uses R5432 CPU
> > which has two-way set-associative cache. The problematic part is
> > the index-based cache operations in r4xxcache.h does not cover all
> > ways in a set.
> > I think this is a problem in general. So far I have seen MIPS
> > processors with 2-way, 4-way and 8-way sets. And I have seen them
> > using ether least- significant-addressing-bits or
> > most-significant-addressing-bits within a cache line to select ways.
> So far as I know the Vr5432 is the only CPU to do anything so silly as
> using the lowest index bits to select the "way".
Actually Sony's R4500 uses the same low bits mechanism.
> Cache maintenance should always use "hit" type instructions, and you
> don't need to know the cache organisation for those, even with the
Ideally - but no in reality. Linux stills uses index-operations a lot.
Theorically, indexed flush is faster if the flushing are is bigger than
the cache size.
> I suggest you should implement the don't-care method, and then have a
> cpu_info-driven special case for the unique and deprecated Vr5432.
If Vr5432 is really that unique, I think that is probably best way, at
least for now.