On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) { printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; } }
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
Regards, Carl-Daniel