[flashrom] MX25L25635F support?

[Brian Rak]

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 at 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 at 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 at 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.pdf 
), 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 at 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 at flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom