[U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems

[U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems

[Wolfgang Denk]

Hi Stefan,

even after pulling the latest CFI updates from the u-boot-cfi-flash
repository, I still see the following issues:

a) on MPC8260:

[Stefan: for testing please use the TQM8260_AD board in the xpert VL.]

The CFI driver returns from an "erase" operation with the flash still
in a undefined state; immediate reads after an erase do not show 0xFF
patterns. If you wait a few  milliseconds,  the  flash  will  finally
change into the expected erased state.

Example:

=> era 40280000 +1 ; md 40280000 10 ; sleep 1 ; md 40280000

. done
Erased 1 sectors
40280000: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
40280010: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
40280020: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
40280030: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
40280000: ffffffff ffffffff ffffffff ffffffff    ................	<- good
40280010: ffffffff ffffffff ffffffff ffffffff    ................	<- good
40280020: ffffffff ffffffff ffffffff ffffffff    ................	<- good
40280030: ffffffff ffffffff ffffffff ffffffff    ................	<- good

Playing with CFI paramaters (like manually increasing  write  timeout
and/or  erase  timeout) does not change anything. Neither does adding
sync()  instructions  to   the   flash_read?()   and   flash_write?()
functions.

b) on 440EPx:

[Stefan: for testing please use the Sequoia board in the pollux VL.]

The CFI driver does not detect that it's writing to flash that is not
(sufficiently) erased:

=> md FC000000 10
fc000000: 00000000 00000000 00000000 00000000    ................
fc000010: 00000000 00000000 00000000 00000000    ................
fc000020: 00000000 00000000 00000000 00000000    ................
fc000030: 00000000 00000000 00000000 00000000    ................
=> mw.b 0 FF 400
=> md 0
00000000: ffffffff ffffffff ffffffff ffffffff    ................
00000010: ffffffff ffffffff ffffffff ffffffff    ................
00000020: ffffffff ffffffff ffffffff ffffffff    ................
00000030: ffffffff ffffffff ffffffff ffffffff    ................
=> cp.b 0 FC000000 400
Copy to Flash... done		<= should issue error message here!!!!
=> md FC000000
fc000000: 00000000 00000000 00000000 00000000    ................
fc000010: 00000000 00000000 00000000 00000000    ................
fc000020: 00000000 00000000 00000000 00000000    ................
fc000030: 00000000 00000000 00000000 00000000    ................
=> 

I consider this a major bug.


Any ideas what might cause such effects?

Best regards,
Viele Gr??e,

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
Today is the yesterday you worried about tomorrow.

