* [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems
@ 2007-12-26 23:09 Wolfgang Denk
2007-12-26 23:42 ` Haavard Skinnemoen
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Wolfgang Denk @ 2007-12-26 23:09 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems
2007-12-26 23:09 [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems Wolfgang Denk
@ 2007-12-26 23:42 ` Haavard Skinnemoen
2007-12-26 23:49 ` Wolfgang Denk
2007-12-27 6:55 ` Stefan Roese
2008-01-02 10:52 ` [U-Boot-Users] CFI: flash accessor functions used for source read too Stefan Roese
2 siblings, 1 reply; 7+ messages in thread
From: Haavard Skinnemoen @ 2007-12-26 23:42 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems
2007-12-26 23:42 ` Haavard Skinnemoen
@ 2007-12-26 23:49 ` Wolfgang Denk
0 siblings, 0 replies; 7+ messages in thread
From: Wolfgang Denk @ 2007-12-26 23:49 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems
2007-12-26 23:09 [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems Wolfgang Denk
2007-12-26 23:42 ` Haavard Skinnemoen
@ 2007-12-27 6:55 ` Stefan Roese
2008-01-02 10:52 ` [U-Boot-Users] CFI: flash accessor functions used for source read too Stefan Roese
2 siblings, 0 replies; 7+ messages in thread
From: Stefan Roese @ 2007-12-27 6:55 UTC (permalink / raw)
To: u-boot
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
=====================================================================
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] CFI: flash accessor functions used for source read too
2007-12-26 23:09 [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems Wolfgang Denk
2007-12-26 23:42 ` Haavard Skinnemoen
2007-12-27 6:55 ` Stefan Roese
@ 2008-01-02 10:52 ` Stefan Roese
2008-01-04 14:42 ` Haavard Skinnemoen
2 siblings, 1 reply; 7+ messages in thread
From: Stefan Roese @ 2008-01-02 10:52 UTC (permalink / raw)
To: u-boot
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
=====================================================================
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] CFI: flash accessor functions used for source read too
2008-01-02 10:52 ` [U-Boot-Users] CFI: flash accessor functions used for source read too Stefan Roese
@ 2008-01-04 14:42 ` Haavard Skinnemoen
2008-01-09 11:22 ` Wolfgang Denk
0 siblings, 1 reply; 7+ messages in thread
From: Haavard Skinnemoen @ 2008-01-04 14:42 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] CFI: flash accessor functions used for source read too
2008-01-04 14:42 ` Haavard Skinnemoen
@ 2008-01-09 11:22 ` Wolfgang Denk
0 siblings, 0 replies; 7+ messages in thread
From: Wolfgang Denk @ 2008-01-09 11:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-01-09 11:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-26 23:09 [U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems Wolfgang Denk
2007-12-26 23:42 ` Haavard Skinnemoen
2007-12-26 23:49 ` Wolfgang Denk
2007-12-27 6:55 ` Stefan Roese
2008-01-02 10:52 ` [U-Boot-Users] CFI: flash accessor functions used for source read too Stefan Roese
2008-01-04 14:42 ` Haavard Skinnemoen
2008-01-09 11:22 ` Wolfgang Denk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox