On Sun, 7 Dec 2014 11:02:35 +0100 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
This flash chip can be configured (one time) to use 64 KiB or 256 KiB sectors. Additionally, in the 64 KiB mode it supports 16 4 KiB sub-sectors that can be (one time) programmed to be on the top or bottom of the device. The sub-sectors can be erased with the 0x20 opcode but because this opcode does not work with the remaining sectors and flashrom can not cope with that the 0x20 opcode is not supported yet.
This patch adds two definitions, one for the 64 KiB and 256 KiB configuration respectively. The device also shares the RDID with the various S25FL128 devices so we have to increase the maximum number of successfully probed chips to 8.
The 64 KiB mode was tested on real hardware.
Signed-off-by: Jernej Škrabec jernej.skrabec@planet.si Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
I have committed this patch in r1858 because Jernej told me that he *currently* is unable to test the patch on real hardware. Since the modifications were minor there shouldn't be any issues though.
On Sat, 20 Dec 2014 22:43:19 +0100 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
On Sun, 7 Dec 2014 11:02:35 +0100 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
This flash chip can be configured (one time) to use 64 KiB or 256 KiB sectors. Additionally, in the 64 KiB mode it supports 16 4 KiB sub-sectors that can be (one time) programmed to be on the top or bottom of the device. The sub-sectors can be erased with the 0x20 opcode but because this opcode does not work with the remaining sectors and flashrom can not cope with that the 0x20 opcode is not supported yet.
This patch adds two definitions, one for the 64 KiB and 256 KiB configuration respectively. The device also shares the RDID with the various S25FL128 devices so we have to increase the maximum number of successfully probed chips to 8.
The 64 KiB mode was tested on real hardware.
Signed-off-by: Jernej Škrabec jernej.skrabec@planet.si Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
I have committed this patch in r1858 because Jernej told me that he *currently* is unable to test the patch on real hardware. Since the modifications were minor there shouldn't be any issues though.
Hi Stefan!
Now I manage to test again and as you can see from attachments, everything is OK for 64 KiB version. However, I found out that chip definitions are duplicated:
S25FL127S-64KB, line 10503 S25FL127S-256kB, line 10536 S25FL127S-64kB, line 10569 S25FL127S-256kB, line 10613
I will also confirm 256 KiB version in the near future and maybe even write better probing function.
Best regards, Jernej Škrabec
Uh, there is no duplicated definitions, I forgot to revert my code, sorry.
Best regards, Jernej Škrabec
Hello Jernej,
thanks for your report!
On Wed, 14 Jan 2015 00:02:22 +0100 (CET) Jernej Škrabec jernej.skrabec@planet.si wrote:
Now I manage to test again and as you can see from attachments, everything is OK for 64 KiB version.
Can you please test probing without the -c parameter? That's much more important than the rest.
However, I found out that chip definitions are duplicated:
S25FL127S-64KB, line 10503 S25FL127S-256kB, line 10536 S25FL127S-64kB, line 10569 S25FL127S-256kB, line 10613
Those must be local modifications on your side. On r1868: $ grep -n S25FL127S flashchips.c 10505: .name = "S25FL127S-64kB", /* hybrid: 32 (top or bottom) 4 kB sub-sectors + 64 kB sectors */ 10549: .name = "S25FL127S-256kB", /* uniform 256kB sectors */
Hello Stefan,
here you have report without -c parameter. I also removed my local changes, so it should be correct.
You once said, that maybe another probe function should be written for this chip. Can you elaborate a bit? I take a look at datasheet and found out that actually almost every field in chip definition structure can be filled from SFDP data. Is this a way to go?
Best regards, Jernej Škrabec
On Wed, 14 Jan 2015 23:52:42 +0100 (CET) Jernej Škrabec jernej.skrabec@planet.si wrote:
Hello Stefan,
here you have report without -c parameter. I also removed my local changes, so it should be correct.
Thanks!
You once said, that maybe another probe function should be written for this chip. Can you elaborate a bit? I take a look at datasheet and found out that actually almost every field in chip definition structure can be filled from SFDP data. Is this a way to go?
I have been working on a complete probing rewrite. Some vendors share the 16b model RDID IDs between incompatible models, but provide other means to distinguish them. In the worst case we would have to issue a second probe opcode and derive the model from the second reply. Or we would have to look at the SFDP responses... (I don't remember what the solution for this series of Spansion chips is from the top of my head, but something similar). Relying completely on SFDP is a bad idea. While it is standardized in a way that flashrom can somewhat work with it (we do use it, if the chip is unknown but supports SFDP), the data in there is often not completely correct... and sometimes even completely bogus. Also, not too many chips support it.
So my plan for this model and all others is to probe not a single function but a number of them and compare the results. This is also important for systems where some opcodes are blocked by the system (e.g. many Intel-based boards).
-
Jernej Škrabec -
Stefan Tauner