*now to the list as well* Hello Carl-Daniel,
Carl-Daniel Hailfinger wrote:
what's the current status of your machine? Please see below for some news.
The machine is still running, didn't try to reboot yet. I'll try to sum up what we tried with help from you and others on irc / some facts.
- The chip does Erase properly - When writing a normal image the byte at 0x5555 is incorrect. (0xaa instead of 0xff) - When I replace byte at 0x5555 with 0x00 in the image, 0x00 is properly written but the verification fails at 0x2a000 (if I remember correctly) which I heard is also a magic address. - I pulled out the chip in the running system and reinserted it in the hope to reset byte 0x5555. Did not help. (?conclusion: the wrong value is actually in memory?) - I added delay statements in the code in all mmio_readx functions, took 10 minutes to flash, but result was the same. - writing an all 0xFF file does work correctly.
I hope I remember everything correctly, can't verify right now. Also we prepped an image which would have a 0 checksum when the 0xaa byte is written to be sure. Haven't been able to verify that is actually was 0.
I found a bug in flashrom which could partially explain what Yuri was seeing. It was already present in the first revision of flashrom back in 2003 and will only appear in very special circumstances which are very difficult to hit. I had to read a few datasheets twice before even seeing what was wrong. "Enable protection" is a command with side effects on some chips (the side effect is trashing the contents of address 0x5555 with subsequent commands). To see the effect, you have to have bad luck with chip timing, exact chip type, the kernel process scheduler, delay calibration and others.
Sounds interesting. You write partially, is there anything you can't explain yet?
Regards, Yuri