[U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems

[Haavard Skinnemoen]

On Thu, 27 Dec 2007 00:09:25 +0100
Wolfgang Denk <wd@denx.de> wrote:

> even after pulling the latest CFI updates from the u-boot-cfi-flash
> repository, I still see the following issues:

By "still", do you mean it's not a regression? IOW, is this something
my patches introduced or was it broken before?

The patch series is meant to be fully bisectable, so if you can find
out which particular patch caused this breakage, I'll have another look
to see if I messed something up...

Haavard

[U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems

[Wolfgang Denk]

Dear Haavard,

in message <20071227004211.2a6cc78d@siona> you wrote:
> 
> > even after pulling the latest CFI updates from the u-boot-cfi-flash
> > repository, I still see the following issues:
> 
> By "still", do you mean it's not a regression? IOW, is this something
> my patches introduced or was it broken before?

It's not a regression - the same problems were there before,  but  my
hope  was that the introduction of the accessor functions (instead of
using plain pointers) might fix the issue. Unfortunately it does not,
the problems remain :-(

> The patch series is meant to be fully bisectable, so if you can find
> out which particular patch caused this breakage, I'll have another look
> to see if I messed something up...

It's not your fault - except of course that your  patches  failed  to
fix these old bugs ;-)

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
Doubt is a pain too lonely to know that faith is his twin brother.
- Kahlil Gibran

[U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems

[Stefan Roese]

Hi Wolfgang,

On Thursday 27 December 2007, Wolfgang Denk wrote:
> even after pulling the latest CFI updates from the u-boot-cfi-flash
> repository, I still see the following issues:
>
> a) on MPC8260:
>
> [Stefan: for testing please use the TQM8260_AD board in the xpert VL.]
>
> The CFI driver returns from an "erase" operation with the flash still
> in a undefined state; immediate reads after an erase do not show 0xFF
> patterns. If you wait a few  milliseconds,  the  flash  will  finally
> change into the expected erased state.
>
> Example:
>
> => era 40280000 +1 ; md 40280000 10 ; sleep 1 ; md 40280000
>
> . done
> Erased 1 sectors
> 40280000: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
> 40280010: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
> 40280020: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
> 40280030: 004c004c 00080008 004c004c 00080008    .L.L.....L.L....	<= bad
> 40280000: ffffffff ffffffff ffffffff ffffffff    ................	<- good
> 40280010: ffffffff ffffffff ffffffff ffffffff    ................	<- good
> 40280020: ffffffff ffffffff ffffffff ffffffff    ................	<- good
> 40280030: ffffffff ffffffff ffffffff ffffffff    ................	<- good
>
> Playing with CFI paramaters (like manually increasing  write  timeout
> and/or  erase  timeout) does not change anything. Neither does adding
> sync()  instructions  to   the   flash_read?()   and   flash_write?()
> functions.

Unfortunately I have no clue right now what could be causing this. I'll try to 
dig into it when I find a little time for it.

> b) on 440EPx:
>
> [Stefan: for testing please use the Sequoia board in the pollux VL.]
>
> The CFI driver does not detect that it's writing to flash that is not
> (sufficiently) erased:
>
> => md FC000000 10
> fc000000: 00000000 00000000 00000000 00000000    ................
> fc000010: 00000000 00000000 00000000 00000000    ................
> fc000020: 00000000 00000000 00000000 00000000    ................
> fc000030: 00000000 00000000 00000000 00000000    ................
> => mw.b 0 FF 400
> => md 0
> 00000000: ffffffff ffffffff ffffffff ffffffff    ................
> 00000010: ffffffff ffffffff ffffffff ffffffff    ................
> 00000020: ffffffff ffffffff ffffffff ffffffff    ................
> 00000030: ffffffff ffffffff ffffffff ffffffff    ................
> => cp.b 0 FC000000 400
> Copy to Flash... done		<= should issue error message here!!!!
> => md FC000000
> fc000000: 00000000 00000000 00000000 00000000    ................
> fc000010: 00000000 00000000 00000000 00000000    ................
> fc000020: 00000000 00000000 00000000 00000000    ................
> fc000030: 00000000 00000000 00000000 00000000    ................
> =>
>
> I consider this a major bug.

Yes, me too.

A quick look at the code shows, that the check for a (sufficiently) erased 
destination is totally missing from the buffered write version (enabled via 
the CFG_FLASH_USE_BUFFER_WRITE define). I'll send a patch in a minute that 
fixes this problem. Tested on Sequoia.

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 accessor functions used for source read too

[Stefan Roese]

Hi Haavard,

Wolfgang just noticed that we (you in your original patches and myself in the 
latest patch) use flash_read8() (etc.) to read from source location too. 
Since this source is normally not located in FLASH, I'm not so sure anymore 
if we should use these accessors here too.

Any comments on this welcome.

Thanks.

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 accessor functions used for source read too

[Haavard Skinnemoen]

On Wed, 2 Jan 2008 11:52:52 +0100
Stefan Roese <sr@denx.de> wrote:

> Hi Haavard,
> 
> Wolfgang just noticed that we (you in your original patches and myself in the 
> latest patch) use flash_read8() (etc.) to read from source location too. 
> Since this source is normally not located in FLASH, I'm not so sure anymore 
> if we should use these accessors here too.

Right. I did that just to introduce as few surprises as possible --
originally, the source data was accessed through a volatile pointer, so
converting it to use the accessor functions seemed like the natural
thing to do.

I don't think it's really necessary though. The source data isn't
supposed to change underneath us, so accessing it through a regular,
non-volatile pointer should work just fine.

Haavard

[U-Boot-Users] CFI: flash accessor functions used for source read too

[Wolfgang Denk]

Dear Haavard,

in message <20080104154223.1b874a41@dhcp-252-066.norway.atmel.com> you wrote:
> 
> > Wolfgang just noticed that we (you in your original patches and myself in the 
> > latest patch) use flash_read8() (etc.) to read from source location too. 
> > Since this source is normally not located in FLASH, I'm not so sure anymore 
> > if we should use these accessors here too.
> 
> Right. I did that just to introduce as few surprises as possible --
> originally, the source data was accessed through a volatile pointer, so
> converting it to use the accessor functions seemed like the natural
> thing to do.
> 
> I don't think it's really necessary though. The source data isn't
> supposed to change underneath us, so accessing it through a regular,
> non-volatile pointer should work just fine.

I'm biased - flash_read*() might, for example, contain bank switching
code on processors (like MPC5200) which have limitations on the flash
sizes thay can directly address. So for copying from flash  to  flash
it  might  actually  be  a  good  idea to use flash_read*(). But then
flash_read*() must also work when accessing RAM or PCI memory or ...

I  think  we  should  at  least   document   the   requirements   for
flash_read*()  - i. e. that it must be capable of reading *arbitrary*
memory areas, not only flash memory.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is nothing in this world constant but inconstancy.      - Swift