On Wed, 4 Mar 2015 11:32:04 +0200 Urja Rannikko urjaman@gmail.com wrote:
Hi,
I've an idea. Maybe you've managed to switch the MX25L6445E into the "individual block protection mode" (read the datasheet page 30 - its an OTP, once done once its for good) and now it isnt actually erasing/writing anything at all (that 1M just happens to have succeeded previously) because flashrom currently doesnt know of the invidividual block unlock commands (or even the GBULK gang block unlock) and thinks everything is ok because the status register looks like unlocked.
So maybe read the current contents into a file and modify a little bit in the erased area (eg. swap out the first 4k to random data*) and see if it writes. My theory is it wont.
*here's example commands: flashrom <insert your parameters> -r current.bin dd if=/dev/urandom of=4krandom.bin bs=1024 count=4 dd if=current.bin bs=1024 skip=4 of=current-4.bin cat 4krandom.bin current-4.bin > modified.bin flashrom <parameters> -w modified.bin
Somebody'd need to write a patch to flashrom to use the RDSCUR command to see if WPSEL is set to see for sure. But support for this wouldnt hurt anyways. I'll see if i have time later in the evening to make a prototype/test patch for this...
I already had the datasheet open, so... here it is (in slightly crude form). https://github.com/urjaman/flashrom/commit/b51f09e5f21bf14d492c7d006e0bdd869... there's the commit if somebody wants to just web see. To test, in the flashrom-serprog git tree you have: git pull git checkout mx25l6445e-debug make ./flashrom ...
Hi,
was this ever tested? I have a MX25L25635F which is yet unsupported due to the larger address space etc. and I could test this eventually some time in the future... but I would prefer to get support for this into flashrom earlier than that (2016? :)
Hi Guys
Have found another two of these chip. And funny: One chip works, the other not! But i have no idea why!?!
Tested with flashrom 0.9.8-rc1-r1886 and newest serprog (git from today 26.6.15).
Chip1 (codename "Yellow") works (tested more than one time). Chip2 (codename "Brown") does not work (also tested more than one time).
Wireing is the same, so i think its not a "hardware" problem. To be 100% sure i pull pin9 (WP) to high on both (to disable WP).
Now i am confused! :-/
Any ideas? Can i do something to help fixing this problem? Now we have a working chip, maybe this helps?
Greets