Hi
i have a bricked router i was using as a test for my new ftdi cable and came across the message that flashrom posted out.
thought i would send you the chip details if it helps you expand the flashrom device support. The router fron Dlink uses a Linux kernel firmware and was bricked through the web interface UI update.
Anyway it is a ESMT F25L32PA c000x 1014. these are all the numbers on the flash chip.
On Thu, 27 Mar 2014 15:15:26 +0000 chris chriscooper@coopertronix.com wrote:
Hi
i have a bricked router i was using as a test for my new ftdi cable and came across the message that flashrom posted out.
thought i would send you the chip details if it helps you expand the flashrom device support. The router fron Dlink uses a Linux kernel firmware and was bricked through the web interface UI update.
Anyway it is a ESMT F25L32PA c000x 1014. these are all the numbers on the flash chip.
There are indeed a number of ESMT chips we do not support yet (mainly because they were not spotted in the wild so far). I have created a patch for your chip. Do you want to test it?
Hi Stefan
Yes please, i would be glad and honoured to test it.
Thank you.
On 05/01/2014 10:32 AM, Stefan Tauner wrote:
On Thu, 27 Mar 2014 15:15:26 +0000 chris chriscooper@coopertronix.com wrote:
Hi
i have a bricked router i was using as a test for my new ftdi cable and came across the message that flashrom posted out.
thought i would send you the chip details if it helps you expand the flashrom device support. The router fron Dlink uses a Linux kernel firmware and was bricked through the web interface UI update.
Anyway it is a ESMT F25L32PA c000x 1014. these are all the numbers on the flash chip.
There are indeed a number of ESMT chips we do not support yet (mainly because they were not spotted in the wild so far). I have created a patch for your chip. Do you want to test it?
Hello Chris,
sorry it took a while *again*. I wanted to integrate all the other small changes to flashchips.c due to the pileup of reports in the last months. But they are too many so I have created the patch on top of the last committed state, i.e. r1782.
The attached patch should apply cleanly to said revision which is easily obtainable and buildable, see http://flashrom.org/Downloads#Installation_from_source
It should just work. Please report back with the flashrom log of a write operation that actually does change the content of the chip (i.e. which writes an image different to the existing data on the chip), e.g. flashrom -p ft2232_spi... -w <filename> -o F25L32PA-write.log Thanks!
On Sat, 3 May 2014 12:24:28 +0200 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
Hello Chris,
sorry it took a while *again*. I wanted to integrate all the other small changes to flashchips.c due to the pileup of reports in the last months. But they are too many so I have created the patch on top of the last committed state, i.e. r1782.
The attached patch should apply cleanly to said revision which is easily obtainable and buildable, see http://flashrom.org/Downloads#Installation_from_source
It should just work. Please report back with the flashrom log of a write operation that actually does change the content of the chip (i.e. which writes an image different to the existing data on the chip), e.g. flashrom -p ft2232_spi... -w <filename> -o F25L32PA-write.log Thanks!
Hi Chris,
I have committed the patch now without your testing in r1801. If you have tested it already or will test it in the future, please report back, thanks.
Hi Stefan
Sorry i did not get back to you sooner. I have been really busy lately but i did briefly try the patch against the latest source 0.9.7 but the patch failed to apply.
I did not have much time to look into it too deeply but the files it failed to apply to were chipdrivers.h and flashchips.h
All the c files patched successfully it was just the header files that had failed.
I manually edited the header files to apply the failed errors on the patching. Built the new version of code and tried it against the flash rom.
I have attached the two log files. It looks like the spi flash chip maybe different in size than 4096
I have tried to write the dlink rom image downloaded from their website and also run a erase on the chip both logs are attached.
Sorry for the delay, the patch failed and i new i had to debug it and ran out of time as i had to run off to do some work. i finally got back to it.
The patch fails on the chipdrivers.h because "void spi_prettyprint_status_register_bit(uint8_t status, int bit);" does not exist in the source files.
flashchips.h has the similar problem so i manually inserted the #define chip ID for the F25L32PA.
This is the patching output from the terminal.
patching file chipdrivers.h Hunk #1 FAILED at 39. 1 out of 1 hunk FAILED -- saving rejects to file chipdrivers.h.rej patching file flashchips.c Hunk #1 succeeded at 2830 (offset -256 lines). patching file flashchips.h Hunk #1 FAILED at 176. 1 out of 1 hunk FAILED -- saving rejects to file flashchips.h.rej patching file spi25_statusreg.c patch unexpectedly ends in middle of line Hunk #1 succeeded at 322 with fuzz 1.
Thanks
On 05/27/2014 10:26 PM, Stefan Tauner wrote:
On Sat, 3 May 2014 12:24:28 +0200 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
Hello Chris,
sorry it took a while *again*. I wanted to integrate all the other small changes to flashchips.c due to the pileup of reports in the last months. But they are too many so I have created the patch on top of the last committed state, i.e. r1782.
The attached patch should apply cleanly to said revision which is easily obtainable and buildable, see http://flashrom.org/Downloads#Installation_from_source
It should just work. Please report back with the flashrom log of a write operation that actually does change the content of the chip (i.e. which writes an image different to the existing data on the chip), e.g. flashrom -p ft2232_spi... -w <filename> -o F25L32PA-write.log Thanks!
Hi Chris,
I have committed the patch now without your testing in r1801. If you have tested it already or will test it in the future, please report back, thanks.
Hi,
the failed patch attempts are probably because you tried to apply it to a different version than r1782. Since I have committed the patch now anyway this should be no issue anymore anyway for your testing.
But you got a more severe problem. The logs you sent show that the flash chip does not always react to the commands flashrom sends to it. All lines in the logs containing 'probe_spi_rdid_generic' should end with 'probe_spi_rdid_generic: id1 0x8c, id2 0x2016' but quite often flashrom reads a constant 'high' (0xFF...) instead of the correct IDs. This might be due to bad cabling or something else interfering on the SPI bus (e.g. the router SoC might be powered through your programmer and tries to fetch its bootcode from the flash). You could work around the latter by lifting the VCC pin of the flash chip from the board (unsoldering it) or holding the SoC in reset somehow. See also http://flashrom.org/ISP
-
C Cooper -
chris
-
Stefan Tauner