EN25Q128 (Thomson TG582n router) flash problem?

[Adrian Graham]

Hi,

I'm trying to re-flash this 16mb chip with the original contents I dumped
before attempting to flash a new bootloader for OpenWRT installation, all
the flashing of various CFE bootloaders was successful and the last erase I
did was also successful. However this happens when I try to re-flash:

pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0 -c"EN25Q128" -w
EN25Q128_flash.bin --verbose
flashrom v0.9.8-r1888 on Linux 4.1.18-v7+ (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org

flashrom was built with libpci 3.2.1, GCC 4.9.2, little endian
Command line (6 args): flashrom -p linux_spi:dev=/dev/spidev0.0 -cEN25Q128
-w EN25Q128_flash.bin --verbose
Calibrating delay loop... OS timer resolution is 3 usecs, 297M loops per
second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1011 us, 10000 myus
= 10067 us, 12 myus = 13 us, OK.
Initializing linux_spi programmer
Using device /dev/spidev0.0
The following protocols are supported: SPI.
Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x1c, id2
0x3018
Found Eon flash chip "EN25Q128" (16384 kB, SPI) on linux_spi.
Chip status register is 0x00.
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
===
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 [e-mail] if any of the above
operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and
mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0...
0x000000-0x000fff:W, 0x001000-0x001fff:W, 0x002000-0x002fff:S,
0x003000-0x003fff:W, 0x004000-0x004fff:W, 0x005000-0x005fff:W,
0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S,
0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:W,
.
.
.
{Snip}
.
.
.
0xff3000-0xff3fff:S, 0xff4000-0xff4fff:S, 0xff5000-0xff5fff:S,
0xff6000-0xff6fff:S, 0xff7000-0xff7fff:S, 0xff8000-0xff8fff:S,
0xff9000-0xff9fff:S, 0xffa000-0xffafff:S, 0xffb000-0xffbfff:S,
0xffc000-0xffcfff:S, 0xffd000-0xffdfff:S, 0xffe000-0xffefff:S,
0xfff000-0xffffff:S
Erase/write done.
Verifying flash... FAILED at 0x0019f8d1! Expected=0x92, Found=0x85, failed
byte count from 0x00000000-0x00ffffff: 0x898
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail [e-mail], thanks!
pi@raspberrypi ~ $

This is version 0.9.8 if you guys are still out there.

Thanks!

[Stefan Tauner]

On Thu, 10 Mar 2016 00:27:13 +0000
Adrian Graham  wrote:
> Hi,
>
> I'm trying to re-flash this 16mb chip with the original contents I dumped
> before attempting to flash a new bootloader for OpenWRT installation, all
> the flashing of various CFE bootloaders was successful and the last erase I
> did was also successful. However this happens when I try to re-flash:
>
> pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0 -c"EN25Q128" -w
> EN25Q128_flash.bin --verbose
> flashrom v0.9.8-r1888 on Linux 4.1.18-v7+ (armv7l)
> flashrom is free software, get the source code at http://www.flashrom.org
>
> flashrom was built with libpci 3.2.1, GCC 4.9.2, little endian
> Command line (6 args): flashrom -p linux_spi:dev=/dev/spidev0.0 -cEN25Q128
> -w EN25Q128_flash.bin --verbose
> Calibrating delay loop... OS timer resolution is 3 usecs, 297M loops per
> second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1011 us, 10000 myus
> = 10067 us, 12 myus = 13 us, OK.
> Initializing linux_spi programmer
> Using device /dev/spidev0.0
> The following protocols are supported: SPI.
> Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x1c, id2
> 0x3018
> Found Eon flash chip "EN25Q128" (16384 kB, SPI) on linux_spi.
> Chip status register is 0x00.
> This chip may contain one-time programmable memory. flashrom cannot read
> and may never be able to write it, hence it may not be able to completely
> clone the contents of this chip (see man page for details).
> ===
> 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 [e-mail] if any of the above
> operations
> work correctly for you with this flash chip. Please include the flashrom log
> file for all operations you tested (see the man page for details), and
> mention
> which mainboard or programmer you tested in the subject line.
> Thanks for your help!
> Reading old flash chip contents... done.
> Erasing and writing flash chip... Trying erase function 0...
> 0x000000-0x000fff:W, 0x001000-0x001fff:W, 0x002000-0x002fff:S,
> 0x003000-0x003fff:W, 0x004000-0x004fff:W, 0x005000-0x005fff:W,
> 0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S,
> 0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:W,
> .
> .
> .
> {Snip}
> .
> .
> .
> 0xff3000-0xff3fff:S, 0xff4000-0xff4fff:S, 0xff5000-0xff5fff:S,
> 0xff6000-0xff6fff:S, 0xff7000-0xff7fff:S, 0xff8000-0xff8fff:S,
> 0xff9000-0xff9fff:S, 0xffa000-0xffafff:S, 0xffb000-0xffbfff:S,
> 0xffc000-0xffcfff:S, 0xffd000-0xffdfff:S, 0xffe000-0xffefff:S,
> 0xfff000-0xffffff:S
> Erase/write done.
> Verifying flash... FAILED at 0x0019f8d1! Expected=0x92, Found=0x85, failed
> byte count from 0x00000000-0x00ffffff: 0x898
> Your flash chip is in an unknown state.
> Please report this on IRC at chat.freenode.net (channel #flashrom) or
> mail [e-mail], thanks!
> pi@raspberrypi ~ $
>
> This is version 0.9.8 if you guys are still out there.

Hello Adrian,

I can not offer a certain explanation for the behaviour you are seeing.
However, it looks like the communication between the programmer and the
flash chip is not as stable as needed. The last FAILED message
indicates that of the 16 Million bytes written only about 2000 failed.
That's not nothing but might not show up easily when just probing for
chips and might be undetected during reads as well (e.g. by comparing
multiple reads manually).

If you were on IRC a few days ago then you know the following links
already, but in any case there is not much else to offer you at this
time:
https://www.flashrom.org/Common_problems
https://www.flashrom.org/ISP

[Adrian Graham]

On 12/03/2016 14:59, "Stefan Tauner" 
wrote:
> On Thu, 10 Mar 2016 00:27:13 +0000
> Adrian Graham  wrote:
> > Verifying flash... FAILED at 0x0019f8d1! Expected=0x92, Found=0x85, failed
> > byte count from 0x00000000-0x00ffffff: 0x898
> > Your flash chip is in an unknown state.
> > Please report this on IRC at chat.freenode.net (channel #flashrom) or
> > mail [e-mail], thanks!
> > pi@raspberrypi ~ $
> >
> > This is version 0.9.8 if you guys are still out there.
>
> Hello Adrian,
>
> I can not offer a certain explanation for the behaviour you are seeing.
> However, it looks like the communication between the programmer and the
> flash chip is not as stable as needed. The last FAILED message
> indicates that of the 16 Million bytes written only about 2000 failed.
> That's not nothing but might not show up easily when just probing for
> chips and might be undetected during reads as well (e.g. by comparing
> multiple reads manually).
>
> If you were on IRC a few days ago then you know the following links
> already, but in any case there is not much else to offer you at this
> time:
> https://www.flashrom.org/Common_problems
> https://www.flashrom.org/ISP

Hi Stefan,

Thanks for replying! I actually found out the reason for the discrepancy by
accident last week - that flash has an OTP section that's locked so the 2k
that's unavailable will be down to that. Reflashing and reconnecting
everything got me going again so I'm now chasing down a CFE bootloader for
the BCM6328 chip in this router :)

Cheers!

[Stefan Tauner]

On Sat, 12 Mar 2016 15:31:27 +0000
Adrian Graham  wrote:
> Thanks for replying! I actually found out the reason for the discrepancy by
> accident last week - that flash has an OTP section that's locked so the 2k
> that's unavailable will be down to that. Reflashing and reconnecting
> everything got me going again so I'm now chasing down a CFE bootloader for
> the BCM6328 chip in this router :)

The OTP memory is separate to the ordinary 16 MB flash memory and
cannot produce these results. It is also only 512 bytes in size
according to the data sheet in the (current) revision E of the EN25Q128.

So you did eventually write the full chip with flashrom and receive a
VERIFIED message at the end? If you still have a log file of that
please post it, thanks.

[Adrian Graham]

On 12/03/2016 15:46, "Stefan Tauner" 
wrote:
> On Sat, 12 Mar 2016 15:31:27 +0000
> Adrian Graham  wrote:
> > Thanks for replying! I actually found out the reason for the discrepancy by
> > accident last week - that flash has an OTP section that's locked so the 2k
> > that's unavailable will be down to that. Reflashing and reconnecting
> > everything got me going again so I'm now chasing down a CFE bootloader for
> > the BCM6328 chip in this router :)
>
> The OTP memory is separate to the ordinary 16 MB flash memory and
> cannot produce these results. It is also only 512 bytes in size
> according to the data sheet in the (current) revision E of the EN25Q128.
>
> So you did eventually write the full chip with flashrom and receive a
> VERIFIED message at the end? If you still have a log file of that
> please post it, thanks.

