[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