[U-Boot-Users] CFI driver problems on MPC8260 and 440EPx systems
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
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
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
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@denx.de =====================================================================
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@denx.de =====================================================================
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
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
participants (3)
-
Haavard Skinnemoen -
Stefan Roese -
Wolfgang Denk