Ah, OK. In that case I don't know why it didn't finish writing then, unless
my temporary connections between RasPi and flash moved a little bit or just
aren't tight enough for a good signal. Cable length maybe - signal path is
RasPi -> 40pin IDE cable -> hookup wires (15cm) soldered to the pads on the
chip. Now that I've got more female-female jumper wires I can go direct to
the Pi to shorten the distance drastically.

Currently I've got the flash hooked up to a parallel port on an old desktop
so I can use SPIPGMW which has just dumped the whole 16mb to disk so I can
try writing it back to see if it fails indicating a bad area in flash.

Cheers,

[Stefan Tauner]

On Sat, 12 Mar 2016 16:08:54 +0000
Adrian Graham  wrote:
> On 12/03/2016 15:46, "Stefan Tauner" 
> wrote:
>
> Ah, OK. In that case I don't know why it didn't finish writing then, unless
> my temporary connections between RasPi and flash moved a little bit or just
> aren't tight enough for a good signal. Cable length maybe - signal path is
> RasPi -> 40pin IDE cable -> hookup wires (15cm) soldered to the pads on the
> chip. Now that I've got more female-female jumper wires I can go direct to
> the Pi to shorten the distance drastically.

That makes a huge difference for the quality of the signals :)
> Currently I've got the flash hooked up to a parallel port on an old desktop
> so I can use SPIPGMW which has just dumped the whole 16mb to disk so I can
> try writing it back to see if it fails indicating a bad area in flash.

