neil@causality.com said:
> I think I recall ripping these out. The write buffer is a physically
> tagged object next to memory, so it only needs to be flushed when
> synchronising main memory for DMA, *not* when cache flushing/
> synchronising. Please check this... 

From the (Digital) SA-110 TRM:

<quote>
6.1.2 Icache Validity

... Instruction fetches do not check the write buffer so data must not 
only be pushed out of the Icache [sic - it probably means Dcache here] but 
the write buffer must also be drained.
</quote>

It doesn't matter too much at the moment, since we don't cache the page 
tables, but I can find no reference in the TRM to the write buffer in 
relation to TLB walks.  Given the above, my suspicion is that the TLB 
walking hardware won't snoop the write buffer either.

neil@causality.com said:
> Also I think there was a reason why the author used two hunks of RAM
> to flush the cache but I can't remember what it was; it seemed the
> popular thing at the time. 

Hmm, the TRM has an example here:

@	R0 points to a 16K region of readable data used only
@	for this cache flushing routine.  If this data is used
@	by other code then 32K must be loaded and the flush MCR
@	is not needed.
writeBackDcache:
	add	r1, r0, #16384
L1:
	ldr	r2, [r0], #32
	teq	r1, r0
	bne	L1
	mcr	p15, 0, r0, c7, c6, 0
	mov	pc, r14

So since we reserve a 16 bank for cache cleaning we don't need a second 
bank.  If there is a reason for the second bank then there is no comment 
explaining why; given the variance from the TRM, that would be a criminal 
omission.

R.