dcache questions, bug in alt_dcache_flush

Hi orsino,

> alt_dcache_flush(videoRam, sizeof(videoRam));

>

> The current hal implementation uses the flushda instruction. If the data cache

> size is 8k the function limits the address range that may be flushed to the first 8k

> of the videoRam buffer (comment: "This is the most we would ever need to flush").

Sounds like a bug. Based on the documentation, flushda does recognize the tag,

so alt_dcache_flush() should (must) flush the entire effective address range.

> I changed the hal function to use the flushd instruction as in earlier versions. Then

> everything works as expected.

This makes sense ... since flushd ignores the tag, the address range (span,

whatever) would be limited to the size of the dcache.

> Could someone explain how flushd really works?

flushd ignores the tag, flushes the line if dirty, then invalidates. The key phrase

being: "ignores the tag". When you use flushd, you may end up flushing data that

is not actually in the effective address range of your buffer (only the line indexes

are the same). This is actually a cool feature when your I/O buffers are larger

than your cache -- you save time by (more or less) flushing cache lines, rather

than entire effective address ranges.

flushda is new ... so my experience is with it is limited. However the docs do

suggest that the tags are _not_ ignored -- when using flushda, you need to

check the entire effective address range. (That's why it sounds like a bug to me).

Perhaps the HAL gurus could comment on this.

> Is there a way to invalidate an address range in the cache even if it is

> never modified by the processor?

This always bothered me. The flushd documentation states, "if the line is dirty,

flushd writes the line back to memory and invalidates the line". But it doesn't

state what happens if the line is _not_ dirty -- I've always assumed that the

line is invalidated in either case ... but I really don't know for sure.

Regards,

--Scott