That will be quite slow, but in any case please report back with a
complete verbose log (-o write.txt creates one easily).

[Adrian Graham]

On 12/03/2016 16:27, "Stefan Tauner" 
wrote:
> On Sat, 12 Mar 2016 16:08:54 +0000
> Adrian Graham  wrote:
> > On 12/03/2016 15:46, "Stefan Tauner" 
> > wrote:
> >
> > Ah, OK. In that case I don't know why it didn't finish writing then, unless
> > my temporary connections between RasPi and flash moved a little bit or just
> > aren't tight enough for a good signal. Cable length maybe - signal path is
> > RasPi -> 40pin IDE cable -> hookup wires (15cm) soldered to the pads on the
> > chip. Now that I've got more female-female jumper wires I can go direct to
> > the Pi to shorten the distance drastically.
>
> That makes a huge difference for the quality of the signals :)

Just hooking up now.
> > Currently I've got the flash hooked up to a parallel port on an old desktop
> > so I can use SPIPGMW which has just dumped the whole 16mb to disk so I can
> > try writing it back to see if it fails indicating a bad area in flash.
>
> That will be quite slow, but in any case please report back with a
> complete verbose log (-o write.txt creates one easily).

Interestingly SPIPGMW wrote back all 16mb without complaining but the board
doesn't boot at all so once I've got the Pi writing again I'll let you know
what happens.

[Adrian Graham]

On 12/03/2016 16:27, "Stefan Tauner" 
wrote:
> On Sat, 12 Mar 2016 16:08:54 +0000
> Adrian Graham  wrote:
> > On 12/03/2016 15:46, "Stefan Tauner" 
> > wrote:
> >
> > Ah, OK. In that case I don't know why it didn't finish writing then, unless
> > my temporary connections between RasPi and flash moved a little bit or just
> > aren't tight enough for a good signal. Cable length maybe - signal path is
> > RasPi -> 40pin IDE cable -> hookup wires (15cm) soldered to the pads on the
> > chip. Now that I've got more female-female jumper wires I can go direct to
> > the Pi to shorten the distance drastically.
>
> That makes a huge difference for the quality of the signals :)

Certainly does - it worked this time with a much shorter signal path! Do you
still want a verbose dump of the writing?

Still stumped on the bootloader though, even a generic tg582n won't boot.
Odd.

[Stefan Tauner]

On Sat, 12 Mar 2016 17:31:39 +0000
Adrian Graham  wrote:
> On 12/03/2016 16:27, "Stefan Tauner" 
> wrote:
> > On Sat, 12 Mar 2016 16:08:54 +0000
> > Adrian Graham  wrote:
> > > On 12/03/2016 15:46, "Stefan Tauner" 
> > > wrote:
> > >
> > > Ah, OK. In that case I don't know why it didn't finish writing then, unless
> > > my temporary connections between RasPi and flash moved a little bit or just
> > > aren't tight enough for a good signal. Cable length maybe - signal path is
> > > RasPi -> 40pin IDE cable -> hookup wires (15cm) soldered to the pads on the
> > > chip. Now that I've got more female-female jumper wires I can go direct to
> > > the Pi to shorten the distance drastically.
> >
> > That makes a huge difference for the quality of the signals :)
>
> Certainly does - it worked this time with a much shorter signal path! Do you
> still want a verbose dump of the writing?

Yes, please. I'll just want to make sure that we set the status of the
chip correctly and you did not miss anything.
> Still stumped on the bootloader though, even a generic tg582n won't boot.
> Odd.

Probably not flashrom's fault... flashrom does not care about the
content of the files you feed it. I fear I can't help with the
tg582n/bootloader problem itself, sorry.

[Adrian Graham]

On 12/03/2016 17:47, "Stefan Tauner" 
wrote:
> > Certainly does - it worked this time with a much shorter signal path! Do you
> > still want a verbose dump of the writing?
>
> Yes, please. I'll just want to make sure that we set the status of the
> chip correctly and you did not miss anything.

There you go, included as an attachment. Nice to see it work when I actually
set things up properly, heh.
> > Still stumped on the bootloader though, even a generic tg582n won't boot.
> > Odd.
>
> Probably not flashrom's fault... flashrom does not care about the
> content of the files you feed it. I fear I can't help with the
> tg582n/bootloader problem itself, sorry.

Nope, definitely not flashrom's fault. I only mentioned it just in case you
had a sudden thought and said "Yes! You need to do ..." but no worries :)

Cheers,