flashrom July 2009

flashrom@flashrom.org

23 participants
93 discussions

flashrom status for GA-MA790X-UD4
by Yann Droneaud 23 Jul '09

23 Jul '09

Hi, Flashrom seems to not support Gigabyte GA-MA790X-UD4. I've only tested read operation, which failed, so I did try the write operation. Here are messages from flashrom: flashrom v0.9.0-r643 No coreboot table found. Found chipset "AMD SB700", enabling flash write... OK. This chipset supports the following protocols: LPC,FWH,SPI. Found board "GIGABYTE GA-MA78GM-S2H", enabling flash write... FAILED! Calibrating delay loop... OK. Found chip "SST unknown SST SPI chip" (0 KB, SPI) at physical address 0x100000000. If you need details, you can downloads flashrom -V, dmidecode, lspci outputs at: https://mais.quest-ce.net/flashrom/ga-ma790x-ud4/ output_dmidecode.txt.gz output_flashrom_V.txt.gz output_flashrom_rV.txt.gz output_lspci.txt.gz output_lspci_vvvxxx.txt.gz Regards. -- Yann Droneaud <yann(a)droneaud.fr>

2 5

chipset Intel ICH2-M eeprom read works
by David Thornton 23 Jul '09

23 Jul '09

Hi, I tested flashrom on a previously untested eeprom flash chip in my laptop; it said to tell you guys so here is the output! gotta love TheCrapTop TheCrapTop:/tmp# flashrom -r bios Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH2-M", enabling flash write... OK. Found chip "Intel 82802AC" (1024 KB) at physical address 0xfff00000. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flashrom(a)coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Reading Flash...done TheCrapTop:/tmp# du bios 1028 bios

2 1

Re: [flashrom] report "SST SST25VF080B"
by Carl-Daniel Hailfinger 23 Jul '09

23 Jul '09

Hi Cédric, thanks for your report. The flash chip status has been updated. Unfortunately, it seems your BIOS readout is not 100% complete due to chipset restrictions. Please do not try to write. Laptops are very difficult to recover if something goes wrong. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

[PATCH] Fix erase for SST49LF020A
by Carl-Daniel Hailfinger 22 Jul '09

22 Jul '09

Fix erase for SST49LF020A. The chip supports multiple erase functions, but the function we use has an eraseblock size of 4k. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-sst49lf020a/flashchips.c =================================================================== --- flashrom-sst49lf020a/flashchips.c (Revision 659) +++ flashrom-sst49lf020a/flashchips.c (Arbeitskopie) @@ -2160,7 +2160,7 @@ .manufacture_id = SST_ID, .model_id = SST_49LF020A, .total_size = 256, - .page_size = 16 * 1024, + .page_size = 4 * 1024, .tested = TEST_UNTESTED, .probe = probe_jedec, .probe_timing = 1, /* 150 ns */ -- http://www.hailfinger.org/

2 2

[commit] r664 - trunk
by svn＠flashrom.org 22 Jul '09

22 Jul '09

Author: hailfinger Date: 2009-07-23 03:44:38 +0200 (Thu, 23 Jul 2009) New Revision: 664 Modified: trunk/flashchips.c Log: Fix erase for SST49LF020A. The chip supports multiple erase functions, but the function we use has an eraseblock size of 4k. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/flashchips.c =================================================================== --- trunk/flashchips.c 2009-07-23 01:42:56 UTC (rev 663) +++ trunk/flashchips.c 2009-07-23 01:44:38 UTC (rev 664) @@ -2160,7 +2160,7 @@ .manufacture_id = SST_ID, .model_id = SST_49LF020A, .total_size = 256, - .page_size = 16 * 1024, + .page_size = 4 * 1024, .tested = TEST_UNTESTED, .probe = probe_jedec, .probe_timing = 1, /* 150 ns */

1 0

[PATCH] Continue verifying after first error
by Carl-Daniel Hailfinger 22 Jul '09

22 Jul '09

Continue erase/write verification after the first error. The first error is printed in detail and all subsequent errors are listed in statistics. This allows users to check if there was just one error or if the failure was widespread. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-verify_keep_going/flashrom.c =================================================================== --- flashrom-verify_keep_going/flashrom.c (Revision 659) +++ flashrom-verify_keep_going/flashrom.c (Arbeitskopie) @@ -278,6 +278,7 @@ int i, j, starthere, lenhere, ret = 0; int page_size = flash->page_size; uint8_t *readbuf = malloc(page_size); + int failcount = 0; if (!len) goto out_free; @@ -318,15 +319,21 @@ flash->read(flash, readbuf, starthere, lenhere); for (j = 0; j < lenhere; j++) { if (cmpbuf[starthere - start + j] != readbuf[j]) { - fprintf(stderr, "%s FAILED at 0x%08x! " - "Expected=0x%02x, Read=0x%02x\n", - message, starthere + j, - cmpbuf[starthere - start + j], readbuf[j]); - ret = -1; - goto out_free; + /* Only print the first failure. */ + if (!failcount++) + fprintf(stderr, "%s FAILED at 0x%08x! " + "Expected=0x%02x, Read=0x%02x,", + message, starthere + j, + cmpbuf[starthere - start + j], + readbuf[j]); } } } + if (failcount) { + fprintf(stderr, " failed byte count from 0x%08x-0x%08x: 0x%x\n", + start, start + len - 1, failcount); + ret = -1; + } out_free: free(readbuf); -- http://www.hailfinger.org/

2 2

[commit] r663 - trunk
by svn＠flashrom.org 22 Jul '09

22 Jul '09

Author: hailfinger Date: 2009-07-23 03:42:56 +0200 (Thu, 23 Jul 2009) New Revision: 663 Modified: trunk/flashrom.c Log: Continue erase/write verification after the first error. The first error is printed in detail and all subsequent errors are listed in statistics. This allows users to check if there was just one error or if the failure was widespread. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/flashrom.c =================================================================== --- trunk/flashrom.c 2009-07-23 01:40:20 UTC (rev 662) +++ trunk/flashrom.c 2009-07-23 01:42:56 UTC (rev 663) @@ -278,6 +278,7 @@ int i, j, starthere, lenhere, ret = 0; int page_size = flash->page_size; uint8_t *readbuf = malloc(page_size); + int failcount = 0; if (!len) goto out_free; @@ -318,15 +319,21 @@ flash->read(flash, readbuf, starthere, lenhere); for (j = 0; j < lenhere; j++) { if (cmpbuf[starthere - start + j] != readbuf[j]) { - fprintf(stderr, "%s FAILED at 0x%08x! " - "Expected=0x%02x, Read=0x%02x\n", - message, starthere + j, - cmpbuf[starthere - start + j], readbuf[j]); - ret = -1; - goto out_free; + /* Only print the first failure. */ + if (!failcount++) + fprintf(stderr, "%s FAILED at 0x%08x! " + "Expected=0x%02x, Read=0x%02x,", + message, starthere + j, + cmpbuf[starthere - start + j], + readbuf[j]); } } } + if (failcount) { + fprintf(stderr, " failed byte count from 0x%08x-0x%08x: 0x%x\n", + start, start + len - 1, failcount); + ret = -1; + } out_free: free(readbuf);

1 0

[PATCH] ST M25P RES support
by Carl-Daniel Hailfinger 22 Jul '09

22 Jul '09

