Re: [PATCH] Intel StrataFlash fix for MIPS

[Mark Salter <msalter at redhat dot com>]

On Fri, 2005-01-14 at 14:57 +0100, Andrew Lunn wrote:
> > Since the processor guarantees execution of load/store operations
> > in program order, a dummy read fixes this. It took me a while to
> > notice that neither HAL_REORDER_BARRIER() nor HAL_IO_BARRIER()
> > (the latter does not even exist for MIPS) address this particular
> > problem. AFAICT there is nothing in ecos that does, or am I missing
> > something here?
> 
> Humm, interesting point. I can kind of understand these macros not
> doing what you want. They don't consider instruction fetches as
> upsetting the flow of code. Any processor which can do "branch"
> prediction could be filling its pipeline with code from the caller,
> whch does not work, because its not accessable. 
> 
> It would be interesting to see what the GCC people say about
> this. Maybe we need to add some sort of HAL_FUNCTION_BARRIER macro!
> 

I don't think gcc can do anything about this. It sounds like there
is a write buffer delaying the actual write to flash or the cpu is
prefetching. So a HAL_WB_FLUSH() and/or a cache flush seems to be in
order. Actually, aren't the caches off when the flash functions are
running?

I think the HAL_REORDER_BARRIER() is a hint to gcc not to reorder
code across the barrier. I'm not sure about HAL_IO_BARRIER. Maybe
that should do a write-buffer flush if needed.

--Mark