On Fri, 24 Jan 2014 14:05:17 +0100 Idwer Vollering vidwer@gmail.com wrote:
Which version or build of flashrom were you using? Chip support for this MX25L25635F was committed a while ago: http://flashrom.org/trac/flashrom/changeset/1702
That is not true. The only thing that was committed was the ID (for further reference). This chip requires 4-byte addressing because it is >16MB and hence wont be supported soonish.
On 1/27/2014 3:29 PM, Stefan Tauner wrote:
On Fri, 24 Jan 2014 14:05:17 +0100 Idwer Vollering vidwer@gmail.com wrote:
Which version or build of flashrom were you using? Chip support for this MX25L25635F was committed a while ago: http://flashrom.org/trac/flashrom/changeset/1702
That is not true. The only thing that was committed was the ID (for further reference). This chip requires 4-byte addressing because it is >16MB and hence wont be supported soonish.
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. I seem to find some patches that add it as well, but they don't appear to have ever made it in.
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.
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.
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.
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
I think I've gotten reads working, just needed this relatively minor patch: https://gist.github.com/devicenull/8735650
Writes are still failing though:
Reading old flash chip contents... done. Erasing and writing flash chip... 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.
On 1/30/2014 4:56 PM, Brian Rak wrote:
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
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
On Fri, 31 Jan 2014 11:33:02 -0500 Brian Rak brak@gameservers.com wrote:
I think I've gotten reads working, just needed this relatively minor patch: https://gist.github.com/devicenull/8735650
Writes are still failing though:
Reading old flash chip contents... done. Erasing and writing flash chip... 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.
That could simply be the write protection. Have you connected all pins correctly, especially the #WP pin? I have not looked at all the changes you made, but not connecting the #WP pin would be the most obvious cause for this behavior. Sorry for the late reply...
-
Brian Rak -
Stefan Tauner -
Stefan Tauner