[U-Boot-Users] CFI flash polling for AMD/SPANSION?
Kumar Gala
galak at kernel.crashing.org
Wed Nov 28 00:20:47 CET 2007
On Nov 27, 2007, at 5:03 PM, Wolfgang Denk wrote:
> In message <9CAC8A3B-89FA-44C3-B554-
> A53C79A0003D at 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:
>
> 1) There are issues with certain versions of certain toolchains which
> happen to be used with the processors in question
>
> 2) 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
More information about the U-Boot
mailing list