On Nov 27, 2007, at 5:03 PM, Wolfgang Denk wrote:
In message <9CAC8A3B-89FA-44C3-B554- A53C79A0003D@kernel.crashing.org> you wrote:
I'm told that higher frequencies we have issues using the toggle method on 85xx/86xx parts from freescale. But use DQ7 at those freq
Given the fact that the CFI code has absolutely no knowledge about which processor it is running on, this means one or both of two things:
- There are issues with certain versions of certain toolchains which
happen to be used with the processors in question
- The processors in question are more likely to have problems with
unexpected out-of-order scheduling / instruction reordering etc.
Please note that the current CFI driver accesses the flash by plain pointer references, in some cases even without using "volatile". This is supposed to cause problems sooner or later.
I think the CFI driver needs some basic rework to get ridof such pointer accesses and use proper accessor functions/macros instead to make sure we have all the memory barriers etc. we may need.
Good to know. I'll see if I can get a test case that fails and play with fixing up the accessors to have barriers and the such.
seems to work reliable for the flash parts we have on some of the boards.
If the DQ7 method works better, we could compare the code. Check for example for missing volatiles - but even better fix the code to use correct accessors.
Agreed. Hopefully I can get a testcase from the people that have seen this to know if I'm actually fixing the code by adding proper accessors.
It looks like it just uses DQ6/toggle if I'm reading the code correctly.
Note that Linux calls a (map)->write() function to access the flash.
I came across the following comment:
* Note that anything more complicated than checking if no bits are toggling * (including checking DQ5 for an error status) is tricky to get working * correctly and is therefore not done (particulary with interleaved chips * as each chip must be checked independantly of the others).
- k