[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Kumar Gala]

So we have a patch to CFI flash to use DQ7/#data polling instead of  
DQ6/toggle.  There seems to have been some discussion from time to  
time regard this and several people have reported empirical evidence  
about how DQ7 appears to work better for them on some systems.

I was hoping to understand what the issues are with getting such a  
change accepted.

- k

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Stefan Roese]

Hi Kumar,

On Tuesday 27 November 2007, Kumar Gala wrote:
> So we have a patch to CFI flash to use DQ7/#data polling instead of
> DQ6/toggle.  There seems to have been some discussion from time to
> time regard this and several people have reported empirical evidence
> about how DQ7 appears to work better for them on some systems.

I have to admit, that I don't remember those discussions. Could you please 
refresh my memory? And why exactly are you implementing this change? What 
problem does it fix?

> I was hoping to understand what the issues are with getting such a
> change accepted.

If your patch fixes a problem, then chances are quite good. :)

BTW: What does Linux MTD do? DQ7/data or DQ6/toggle? (I'm just too lazy to 
check myself :))

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Kumar Gala]

On Nov 27, 2007, at 12:41 PM, Stefan Roese wrote:

> Hi Kumar,
>
> On Tuesday 27 November 2007, Kumar Gala wrote:
>> So we have a patch to CFI flash to use DQ7/#data polling instead of
>> DQ6/toggle.  There seems to have been some discussion from time to
>> time regard this and several people have reported empirical evidence
>> about how DQ7 appears to work better for them on some systems.
>
> I have to admit, that I don't remember those discussions. Could you  
> please
> refresh my memory? And why exactly are you implementing this change?  
> What
> problem does it fix?

http://search.gmane.org/?query=DQ7&group=gmane.comp.boot-loaders.u-boot

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  
seems to work reliable for the flash parts we have on some of the  
boards.

>> I was hoping to understand what the issues are with getting such a
>> change accepted.
>
> If your patch fixes a problem, then chances are quite good. :)
>
> BTW: What does Linux MTD do? DQ7/data or DQ6/toggle? (I'm just too  
> lazy to
> check myself :))

It looks like it just uses DQ6/toggle if I'm reading the code correctly.

- k

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Wolfgang Denk]

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:

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.

> 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.

> 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.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The high cost of living hasn't affected its popularity.

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Kumar Gala]

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

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Haavard Skinnemoen]

On Wed, 28 Nov 2007 00:03:48 +0100
Wolfgang Denk <wd@denx.de> wrote:

> 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.

I happen to have a patch lying around which does exactly that, in
addition to a few other cleanups.

Stefan, if you could push out all the stuff you have pending to the CFI
custodian tree, I can rebase my stuff on top of that and submit for
review.

> > 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.

Only if CONFIG_MTD_COMPLEX_MAPPINGS=y. Otherwise, it uses
__raw_write[bwl].

Haavard

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Stefan Roese]

Hi Haavard,

On Wednesday 28 November 2007, Haavard Skinnemoen wrote:
> > 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.
>
> I happen to have a patch lying around which does exactly that, in
> addition to a few other cleanups.

Great.

> Stefan, if you could push out all the stuff you have pending to the CFI
> custodian tree, I can rebase my stuff on top of that and submit for
> review.

I suggest that we wait a few days more, till the new Makefile rework etc is in 
place. I'll then merge the master repo into the CFI custodian repo and push 
the pending changes in (mainly the non-CFI/JEDEC support). After this you can 
rebase your patch against the CFI repo. I suspect that this will happen 
sometime next week.

What do you think? Does this sound like a plan or what? :)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Haavard Skinnemoen]

On Wed, 28 Nov 2007 16:35:56 +0100
Stefan Roese <sr@denx.de> wrote:

> What do you think? Does this sound like a plan or what? :)

Absolutely. Please drop me a note when you're ready.

Haavard

[U-Boot-Users] CFI flash polling for AMD/SPANSION?

[Stefan Roese]

On Wednesday 28 November 2007, Haavard Skinnemoen wrote:
> > What do you think? Does this sound like a plan or what? :)
>
> Absolutely. Please drop me a note when you're ready.

Ready for updates. The u-boot-cfi-flash custodian repo waits for your new 
shiny patches... :)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================