Hmm, I'm not quite sure if I've done this correctly. So, I merged that linked patch (3897, this took some minor updating. The fixed patch file is available at https://gist.github.com/devicenull/8720588 and should apply cleanly on 1764).
I also had to add support for this chip, https://gist.github.com/devicenull/8720643
This is enough to get it detected, and reads *seem* to be okay:
# ./flashrom -p buspirate_spi:dev=/dev/ttyUSB1 -r test flashrom v0.9.7-r1764 on Linux 3.11.0-15-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK. Found Macronix flash chip "MX25L25635F" (262144 kB, SPI) on buspirate_spi. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom@flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -VE, -Vw), and mention which mainboard or programmer you tested. Please mention your board in the subject line. Thanks for your help! Reading flash... Flash chip size exceeds the allowed access window. Read will probably fail. Flash chip is not aligned natively in the allowed access window. Read will probably return garbage. done. # ls -l test -rw-r--r-- 1 root root 268435456 Jan 30 16:50 test
However, I don't believe this is actually ok. The read finished in 4 seconds, which is very fast for a bus pirate and 256MB chip.
Writing a file appears to fail (unsurprisingly!):
# ./flashrom -p buspirate_spi:dev=/dev/ttyUSB1 -w ./268435456B flashrom v0.9.7-r1764 on Linux 3.11.0-15-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK. Found Macronix flash chip "MX25L25635F" (262144 kB, SPI) on buspirate_spi. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom@flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -VE, -Vw), and mention which mainboard or programmer you tested. Please mention your board in the subject line. Thanks for your help! Reading old flash chip contents... Flash chip size exceeds the allowed access window. Read will probably fail. Flash chip is not aligned natively in the allowed access window. Read will probably return garbage. done. Erasing and writing flash chip... Flash chip size exceeds the allowed access window. Read will probably fail. Flash chip is not aligned natively in the allowed access window. Read will probably return garbage. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0x10000 ERASE FAILED! FAILED! Uh oh. Erase/write failed. Checking if anything changed. Flash chip size exceeds the allowed access window. Read will probably fail. Flash chip is not aligned natively in the allowed access window. Read will probably return garbage. Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom@flashrom.org, thanks!
I'm wondering if there's anything simple that I could do to correct this. I don't have a whole lot of confidence in the chip definition I came up with, but I'm not sure how to correct it. Is there any way I can actually validate the chip definition is correct? The datasheet is available ( http://datasheet.octopart.com/MX25L25635FZNI-12G-Macronix-datasheet-12537112... ), but it doesn't make a whole lot of sense to me.
On 1/27/2014 8:00 PM, Brian Rak wrote:
On 1/27/2014 6:18 PM, Stefan Tauner wrote:
On Mon, 27 Jan 2014 16:58:45 -0500 Brian Rak brak@gameservers.com wrote:
Is >16MB a feature that hasn't been implemented, or were there problems with it? I find references like http://www.flashrom.org/pipermail/flashrom/2013-July/011301.html , but it doesn't really make a whole lot of sense to me.
That mail is about a related problem that is caused by the current implementation of flashrom that has actually nothing to do with 4-byte addressing - it's a bug.
Ah, thanks for clearing that up.
There is a PoC implementation of 4-byte addressing but i would could it rather a hack than a solution: http://patchwork.coreboot.org/patch/3897/
I seem to find some patches that add it as well, but they don't appear to have ever made it in.
Probably the one above(?) Maybe you can get it to work for your use case but due to time constraints I can not assist you (much) further, sorry.
That was the one, yea. I never really found it on the patchwork site, only referenced in some mailing list posts. I'll have to see if I can get it working, having a hack that works is quite all right for me.
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom