Re: [flashrom] FAILED: Adlink NanoX-TC

[Carl-Daniel Hailfinger]

Hi Ricardo,

your log is weird in a way I've never seen before. Details below.

Am 13.08.2014 21:24 schrieb Ricardo Menzer:
> I have also found that if I probe the chip three times, it will work
> only once. I mean, if I probe for the chip and it is found, the next
> two probes will fail. The third will work, and the next two will fail
> again, and so on.
> I'm attaching the logs for three consecutive probes and also the
> output of lspci -vvxxxnn.
>
> Ricardo Menzer
> [e-mail]
> (32)8865-8805
>
> 2014-08-13 12:15 GMT-03:00 Ricardo Menzer :
> > > Hi guys!
> > > I'm working with this COM Express module from Adlink
> > > (http://www.adlinktech.com/PD/web/PD_detail.php?cKind=&pid=1001&seq=&...)
> > > and sometimes it doesn't recognize it's flash chip.
> > > The following log happened after a failed probing. I then let the
> > > board resting some time and tried to program again, with the results
> > > bellow.
> > >
> > > This is a quite problematic module. Frequently it fails to probe the
> > > flash chip. I have to reboot the system so it can see it again. It
> > > also seems to corrupt the module flash even if I select to write to
> > > the baseboard flash. I don't know if it's a flashrom issue or a
> > > bios/hardware issue.
> > >
> > > I can safely reboot the system because we have a second flash on the baseboard.
> > >
> > > Right now I am using the module's flash to play with coreboot and i'm
> > > maintaining a copy of the original BIOS on the baseboard. Changing the
> > > role of both chips doesn't seem to change much, except for the
> > > corruption issue (didn't made much tests yet, though).
> > >
> > > I have a Kontron module that I use in this same base board and it
> > > works pretty well.
> > >
> > > 14:55:12 root ~ # flashrom-0.9.7/flashrom -p internal -w
> > > /media/sda1/coreboot.rom
> > > flashrom v0.9.7-r1711 on Linux 3.10.38-ltsi-yocto-standard (i686)
> > > flashrom is free software, get the source code at http://www.flashrom.org
> > >
> > > Calibrating delay loop... OK.
> > > sh: dmidecode: command not found
> > > dmidecode execution unsuccessful - continuing without DMI info
> > > Warning: Can't autodetect MSC Q7-TCTC, DMI info unavailable.
> > > Please supply the board vendor and model name with the -p
> > > internal:mainboard=<vendor>:<model> option.
> > > Found chipset "Intel Atom E6xx(T)/Tunnel Creek". Enabling flash write... OK.
> > > Found SST flash chip "SST25VF016B" (2048 kB, SPI) at physical address
> > > 0xffe00000.
> > > Reading old flash chip contents... done.
> > > Erasing and writing flash chip... timeout, ICH7_REG_SPIS=0x0001
> > > spi_block_erase_20 failed during command execution at address 0x0
> > > Reading current flash chip contents... Error: SCIP never cleared!
> > > Can't read anymore! Aborting.
> > > FAILED!
> > > Uh oh. Erase/write failed. Checking if anything changed.
> > > Error: SCIP never cleared!
> > > Your flash chip is in an unknown state.
> > > Get help on IRC at chat.freenode.net (channel #flashrom) or
> > > mail [e-mail] with the subject "FAILED: <your board name>"!
> > >
> > > DO NOT REBOOT OR POWEROFF!
> > > 14:56:28 root ~ # flashrom-0.9.7/flashrom -p internal -w
> > > /media/sda1/coreboot.rom
> > > flashrom v0.9.7-r1711 on Linux 3.10.38-ltsi-yocto-standard (i686)
> > > flashrom is free software, get the source code at http://www.flashrom.org
> > >
> > > Calibrating delay loop... OK.
> > > sh: dmidecode: command not found
> > > dmidecode execution unsuccessful - continuing without DMI info
> > > Warning: Can't autodetect MSC Q7-TCTC, DMI info unavailable.
> > > Please supply the board vendor and model name with the -p
> > > internal:mainboard=<vendor>:<model> option.
> > > Found chipset "Intel Atom E6xx(T)/Tunnel Creek". Enabling flash write... OK.
> > > Error: SCIP never cleared!
> > > Error: SCIP never cleared!
>
> flash1.log
> flashrom v0.9.7-r1711 on Linux 3.10.38-ltsi-yocto-standard (i686)
> flashrom is free software, get the source code at http://www.flashrom.org
>
> flashrom was built with libpci 3.2.0, GCC 4.8.2, little endian
> Command line (3 args): /home/root/flashrom-0.9.7/flashrom -p internal -V
> Calibrating delay loop... OS timer resolution is 4 usecs, 292M loops per second, 10 myus = 13 us, 100 myus = 101 us, 1000 myus = 1016 us, 10000 myus = 10057 us, 16 myus = 19 us, OK.
> Initializing internal programmer
> No coreboot table found.
> Found Winbond Super I/O, id 0x52
> Please supply the board vendor and model name with the -p internal:mainboard=<vendor>:<model> option.
> Found chipset "Intel Atom E6xx(T)/Tunnel Creek" with PCI ID 8086:8186. Enabling flash write... 
> BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
> BIOS Prefetch Enable: disabled, 
> Root Complex Register Block address = 0xfed1c000
> SPIBAR = 0xfed1c000 + 0x3020
> 0x00: 0x0004     (SPIS)
> 0x02: 0x41c0     (SPIC)
> 0x04: 0x00000000 (SPIA)
> 0x08: 0x41414125 (SPID0)
> 0x0c: 0x00000000 (SPID0+4)
> 0x10: 0x00000000 (SPID1)
> 0x14: 0x00000000 (SPID1+4)
> 0x18: 0x00000000 (SPID2)
> 0x1c: 0x00000000 (SPID2+4)
> 0x20: 0x00000000 (SPID3)
> 0x24: 0x00000000 (SPID3+4)
> 0x28: 0x00000000 (SPID4)
> 0x2c: 0x00000000 (SPID4+4)
> 0x30: 0x00000000 (SPID5)
> 0x34: 0x00000000 (SPID5+4)
> 0x38: 0x00000000 (SPID6)
> 0x3c: 0x00000000 (SPID6+4)
> 0x40: 0x00000000 (SPID7)
> 0x44: 0x00000000 (SPID7+4)
> 0x50: 0x00000000 (BBAR)
> 0x54: 0x5006     (PREOP)
> 0x56: 0x063b     (OPTYPE)
> 0x58: 0x05200302 (OPMENU)
> 0x5c: 0x0050019f (OPMENU+4)
> 0x60: 0x00000000 (PBR0)
> 0x64: 0x00000000 (PBR1)
> 0x68: 0x00000000 (PBR2)
> Programming OPCODES... done
> SPI Read Configuration: prefetching disabled, caching enabled, OK.
> The following protocols are supported: Parallel, LPC, FWH, SPI.
> Probing for AMIC A25L05PT, 64 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x41, id2 0xbf25
> Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0x25, id2 0x41bf
> Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0xbf, id2 0x2541
> Probing for AMIC A25L10PU, 128 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x41, id2 0xbf25
> Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0x25, id2 0x41bf
> Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0xbf, id2 0x2541
> Probing for AMIC A25L40PT, 512 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x41, id2 0xbf25
> Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0x25, id2 0x41bf
> Probing for AMIC A25L80P, 1024 kB: probe_spi_rdid_generic: id1 0xbf, id2 0x2541
> Probing for AMIC A25L16PT, 2048 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x41, id2 0xbf25
> Probing for AMIC A25L16PU, 2048 kB: probe_spi_rdid_generic: id1 0x25, id2 0x41bf
> Probing for AMIC A25L512, 64 kB: probe_spi_rdid_generic: id1 0xbf, id2 0x2541
> Probing for AMIC A25L010, 128 kB: probe_spi_rdid_generic: id1 0x25, id2 0x41bf
> Probing for AMIC A25L020, 256 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x41, id2 0xbf25

As you can see, the chip continuously outputs 0xbf 0x25 0x41 in an
endless loop. Normally, the SST SST25VF016B chip should always return
the same ID response to probe_spi_rdid_generic: id1 0xbf, id2 0x2541.
However, your chip seems to be cycling through shifted variants of that
response.
This indicates the chip never leaves ID (read JEDEC ID with command
0x9f) mode, probably because the CE# (chip enable) line is stuck on low.
I've never seen that happen before, and it's certainly really weird. Do
you have a multimeter to confirm that the CE# pin of the flash chip is
indeed continuously at 0V?
The Intel Tunnel Creek chipset may be at fault, or some other weird
component is screwing things up.

Two things I'd like you to try:
- Compile latest flashrom from source, reboot and then write a log file
with the new flashrom using -o logfile.txt . It needs to be the first
run after the reboot or we'll get mostly random results.
- Put an oscilloscope on the CE# line and check if it ever goes to high
(3.3V) again after a flashrom run.

Regards,
Carl-Daniel

FAILED: Adlink NanoX-TC

[Ricardo Menzer]

Thanks for your help!
Answers inline below.

Ricardo Menzer
[e-mail]
(32)8865-8805

On Wed, Aug 13, 2014 at 8:16 PM, Carl-Daniel Hailfinger
 wrote:
> Hi Ricardo,
>
> your log is weird in a way I've never seen before. Details below.
>
> Am 13.08.2014 21:24 schrieb Ricardo Menzer:
> > I have also found that if I probe the chip three times, it will work
> As you can see, the chip continuously outputs 0xbf 0x25 0x41 in an
> endless loop. Normally, the SST SST25VF016B chip should always return
> the same ID response to probe_spi_rdid_generic: id1 0xbf, id2 0x2541.
> However, your chip seems to be cycling through shifted variants of that
> response.
> This indicates the chip never leaves ID (read JEDEC ID with command
> 0x9f) mode, probably because the CE# (chip enable) line is stuck on low.
> I've never seen that happen before, and it's certainly really weird. Do
> you have a multimeter to confirm that the CE# pin of the flash chip is
> indeed continuously at 0V?

The line is not stuck at a specific level. I got a logic analyzer and
I can see the level changing from 0 to 1 and vice-versa.
> The Intel Tunnel Creek chipset may be at fault, or some other weird
> component is screwing things up.
>
> Two things I'd like you to try:
> Compile latest flashrom from source, reboot and then write a log file
>
> with the new flashrom using -o logfile.txt . It needs to be the first
> run after the reboot or we'll get mostly random results.

I'll do that. It's not a scientific experiment, but I have the feeling
that, indeed, reading/writing chips work better right after a reboot,
instead of after using the system for a while.
> Put an oscilloscope on the CE# line and check if it ever goes to high
>
> (3.3V) again after a flashrom run.

Used a Saleae Logic Analyzer. All four lines are changing levels. I
have two problems now:
First, when I attach the logic analyzer to the chip, and run flashrom
in verify mode, it show differences between the flash and its image on
disk. Obviously, the analyzer is interfering in the SPI lines
sufficiently to cause read errors. When I remove the analyzer, the
verification process finishes fine, even with the probes/wires
connected. (implicit question: is there a parameter to set SPI
frequency for the internal programmer?)

Second, all read/write operations I made today worked! I was hoping to
see what's going wrong on the bus with the logic analyzer. As soon it
starts to fail again I'll try to do that.
> Regards,
> Carl-Daniel