CFI driver does not verify writes in buffered mode - feature?
Hi,
when using the CFI flash driver with CFG_FLASH_USE_BUFFER_WRITE the "usual" verification whether the write did indeed happen correctly is not done:
=> erase fc000000 +1
. done
Erased 1 sectors
=> mw 200000 55555555 100
=> cp.b 200000 fc000000 100
Copy to Flash... done
=> md fc000000
fc000000: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000010: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000020: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000030: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000040: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000050: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000060: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000070: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000080: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000090: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000a0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000b0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000c0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000d0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000e0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000f0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU => mw 200000 ffffffff 100 => cp.b 200000 fc000000 100 Copy to Flash... done => md fc000000 fc000000: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000010: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000020: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000030: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000040: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000050: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000060: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000070: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000080: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000090: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000a0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000b0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000c0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000d0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000e0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000f0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU
So the write did indeed *not proceed* correctly without the expected "flash not erased" error message appearing.
The behaviour is not consistent, so either we should do verification of the write or we should have some kind of warning here. Does anyone see an easy way to become consistent here?
Thanks
Detlev
Signature · 6 lines
Emacs seems a more likely candidate to contain a mail system than the
mail system to contain an Emacs, so this is the way it was done.
-- Bernard S. Greenberg
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany +49 8142 66989 40Quoted 52 lines · Detlev Zundel
Hi,
when using the CFI flash driver with
CFG_FLASH_USE_BUFFER_WRITEthe "usual" verification whether the write did indeed happen correctly is not done:=> erase
fc000000+1. done
Erased 1 sectors
=> mw 200000 55555555 100
=> cp.b 200000fc000000100
Copy to Flash... done
=> mdfc000000fc000000: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000010: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000020: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000030: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000040: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000050: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000060: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000070: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000080: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000090: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000a0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000b0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000c0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000d0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000e0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000f0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU => mw 200000 ffffffff 100 => cp.b 200000 fc000000 100 Copy to Flash... done => md fc000000 fc000000: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000010: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000020: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000030: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000040: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000050: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000060: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000070: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000080: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc000090: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000a0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000b0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000c0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000d0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000e0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU fc0000f0: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU
Quoted 2 lines
So the write did indeed *not proceed* correctly without the expected "flash not erased" error message appearing.
In the above example you are overwriting the same data. Which is OK to write without erasing first. You can turn 1 bits to 0 or re-write the same data without erasing which is OK. The redundant environment implementation takes advantage of this in U-Boot. This is not an error.
Am I missing something?
Tolunay
Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 4 lines
when using the CFI flash driver with
CFG_FLASH_USE_BUFFER_WRITEthe "usual" verification whether the write did indeed happen correctly is not done:
...
Quoted 6 lines
In the above example you are overwriting the same data. Which is OK to write without erasing first. You can turn 1 bits to 0 or re-write the same data without erasing which is OK. The redundant environment implementation takes advantage of this in U-Boot. This is not an error.
Am I missing something?
Yes, you do. Detlev wrote different data, and it was not discovered by the CFI driver. Using one of the propriatary flash drivers like on the TQM8xxL will complain...
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, CEO: 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 We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.
Quoted 10 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 3 lines
when using the CFI flash driver with
CFG_FLASH_USE_BUFFER_WRITEthe "usual" verification whether the write did indeed happen correctly is not done:...
Quoted 5 lines
In the above example you are overwriting the same data. Which is OK to write without erasing first. You can turn 1 bits to 0 or re-write the same data without erasing which is OK. The redundant environment implementation takes advantage of this in U-Boot. This is not an error.
Quoted 5 lines
Quoted 1 line
Am I missing something?
Yes, you do. Detlev wrote different data, and it was not discovered by the CFI driver. Using one of the propriatary flash drivers like on the TQM8xxL will complain...
Yes, in that case we need to fix this! Detlev, do you have a patch suggestion?
Tolunay
Hello Tolunay,
Quoted 12 lines
Quoted 11 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 3 lines
when using the CFI flash driver with
CFG_FLASH_USE_BUFFER_WRITEthe "usual" verification whether the write did indeed happen correctly is not done:...
Quoted 6 lines
In the above example you are overwriting the same data. Which is OK to write without erasing first. You can turn 1 bits to 0 or re-write the same data without erasing which is OK. The redundant environment implementation takes advantage of this in U-Boot. This is not an error.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Am I missing something?
Yes, you do. Detlev wrote different data, and it was not discovered by the CFI driver. Using one of the propriatary flash drivers like on the TQM8xxL will complain...
Yes, in that case we need to fix this! Detlev, do you have a patch suggestion?
No sorry, not right now. This actually turned out to be a problem during a training that I do right now. The participants complained that they copied u-boot images being correct in RAM to flash but they were corrupt in flash. It took me a while to figure out what was going on here.
If I understand the code correctly then we would have to do a buffer read after a buffer write and compare the data, right? I am not too fluent in working with CFI flashes so I would have to look up all details like can I simply read from flash after the program cycle or do I have to do things like take it out of command mode etc so I couldn't come up with a fix "after work".
On the other hand I consider this to be a serious problem so I brazenly posted it in the hope that someone else might be able to solve it more quickly. If this does not happen, I will have to spend some time on it, but this will not happen this week nor early next week...
Thanks
Detlev
Signature · 7 lines
I will use free software even if it is less powerful, or less reliable,
because freedom is the most important thing, and that is what the Free
Software movement is about. How we get freedom.
-- Richard M. Stallman
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany +49 8142 66989 40Quoted 7 lines · Detlev Zundel
If I understand the code correctly then we would have to do a buffer read after a buffer write and compare the data, right? I am not too fluent in working with CFI flashes so I would have to look up all details like can I simply read from flash after the program cycle or do I have to do things like take it out of command mode etc so I couldn't come up with a fix "after work".
There is an opportunity to do the verification at a higher level. This would standardize verification after right copying of the block/segment in cp command. What do you think? That would leave the driver simplified. I am personally not too happy to generate interactive messages from within the driver. Different flash drivers emit different messages. A unified user experience would be better in my opinion...
Tolunay