Add support for old ST M25P05/M25P10 chips which only respond to the RES command and not the RDID command. Unfortunately, either the datasheets are wrong or both chips have exactly the same ID. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-sst25_res/flashchips.c =================================================================== --- flashrom-sst25_res/flashchips.c (Revision 659) +++ flashrom-sst25_res/flashchips.c (Arbeitskopie) @@ -2249,8 +2249,29 @@ .read = spi_chip_read, }, + /* The ST M25P05 is a bit of a problem. It has the same ID as the + * ST M25P05-A in RES mode, but supports only 128 byte writes instead + * of 256 byte writes. We rely heavily on the fact that probe_spi_res + * only is successful if RDID does not work. + */ { .vendor = "ST", + .name = "M25P05.RES", + .bustype = CHIP_BUSTYPE_SPI, + .manufacture_id = ST_ID, + .model_id = ST_M25P05_RES, + .total_size = 64, + .page_size = 256, + .tested = TEST_UNTESTED, + .probe = probe_spi_res, + .probe_timing = TIMING_ZERO, + .erase = spi_chip_erase_c7, + .write = spi_chip_write_1, /* 128 */ + .read = spi_chip_read, + }, + + { + .vendor = "ST", .name = "M25P10-A", .bustype = CHIP_BUSTYPE_SPI, .manufacture_id = ST_ID, @@ -2265,8 +2286,25 @@ .read = spi_chip_read, }, + /* The ST M25P10 has the same problem as the M25P05. */ { .vendor = "ST", + .name = "M25P10.RES", + .bustype = CHIP_BUSTYPE_SPI, + .manufacture_id = ST_ID, + .model_id = ST_M25P10_RES, + .total_size = 128, + .page_size = 256, + .tested = TEST_UNTESTED, + .probe = probe_spi_res, + .probe_timing = TIMING_ZERO, + .erase = spi_chip_erase_c7, + .write = spi_chip_write_1, /* 128 */ + .read = spi_chip_read, + }, + + { + .vendor = "ST", .name = "M25P20", .bustype = CHIP_BUSTYPE_SPI, .manufacture_id = ST_ID, Index: flashrom-sst25_res/flashchips.h =================================================================== --- flashrom-sst25_res/flashchips.h (Revision 659) +++ flashrom-sst25_res/flashchips.h (Arbeitskopie) @@ -322,7 +322,9 @@ */ #define ST_ID 0x20 /* ST / SGS/Thomson */ #define ST_M25P05A 0x2010 +#define ST_M25P05_RES 0x10 /* Same code as M25P10. */ #define ST_M25P10A 0x2011 +#define ST_M25P10_RES 0x10 /* Same code as M25P05. */ #define ST_M25P20 0x2012 #define ST_M25P40 0x2013 #define ST_M25P40_RES 0x12 -- http://www.hailfinger.org/

2 2

[commit] r662 - trunk
by svn＠flashrom.org 22 Jul '09

22 Jul '09

Author: hailfinger Date: 2009-07-23 03:40:20 +0200 (Thu, 23 Jul 2009) New Revision: 662 Modified: trunk/flashchips.c trunk/flashchips.h Log: Add support for old ST M25P05/M25P10 chips which only respond to the RES command and not the RDID command. Unfortunately, either the datasheets are wrong or both chips have exactly the same ID. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/flashchips.c =================================================================== --- trunk/flashchips.c 2009-07-23 01:36:08 UTC (rev 661) +++ trunk/flashchips.c 2009-07-23 01:40:20 UTC (rev 662) @@ -2249,8 +2249,29 @@ .read = spi_chip_read, }, + /* The ST M25P05 is a bit of a problem. It has the same ID as the + * ST M25P05-A in RES mode, but supports only 128 byte writes instead + * of 256 byte writes. We rely heavily on the fact that probe_spi_res + * only is successful if RDID does not work. + */ { .vendor = "ST", + .name = "M25P05.RES", + .bustype = CHIP_BUSTYPE_SPI, + .manufacture_id = ST_ID, + .model_id = ST_M25P05_RES, + .total_size = 64, + .page_size = 256, + .tested = TEST_UNTESTED, + .probe = probe_spi_res, + .probe_timing = TIMING_ZERO, + .erase = spi_chip_erase_c7, + .write = spi_chip_write_1, /* 128 */ + .read = spi_chip_read, + }, + + { + .vendor = "ST", .name = "M25P10-A", .bustype = CHIP_BUSTYPE_SPI, .manufacture_id = ST_ID, @@ -2265,8 +2286,25 @@ .read = spi_chip_read, }, + /* The ST M25P10 has the same problem as the M25P05. */ { .vendor = "ST", + .name = "M25P10.RES", + .bustype = CHIP_BUSTYPE_SPI, + .manufacture_id = ST_ID, + .model_id = ST_M25P10_RES, + .total_size = 128, + .page_size = 256, + .tested = TEST_UNTESTED, + .probe = probe_spi_res, + .probe_timing = TIMING_ZERO, + .erase = spi_chip_erase_c7, + .write = spi_chip_write_1, /* 128 */ + .read = spi_chip_read, + }, + + { + .vendor = "ST", .name = "M25P20", .bustype = CHIP_BUSTYPE_SPI, .manufacture_id = ST_ID, Modified: trunk/flashchips.h =================================================================== --- trunk/flashchips.h 2009-07-23 01:36:08 UTC (rev 661) +++ trunk/flashchips.h 2009-07-23 01:40:20 UTC (rev 662) @@ -322,7 +322,9 @@ */ #define ST_ID 0x20 /* ST / SGS/Thomson */ #define ST_M25P05A 0x2010 +#define ST_M25P05_RES 0x10 /* Same code as M25P10. */ #define ST_M25P10A 0x2011 +#define ST_M25P10_RES 0x10 /* Same code as M25P05. */ #define ST_M25P20 0x2012 #define ST_M25P40 0x2013 #define ST_M25P40_RES 0x12

1 0

[PATCH] SB600 SPI off-by-one read count workaround
by Carl-Daniel Hailfinger 22 Jul '09

22 Jul '09

This is a workaround for a bug in SB600 and SB700. If we only send an opcode and no additional data/address, the SPI controller will read one byte too few from the chip. Basically, the last byte of the chip response is discarded and will not end up in the FIFO. It is unclear if the CS# line is set high too early as well. That hardware bug is undocumented as of now, but I'm working with AMD to add a detailed description of it to the errata. Add loads of additional debugging to SB600/SB700 init. Add explanatory comments for unintuitive code flow. Thanks go to Uwe for testing quite a few iterations of the patch. As a side benefit, we can now kill the SB600 flash chip status register special case, which was a somewhat misguided workaround for that hardware erratum. Note for future added features in the SB600 SPI driver: It may be possible to read up to 15 bytes of command response with overlapping reads due to the ring buffer design of the FIFO if the command can be repeated without ill effects. Same for skipping up to 7 bytes between command and response. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-spi_sb600_offbyone_workaround/chipset_enable.c =================================================================== --- flashrom-spi_sb600_offbyone_workaround/chipset_enable.c (Revision 653) +++ flashrom-spi_sb600_offbyone_workaround/chipset_enable.c (Arbeitskopie) @@ -692,25 +692,49 @@ /* Read SPI_BaseAddr */ tmp = pci_read_long(dev, 0xa0); - tmp &= 0xfffffff0; /* remove low 4 bits (reserved) */ + tmp &= 0xffffffe0; /* remove bits 4-0 (reserved) */ printf_debug("SPI base address is at 0x%x\n", tmp); /* If the BAR has address 0, it is unlikely SPI is used. */ if (!tmp) has_spi = 0; - /* Physical memory can only be mapped at page (4k) boundaries */ - sb600_spibar = physmap("SB600 SPI registers", tmp & 0xfffff000, 0x1000); - /* The low bits of the SPI base address are used as offset into the mapped page */ - sb600_spibar += tmp & 0xfff; + if (has_spi) { + /* Physical memory has to be mapped at page (4k) boundaries. */ + sb600_spibar = physmap("SB600 SPI registers", tmp & 0xfffff000, + 0x1000); + /* The low bits of the SPI base address are used as offset into + * the mapped page. + */ + sb600_spibar += tmp & 0xfff; + tmp = pci_read_long(dev, 0xa0); + printf_debug("AltSpiCSEnable=%i, SpiRomEnable=%i, " + "AbortEnable=%i\n", tmp & 0x1, (tmp & 0x2) >> 1, + (tmp & 0x4) >> 2); + tmp = (pci_read_byte(dev, 0xba) & 0x4) >> 2; + printf_debug("PrefetchEnSPIFromIMC=%i, ", tmp); + + tmp = pci_read_byte(dev, 0xbb); + printf_debug("PrefetchEnSPIFromHost=%i, SpiOpEnInLpcMode=%i\n", + tmp & 0x1, (tmp & 0x20) >> 5); + tmp = mmio_readl(sb600_spibar); + printf_debug("SpiArbEnable=%i, SpiAccessMacRomEn=%i, " + "SpiHostAccessRomEn=%i, ArbWaitCount=%i, " + "SpiBridgeDisable=%i, DropOneClkOnRd=%i\n", + (tmp >> 19) & 0x1, (tmp >> 22) & 0x1, + (tmp >> 23) & 0x1, (tmp >> 24) & 0x7, + (tmp >> 27) & 0x1, (tmp >> 28) & 0x1); + } + /* Look for the SMBus device. */ smbus_dev = pci_dev_find(0x1002, 0x4385); - if (!smbus_dev) { + if (has_spi && !smbus_dev) { fprintf(stderr, "ERROR: SMBus device not found. Not enabling SPI.\n"); has_spi = 0; - } else { + } + if (has_spi) { /* Note about the bit tests below: If a bit is zero, the GPIO is SPI. */ /* GPIO11/SPI_DO and GPIO12/SPI_DI status */ reg = pci_read_byte(smbus_dev, 0xAB); Index: flashrom-spi_sb600_offbyone_workaround/sb600spi.c =================================================================== --- flashrom-spi_sb600_offbyone_workaround/sb600spi.c (Revision 653) +++ flashrom-spi_sb600_offbyone_workaround/sb600spi.c (Arbeitskopie) @@ -38,7 +38,7 @@ *}; */ -uint8_t *sb600_spibar; +uint8_t *sb600_spibar = NULL; int sb600_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len) { @@ -106,6 +106,7 @@ int count; /* First byte is cmd which can not being sent through FIFO. */ unsigned char cmd = *writearr++; + unsigned int readoffby1; writecnt--; @@ -124,8 +125,15 @@ return SPI_INVALID_LENGTH; } + /* This is a workaround for a bug in SB600 and SB700. If we only send + * an opcode and no additional data/address, the SPI controller will + * read one byte too few from the chip. Basically, the last byte of + * the chip response is discarded and will not end up in the FIFO. + * It is unclear if the CS# line is set high too early as well. + */ + readoffby1 = (writecnt) ? 0 : 1; + mmio_writeb((readcnt + readoffby1) << 4 | (writecnt), sb600_spibar + 1); mmio_writeb(cmd, sb600_spibar + 0); - mmio_writeb(readcnt << 4 | (writecnt), sb600_spibar + 1); /* Before we use the FIFO, reset it first. */ reset_internal_fifo_pointer(); @@ -147,17 +155,24 @@ /* * After the command executed, we should find out the index of the - * received byte. Here we just reset the FIFO pointer, skip the - * writecnt, is there anyone who have anther method to replace it? + * received byte. Here we just reset the FIFO pointer and skip the + * writecnt. + * It would be possible to increase the FIFO pointer by one instead + * of reading and discarding one byte from the FIFO. + * The FIFO is implemented on top of an 8 byte ring buffer and the + * buffer is never cleared. For every byte that is shifted out after + * the opcode, the FIFO already stores the response from the chip. + * Usually, the chip will respond with 0x00 or 0xff. */ reset_internal_fifo_pointer(); + /* Skip the bytes we sent. */ for (count = 0; count < writecnt; count++) { - cmd = mmio_readb(sb600_spibar + 0xC); /* Skip the byte we send. */ + cmd = mmio_readb(sb600_spibar + 0xC); printf_debug("[ %2x]", cmd); } - printf_debug("The FIFO pointer 6 is %d.\n", mmio_readb(sb600_spibar + 0xd) & 0x07); + printf_debug("The FIFO pointer after skipping is %d.\n", mmio_readb(sb600_spibar + 0xd) & 0x07); for (count = 0; count < readcnt; count++, readarr++) { *readarr = mmio_readb(sb600_spibar + 0xC); printf_debug("[%02x]", *readarr); -- http://www.hailfinger.org/

2 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom July 2009