[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS is not broken (Was: JFFS broken?)



> >  I am guessing here, but are you by any chance using burst read
> > towards you flash?

Yes we are. But as david points out below, it needs some help from MTD to
call a cache invalidation on changed data, or doing it inside the flash
drivers write code.

> > If you are, I would like to know how you have done that. I understand
> > that it involves mapping the flash to 2 virtual address spaces, one
> > cached and one uncached. The "copy_from" function should use the
> > cached address space, the other functions the uncached address space.

Yes. This mapping is very probably very hardware specific though. It's
easy enough to do on our chip (the Etrax 100LX) because bit 31 controls if
the access is cached or not, but on other architectures you might need
bits in the TLB entry to control it etc.

> > Then there is some "cache management magic" that has to be done to avoid
> > corruption, and here I am lost. What has to be done and why?

> Doing burst reads depends a _lot_ on your hardware, but I have _assumed_ 
> that in order to get burst reads, you have to use a cached mapping of the 
> address range in question - where else would it put the remainder of the 
> burst otherwise?

That makes sense.. 

> Using a cached mapping for flash is a pain, because the contents of the 
> flash appear to change - so for sending commands you need to use an 
> uncached mapping - only for doing large reads do you want the cached 
> mapping, and you need to invalidate the cache whenever you write to or 
> erase the flash.

Which is not necessarily a pain - the places where the flash is written to
are extremely localized (in the driver) but depending on how the cache
works, it might be slow to have to flush a lot of data.

I guess it requires global benchmarks involving the whole system to figure
out if it's worth keeping the cache coherent or entirely bypassing it.

Since we quite often do large reads, i.e. reading compressed pages from
the filesystem into the page cache, I believe cached reads can be a win
but it depends on the burst hardware and waitstates used as well. If you
have a killer slow waitstate, it does not help to burst read it.. :) 

We're checking benchmarks on our system now to figure out if we can simply
skip the caching totally.

-BW



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com