On 29.03.2008 22:58, Fredrik Tolf wrote:
On Sat, 2008-03-29 at 22:17 +0100, Carl-Daniel Hailfinger wrote:
I'm attaching my patch to fix the problem. I would imagine that the other M25Pxx chips would be affected by the same problem, but since I can neither verify nor test what IDs they would have, they are excluded from my patch.
Thanks for investigating and coding this. However, I have to veto the patch in its current form. I know at least 4 flash chips with different sizes from different manufacturers which have the same RES code. Can you post the RDID output for your device? Maybe we can figure out a way to identify it safely with the help of RDID and RES and possibly READ.
The RDID output was just FF FF FF, so I'm pretty sure it just doesn't recognize the command at all.
Good. That means we can probably use RDID in combination with RES to identify this special ST M25P40 variant.
How do you suppose the chip's identity could be deduced from a READ command?
You can read the contents of the chip and deduce a minimum size by analyzing repetitions. While it is possible to underestimate the size of the chip (in case 2^n identical images are behind each other), I can't see a way to overestimate chip size.
Would it perhaps not be wise to create a command-line switch to enable detection for chips like this, that might not be possible to auto-identify safely? The flashchip struct could be gifted with a pre-initialized boolean that indicates if a chip should be auto-identified without being explicitly specified.
Yes, a command line switch would probably work, but I'm currently working on a redesign of the SPI part of flashrom, so I'd like to delay that a bit. Details will be announced after Tuesday.
Some parts of your patch (except the modification of the ST_M25P40 #define and the flashchips.c changes) are definitely worth merging instantly, though. Could you split these parts from the patch and resend them with a Signed-off-by statement?
Regards, Carl-Daniel