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 ricardomenzer@gmail.com (32)8865-8805
2014-08-13 12:15 GMT-03:00 Ricardo Menzer ricardomenzer@gmail.com:
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 flashrom@flashrom.org 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