flashrom

flashrom@flashrom.org

9164 discussions

Re: [flashrom] [PATCH 0/5] check_trans and probe_spi_rdid_edi
by Carl-Daniel Hailfinger 16 Oct '12

16 Oct '12

Am 03.10.2012 06:13 schrieb Stefan Tauner: > This patch set enables us to figure out if transactions will succeed > without executing them, which allows for a refactoring of > probe_spi_rdid_generic() which in consequence makes it possible to add > probe_spi_rdid_edi(). I think this is a good idea. Review below and in each individual patch. > The infrastructure code as a whole, but especially the ichspi code > is heavily modified. Please be aware of that if you test it on > mainboards. > > Stefan Tauner (5): > Refactor ichspi and prepare it for check_trans(). > Prepare wbsio_spi.c for check_trans(). > Introduce check_trans(). > Generify probe_spi_rdid_generic() and add probe_spi_rdid_edi(). > Let the dummy programmer emulate SPI payload limitations. > > This is the output of the dummy programmer to show the new behavior: > > flashrom v0.9.6.1-r1611 on Linux 3.2.0-31-generic (x86_64) > flashrom is free software, get the source code at http://www.flashrom.org > > flashrom was built with libpci 3.1.8, GCC 4.6.3, little endian > Command line (3 args): ./flashrom -p dummy:bus=SPI,spi_prog=wbsio,emulate=M25P10.RES -V > Calibrating delay loop... OS timer resolution is 1 usecs, 1456M loops per second, 10 myus = 10 us, 100 myus = 127 us, 1000 myus = 1023 us, 10000 myus = 10024 us, 4 myus = 10 us, OK. > Initializing dummy programmer > Requested buses are: SPI > Enabling support for SPI flash. > Emulating ST M25P10.RES SPI flash chip (RES, page write) > Using SPI payload limitations of the wbsio programmer. > Filling fake flash chip with 0xff, size 131072 > The following protocols are supported: SPI. > Probing for AMIC A25L05PT, 64 kB: 3 byte RDID not supported on this SPI controller. This should have been "4 byte RDID..." > Probing for AMIC A25L05PU, 64 kB: 3 byte RDID not supported on this SPI controller. > [...] > Probing for Spansion S25FL064A, 8192 kB: 3 byte RDID not supported on this SPI controller. > Probing for SST SST25LF040A, 512 kB: probe_spi_res2: id1 0x10, id2 0x10 > Probing for SST SST25LF080A, 1024 kB: probe_spi_res2: id1 0x10, id2 0x10 > Probing for SST SST25VF010, 128 kB: probe_spi_rems: id1 0xff, id2 0xff > Probing for SST SST25VF016B, 2048 kB: 3 byte RDID not supported on this SPI controller. > Probing for SST SST25VF032B, 4096 kB: 3 byte RDID not supported on this SPI controller. > Probing for SST SST25VF064C, 8192 kB: 3 byte RDID not supported on this SPI controller. > Probing for SST SST25VF040, 512 kB: probe_spi_rems: id1 0xff, id2 0xff > Probing for SST SST25VF040B, 512 kB: 3 byte RDID not supported on this SPI controller. > Probing for SST SST25VF040B.REMS, 512 kB: probe_spi_rems: id1 0xff, id2 0xff > Probing for SST SST25VF080B, 1024 kB: 3 byte RDID not supported on this SPI controller. > [...] > Probing for ST M25P05-A, 64 kB: 3 byte RDID not supported on this SPI controller. > Probing for ST M25P05, 64 kB: probe_spi_res1: id 0x10 > Chip status register is 00 > Found ST flash chip "M25P05" (64 kB, SPI) on dummy. > Probing for ST M25P10-A, 128 kB: 3 byte RDID not supported on this SPI controller. > Probing for ST M25P10, 128 kB: probe_spi_res1: id 0x10 > Chip status register is 00 > Found ST flash chip "M25P10" (128 kB, SPI) on dummy. > Probing for ST M25P20, 256 kB: 3 byte RDID not supported on this SPI controller. > Probing for ST M25P40, 512 kB: 3 byte RDID not supported on this SPI controller. > Probing for ST M25P40-old, 512 kB: probe_spi_res1: id 0x10 > Probing for ST M25P80, 1024 kB: 3 byte RDID not supported on this SPI controller. > [...] > Probing for Winbond W25X64, 8192 kB: 3 byte RDID not supported on this SPI controller. > Probing for Unknown SFDP-capable chip, 0 kB: No SFDP signature found. > Probing for AMIC unknown AMIC SPI chip, 0 kB: 3 byte RDID not supported on this SPI controller. > [...] > Probing for Generic unknown SPI chip (RDID), 0 kB: 3 byte RDID not supported on this SPI controller. > Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xff, id2 0xff > Multiple flash chips were detected: "M25P05", "M25P10" > Please specify which chip to use with the -c <chipname> option. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Re: [flashrom] [PATCH 2/5] Prepare wbsio_spi.c for check_trans().
by Carl-Daniel Hailfinger 16 Oct '12

16 Oct '12

Am 03.10.2012 06:13 schrieb Stefan Tauner: > Introduce determine_mode() which contains the extracted bits of the init > function that do sanity checks but without altering the hardware state. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> I see that you took great care to avoid the pitfalls in converting that code. Good! Side note: That hardware is just awful from a capability/interface perspective. If I had a way to drive it by bitbanging, I'd do that instantly. However, the two of the four essential SPI lines (MOSI and MISO) are not usable as GPIO, so that way of working around hardware limitations is not going to work. > --- > wbsio_spi.c | 136 +++++++++++++++++++++++++++++++++-------------------------- > 1 file changed, 77 insertions(+), 59 deletions(-) > > diff --git a/wbsio_spi.c b/wbsio_spi.c > index 7d4bb2a..778b983 100644 > --- a/wbsio_spi.c > +++ b/wbsio_spi.c > @@ -61,6 +61,53 @@ done: > return flashport; > } > > +/* W83627DHG has 11 command modes: > + * 1=1 command only > + * 2=1 command+1 data write > + * 3=1 command+2 data read > + * 4=1 command+3 address > + * 5=1 command+3 address+1 data write > + * 6=1 command+3 address+4 data write > + * 7=1 command+3 address+1 dummy address inserted by wbsio+4 data read > + * 8=1 command+3 address+1 data read > + * 9=1 command+3 address+2 data read > + * a=1 command+3 address+3 data read > + * b=1 command+3 address+4 data read > + * > + * mode[7:4] holds the command mode > + * mode[3:0] holds SPI address bits [19:16] > + * > + * The Winbond SPI master only supports 20 bit addresses on the SPI bus. :\ > + * Would one more byte of RAM in the chip (to get all 24 bits) really make > + * such a big difference? > + */ > +static uint8_t determine_mode(struct flashctx *flash, unsigned int writecnt, unsigned int readcnt, > + const unsigned char *writearr) > +{ > + if (1 == writecnt && 0 == readcnt) { > + return 0x10; > + } else if (2 == writecnt && 0 == readcnt) { > + return 0x20; > + } else if (1 == writecnt && 2 == readcnt) { > + return 0x30; > + } else if (4 == writecnt && 0 == readcnt) { > + return 0x40 | (writearr[1] & 0x0f); Would it be possible to return only 0x40 here, and add the low nibble of writearr[1] inside wbsio_send_command? That low nibble is not part of the mode, it just happens to be stored in the same hw register for some modes. Same for other cases. > + } else if (5 == writecnt && 0 == readcnt) { > + return 0x50 | (writearr[1] & 0x0f); > + } else if (8 == writecnt && 0 == readcnt) { > + return 0x60 | (writearr[1] & 0x0f); > + } else if (5 == writecnt && 4 == readcnt) { > + /* XXX: TODO not supported by flashrom infrastructure! > + * This mode, 7, discards the fifth byte in writecnt, > + * but since we can not express that in flashrom, fail > + * the operation for now. > + */; > + } else if (4 == writecnt && readcnt >= 1 && readcnt <= 4) { > + return ((7 + readcnt) << 4) | (writearr[1] & 0x0f); > + } > + return 0; > +} > + > static int wbsio_spi_send_command(struct flashctx *flash, unsigned int writecnt, > unsigned int readcnt, > const unsigned char *writearr, > @@ -95,52 +142,37 @@ int wbsio_check_for_spi(void) > return 0; > } > > -/* W83627DHG has 11 command modes: > - * 1=1 command only > - * 2=1 command+1 data write > - * 3=1 command+2 data read > - * 4=1 command+3 address > - * 5=1 command+3 address+1 data write > - * 6=1 command+3 address+4 data write > - * 7=1 command+3 address+1 dummy address inserted by wbsio+4 data read > - * 8=1 command+3 address+1 data read > - * 9=1 command+3 address+2 data read > - * a=1 command+3 address+3 data read > - * b=1 command+3 address+4 data read > - * > - * mode[7:4] holds the command mode > - * mode[3:0] holds SPI address bits [19:16] > - * > - * The Winbond SPI master only supports 20 bit addresses on the SPI bus. :\ > - * Would one more byte of RAM in the chip (to get all 24 bits) really make > - * such a big difference? > - */ > static int wbsio_spi_send_command(struct flashctx *flash, unsigned int writecnt, > unsigned int readcnt, > const unsigned char *writearr, > unsigned char *readarr) > { > int i; > - uint8_t mode = 0; > + uint8_t mode = determine_mode(flash, writecnt, readcnt, writearr); > > - msg_pspew("%s:", __func__); > + if (!mode) { > + msg_perr("%s: unsupported command type wr=%d rd=%d\n", > + __func__, writecnt, readcnt); > + /* Command type refers to the number of bytes read/written. */ > + return SPI_INVALID_LENGTH; > + } > > - if (1 == writecnt && 0 == readcnt) { > - mode = 0x10; > - } else if (2 == writecnt && 0 == readcnt) { > + msg_pspew(" cmd=%02x mode=%02x\n", writearr[0], mode); > + switch (mode & 0xF0) { That masking would become unnecessary. > + case 0x10: break; > + case 0x20: > OUTB(writearr[1], wbsio_spibase + 4); > msg_pspew(" data=0x%02x", writearr[1]); > - mode = 0x20; > - } else if (1 == writecnt && 2 == readcnt) { > - mode = 0x30; > - } else if (4 == writecnt && 0 == readcnt) { > + break; > + case 0x30: break; > + case 0x40: > msg_pspew(" addr=0x%02x", (writearr[1] & 0x0f)); > for (i = 2; i < writecnt; i++) { > OUTB(writearr[i], wbsio_spibase + i); > msg_pspew("%02x", writearr[i]); > } > - mode = 0x40 | (writearr[1] & 0x0f); And here you could use mode |= (writearr[1] & 0x0f); Same for other cases where mode >= 0x40. > - } else if (5 == writecnt && 0 == readcnt) { > + break; > + case 0x50: > msg_pspew(" addr=0x%02x", (writearr[1] & 0x0f)); > for (i = 2; i < 4; i++) { > OUTB(writearr[i], wbsio_spibase + i); > @@ -148,8 +180,8 @@ static int wbsio_spi_send_command(struct flashctx *flash, unsigned int writecnt, > } > OUTB(writearr[i], wbsio_spibase + i); > msg_pspew(" data=0x%02x", writearr[i]); > - mode = 0x50 | (writearr[1] & 0x0f); > - } else if (8 == writecnt && 0 == readcnt) { > + break; > + case 0x60: > msg_pspew(" addr=0x%02x", (writearr[1] & 0x0f)); > for (i = 2; i < 4; i++) { > OUTB(writearr[i], wbsio_spibase + i); > @@ -160,44 +192,30 @@ static int wbsio_spi_send_command(struct flashctx *flash, unsigned int writecnt, > OUTB(writearr[i], wbsio_spibase + i); > msg_pspew("%02x", writearr[i]); > } > - mode = 0x60 | (writearr[1] & 0x0f); > - } else if (5 == writecnt && 4 == readcnt) { > - /* XXX: TODO not supported by flashrom infrastructure! > - * This mode, 7, discards the fifth byte in writecnt, > - * but since we can not express that in flashrom, fail > - * the operation for now. > - */ > - ; > - } else if (4 == writecnt && readcnt >= 1 && readcnt <= 4) { > + break; > + case 0x70: /* unimplemented */ > + break; > + default: > msg_pspew(" addr=0x%02x", (writearr[1] & 0x0f)); > for (i = 2; i < writecnt; i++) { > OUTB(writearr[i], wbsio_spibase + i); > msg_pspew("%02x", writearr[i]); > } > - mode = ((7 + readcnt) << 4) | (writearr[1] & 0x0f); > - } > - msg_pspew(" cmd=%02x mode=%02x\n", writearr[0], mode); > - > - if (!mode) { > - msg_perr("%s: unsupported command type wr=%d rd=%d\n", > - __func__, writecnt, readcnt); > - /* Command type refers to the number of bytes read/written. */ > - return SPI_INVALID_LENGTH; > + break; > } > > OUTB(writearr[0], wbsio_spibase); > OUTB(mode, wbsio_spibase + 1); > programmer_delay(10); Side note: I have absolutely no idea why this programmer_delay() is here. It seems to be pointless... unless the hardware is even more broken than I thought. No need to change it, I just wanted to point it out. > > - if (!readcnt) > - return 0; > - > - msg_pspew("%s: returning data =", __func__); > - for (i = 0; i < readcnt; i++) { > - readarr[i] = INB(wbsio_spibase + 4 + i); > - msg_pspew(" 0x%02x", readarr[i]); > + if (readcnt > 0) { > + msg_pspew("%s: returning data =", __func__); > + for (i = 0; i < readcnt; i++) { > + readarr[i] = INB(wbsio_spibase + 4 + i); > + msg_pspew(" 0x%02x", readarr[i]); > + } > + msg_pspew("\n"); > } > - msg_pspew("\n"); > return 0; > } > I don't see the point of this last hunk. Except for additional indentation and an elimination of an early return, the code stays the same. IMHO the early return is more readable, but I guess code readability is in the eye of the beholder. I don't care that much either way, it's your choice. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

Re: [flashrom] [PATCH 5/5] Let the dummy programmer emulate SPI payload limitations.
by Carl-Daniel Hailfinger 15 Oct '12

15 Oct '12

Am 03.10.2012 06:13 schrieb Stefan Tauner: > --- a/dummyflasher.c > +++ b/dummyflasher.c > @@ -119,7 +119,7 @@ static uint32_t dummy_chip_readl(const struct flashctx *flash, > static void dummy_chip_readn(const struct flashctx *flash, uint8_t *buf, > const chipaddr addr, size_t len); > > -static const struct spi_programmer spi_programmer_dummyflasher = { > +static struct spi_programmer spi_programmer_dummyflasher = { > .type = SPI_CONTROLLER_DUMMY, > .max_data_read = MAX_DATA_READ_UNLIMITED, > .max_data_write = MAX_DATA_UNSPECIFIED, > @@ -373,6 +373,19 @@ int dummy_init(void) > msg_pdbg("Initial status register is set to 0x%02x.\n", > emu_status); > } > + tmp = extract_programmer_param("spi_prog"); > + if (tmp) { > + if (!strcmp(tmp, "wbsio")) { > + spi_programmer_dummyflasher.check_trans = wbsio_spi_check_trans; This will cause compile failures if CONFIG_INTERNAL=no A similar #ifdef guard is needed for the programmer.h chunk unless we decide that it's ok to have prototypes for unavailable functions. > + msg_pdbg("Using SPI payload limitations of the %s programmer.\n", tmp); > + } else { > + msg_perr("Error: emulation of a programmer requested, " > + "but the programmer could not be parsed \"%s\".\n", tmp); > + free(tmp); > + return 1; > + } > + } > + free(tmp); > #endif > > msg_pdbg("Filling fake flash chip with 0xff, size %i\n", emu_chip_size); Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

Re: [flashrom] [PATCH 4/5] Generify probe_spi_rdid_generic() and add probe_spi_rdid_edi().
by Antonio Ospite 15 Oct '12

15 Oct '12

On Wed, 3 Oct 2012 06:13:04 +0200 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote: > Previously the "generic" function was working/used for exactly two > cases, namely for manufacturer IDs with 0 or 1 continuation bytes. > For this behavior it was overly complicated. > > The new implementation handles up to 3 continuation bytes > automatically and allows for up to 4 model bytes which is directly > used to add support for an EDI probing function. The probe_spi_rdid4() > function is removed because it is no longer needed. > > The new probe_spi_rdid_generic() tries to figure out the maximum > allowed read size by using the recently added check_trans() function > to reduce the request size if necessary. While this does not make > detection to succeed in all theoretical situations, it improves the > code and will hopefully work in all realworld situations. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > flashchips.c | 24 +++++++-------- > flashchips.h | 2 +- > spi25.c | 97 ++++++++++++++++++++++++++++++---------------------------- > 3 files changed, 63 insertions(+), 60 deletions(-) > A fixup like this is needed for probe_spi_rdid_edi() to be usable: diff --git a/chipdrivers.h b/chipdrivers.h index 1ef4959..b754076 100644 --- a/chipdrivers.h +++ b/chipdrivers.h @@ -34,7 +34,7 @@ int spi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, int /* spi25.c */ int probe_spi_rdid(struct flashctx *flash); -int probe_spi_rdid4(struct flashctx *flash); +int probe_spi_rdid_edi(struct flashctx *flash); int probe_spi_rems(struct flashctx *flash); int probe_spi_res1(struct flashctx *flash); int probe_spi_res2(struct flashctx *flash); -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

1 0

[RFC, PATCH] Add read support for the Spansion S25FL129P flash chip
by Antonio Ospite 15 Oct '12

15 Oct '12

http://www.spansion.com/Support/Datasheets/S25FL129P_00.pdf http://www.spansion.com/Support/Application%20Notes/S25FL129P_Prog_Guide_AN… Signed-off-by: Antonio Ospite <ospite(a)studenti.unina.it> --- Hi, I was able to read the content of the flash chip in the subject with the patch below but I am not sure if the patch is correct and ready for submission, could someone please check with the datasheet? I know very little about flash chips. Moreover from the Datasheet (Table 9.2, page 34) I see that this chip comes in two variants, one with 64K sectors and one with 256KB sectors, and some "Extended Device Identification" is used to identify the right variant, I don't know if flashrom supports reading such information. I see that somewhere else that is supported: http://old.nabble.com/-PATCH--m25p80:-Add-Spansion-S25FL129P-serial-flashes… I didn't feel like testing erase/write either as the connection to the chip was/is quite unreliable, I just needed to get a rootfs off from it once (it's some embedded router). If anyone can suggest some really cheap place where to get test clips or probes in Italy (or even better feels like donating some), I might risk testing erase/write after we solve the issue about the chip variant. BTW the output after the patch: $ sudo ./flashrom -p ft2232_spi:type=tumpa,port=B -r flash.bin flashrom v0.9.6.1-r1599 on Linux 3.6.0-rc5-ao2 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found Spansion flash chip "S25FL129P" (16384 kB, SPI) on ft2232_spi. Reading flash... done. Thanks, Antonio Ospite http://ao2.it flashchips.c | 28 ++++++++++++++++++++++++++++ flashchips.h | 1 + 2 files changed, 29 insertions(+) diff --git a/flashchips.c b/flashchips.c index a6c2004..ced6ad0 100644 --- a/flashchips.c +++ b/flashchips.c @@ -6288,6 +6288,34 @@ const struct flashchip flashchips[] = { }, { + .vendor = "Spansion", + .name = "S25FL129P", + .bustype = BUS_SPI, + .manufacture_id = SPANSION_ID, + .model_id = SPANSION_S25FL129P, + .total_size = 16384, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN, + .tested = TEST_OK_PR, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {64 * 1024, 256} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {4 * 1024, 4096} }, + .block_erase = spi_block_erase_20, + } + }, + .unlock = spi_disable_blockprotect, + .write = spi_chip_write_256, + .read = spi_chip_read, + .voltage = {2700, 3600}, + }, + + { .vendor = "SST", .name = "SST25LF040A", .bustype = BUS_SPI, diff --git a/flashchips.h b/flashchips.h index 8e51d35..d13773d 100644 --- a/flashchips.h +++ b/flashchips.h @@ -480,6 +480,7 @@ #define SPANSION_S25FL016A 0x0214 #define SPANSION_S25FL032A 0x0215 #define SPANSION_S25FL064A 0x0216 +#define SPANSION_S25FL129P 0x2018 /* * SST25 chips are SPI, first byte of device ID is memory type, second -- 1.7.10.4

2 4

Re: [flashrom] add Numonyx/Micron N25Q128
by Stefan Tauner 15 Oct '12

15 Oct '12

On Sat, 9 Jun 2012 14:51:15 +0200 frederic.temporelli(a)bull.net wrote: > Hello > > > Numonyx/Micron N25Q128 is used on new X9 motherboards from Supermicro (X9DRT, ...) > > Specs are availbale on Micron WWW site: > http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NOR%20Flash/S… > > Following patch add this chip to flashrom. Probe is OK. > Due to Manageability Engine, some work is required before being able to test READ/ERASE/WRITE... > > ================================================================================= > Signed-off-by: Frederic Temporelli <frederic.temporelli(a)bull.net> > > diff -urN flashrom-0.9.5.2-r1540/flashchips.c flashrom-0.9.5.2-r1540-n25q128/flashchips.c > --- flashrom-0.9.5.2-r1540/flashchips.c 2012-05-20 23:32:32.000000000 +0000 > +++ flashrom-0.9.5.2-r1540-n25q128/flashchips.c 2012-06-09 14:41:07.064141076 +0000 > @@ -5453,6 +5453,37 @@ > }, > > { > + .vendor = "Numonyx", > + .name = "N25Q128", > + .bustype = BUS_SPI, > + .manufacture_id = ST_ID, > + .model_id = ST_N25Q128, > + .total_size = 16384, > + .page_size = 256, > + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, > + .tested = TEST_OK_PROBE, > + .probe = probe_spi_rdid, > + .probe_timing = TIMING_ZERO, > + .block_erasers = > + { > + { > + .eraseblocks = { {4 * 1024, 4096 } }, > + .block_erase = spi_block_erase_20, > + }, { > + .eraseblocks = { {64 * 1024, 256} }, > + .block_erase = spi_block_erase_d8, > + }, { > + .eraseblocks = { {16 * 1024 * 1024, 1} }, > + .block_erase = spi_block_erase_c7, > + } > + }, > + .unlock = spi_disable_blockprotect, > + .write = spi_chip_write_256, > + .read = spi_chip_read, > + }, > + > + > + { > .vendor = "PMC", > .name = "Pm25LV010", > .bustype = BUS_SPI, > diff -urN flashrom-0.9.5.2-r1540/flashchips.h flashrom-0.9.5.2-r1540-n25q128/flashchips.h > --- flashrom-0.9.5.2-r1540/flashchips.h 2012-05-14 01:51:46.000000000 +0000 > +++ flashrom-0.9.5.2-r1540-n25q128/flashchips.h 2012-06-08 20:46:47.225385676 +0000 > @@ -587,6 +587,7 @@ > #define ST_M29W040B 0xE3 > #define ST_M29W512B 0x27 > #define ST_N25Q064 0xBA17 > +#define ST_N25Q128 0xBA18 /* also Numonyx N25Q128 */ > > #define SYNCMOS_MVC_ID 0x40 /* SyncMOS (SM) and Mosel Vitelic Corporation (MVC) */ > #define MVC_V29C51000T 0x00 > ================================================================================= hello and thanks for your patch! this chip is a bit complicated and we cant merge the patch as it is. they have used the same plane RDID for multiple variants of the chip. some attributes are not important for flashrom and can be ignored, but some are very important, namely the boot sector layout. quote from p.52: > The N25Q128 is available in the following architecture versions: > Bottom version, 64 KB uniform sectors plus 8 bottom boot sectors (each with 16 > subsectors), > Top version, 64 KB uniform sectors plus 8 top boot sectors (each with 16 subsectors) > Uniform version, 64 KB uniform sectors without any boot sectors and subsectors. the good news is that this differences can be detected by an extended RDID command in its 5th byte (1 manufacturer, 2 device, 1 length of the following extended data, the first EDID byte we want), see table 15. of this 5th byte we need to look at the first two bits to determine the architecture, see table 16. our current infrastructure (probe_spi_rdid_generic) cant handle that, but should... so we will plan a change, but please dont expect it to happen too soon. the bad news is that i am not even sure if the subsector erase commands work as flashrom expects. flashrom wants to use the same erase opcode for the hole address space, even for non-uniform layouts. this usually works fine, but afaics it is not specified in the datasheet what happens if one uses the subsector erase opcode on a non-subsector *on devices that actually have subsectors* (the emphasis stems from the fact that it *is* defined, that the subsector erase command is ignore by the uniform model: "Any Subsector Erase (SSE) instruction in devices with uniform architecture (meaning no boot sectors with subsectors) is rejected without having any effects on the device." (p. 98). other interesting bits of this chips: - bit#5 of the status register "is used in conjunction with the Block Protect (BP3, BP2, BP1, BP0) bits to determine if the protected area defined by the Block Protect bits starts from the top or the bottom of the memory array" - a flag status register that gives more info than the "legacy spi status register" - a non-volatile configuration register to configure dummy clock cycles, output driver strength and other stuff, and a volatile register that overrides the nvm settings the first two points can be somewhat ignored by us, the generic "write 0 to the status register" is good enough to unlock the device. regarding the ME: are you aware of my layout patches, that enable read, erase and verify on user-definable address ranges? see the patches from 2011-12-25 at http://patchwork.coreboot.org/project/flashrom/list/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

Re: [flashrom] [PATCH] Cache SPI RDID response
by Stefan Tauner 12 Oct '12

12 Oct '12

On Thu, 11 Oct 2012 19:16:40 -0700 David Hendricks <dhendrix(a)google.com> wrote: > On Wed, Oct 3, 2012 at 3:59 PM, Carl-Daniel Hailfinger < > c-d.hailfinger.devel.2006(a)gmx.net> wrote: > > > Not for merge... yet. > > It works for dummy, nothing else was tested. > > Limitations/bugs mentioned in the patch. > > > > Interesting approach. However, I think 3-byte vs. 4-byte RDID commands and > caching REMS might make patching spi_send_command rather messy. > > I made a patch that takes a different route by changing > probe_spi_{rdid,rdid4,rems} functions instead. My patch can be viewed via > Gerrit on Chromium.org @ > https://gerrit.chromium.org/gerrit/#/c/35376/2 (doesn't > apply cleanly against upsteam currently). > Much better, but still wrong :) We work around a stupid probing loop instead fixing the root cause (verbose prints will still be way too verbose with this patch). If there are good reasons to do it this way, then i have no problem with it, but if we just hack this into the SPI code because it is easier to implement and come to a consensus, then i'll make the latter hard :P Fixing the probing loop has been on my todo list for a long time and i will work on it as soon as the other architectural changes are merged (status register stuff, check_trans etc). We should postpone the discussion until then IMHO. I suggest that chromium uses David's method till then and someone reviews my other patches soon ;) OTOH it would not hurt to integrate this into upstream with one exception: it would introdcue even more conflicts between open patches: David: some of this heavily conflicts with my "Generify probe_spi_rdid_generic() and add probe_spi_rdid_edi()." and other patches from that set. Maybe it would be better if you leave out the compare_id() introduction to get less conflicts later. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[PATCH] Cache SPI RDID response
by Carl-Daniel Hailfinger 12 Oct '12

12 Oct '12

Not for merge... yet. It works for dummy, nothing else was tested. Limitations/bugs mentioned in the patch. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-spi_cache_rdid/spi.c =================================================================== --- flashrom-spi_cache_rdid/spi.c (Revision 1611) +++ flashrom-spi_cache_rdid/spi.c (Arbeitskopie) @@ -24,18 +24,46 @@ #include <strings.h> #include <string.h> +#include <stdlib.h> #include "flash.h" #include "flashchips.h" #include "chipdrivers.h" #include "programmer.h" #include "spi.h" +/* FIXME: We want a per-command cache, not just a RDID cache. + * FIXME: We should cache this for spi_send_multicommand programmers as well. + */ +struct rdidcache { + int available; + unsigned char *readarr; +} rdidcache = {0}; + int spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr) { - return flash->pgm->spi.command(flash, writecnt, readcnt, writearr, + int ret; + unsigned char *tmp; + + if ((writearr[0] == JEDEC_RDID) && (rdidcache.available >= readcnt)) { + memcpy(readarr, rdidcache.readarr, readcnt); + return 0; + } + ret = flash->pgm->spi.command(flash, writecnt, readcnt, writearr, readarr); + if (!ret && (writearr[0] == JEDEC_RDID) && (rdidcache.available < readcnt)) { + tmp = realloc(rdidcache.readarr, readcnt); + if (!tmp) { + /* Oh well. Don't cache stuff, then. No problem. */ + msg_perr("Doom due to OOM! Brace for impact!\n"); + return ret; + } + rdidcache.readarr = tmp; + rdidcache.available = readcnt; + memcpy(rdidcache.readarr, readarr, readcnt); + } + return ret; } int spi_send_multicommand(struct flashctx *flash, struct spi_command *cmds) -- http://www.hailfinger.org/

2 1

Re: [flashrom] undetected Intel X79 (8086:1d41) flash chip
by Stefan Tauner 12 Oct '12

12 Oct '12

On Wed, 10 Oct 2012 13:26:09 +0300 Alexey Dobriyan <adobriyan(a)gmail.com> wrote: > > The problem is the locked ME region as quoted above. We are working on > > unlocking it, but intel does not provide us any documentation so please > > do not expect a solution soon. > > > > Can you please tell us which Supermicro board that is so that i can add > > it to our list of unsupported boards in the meantime? > > I can't, it's a custom(?) board with DMI info et al stripped and replaced. OK > Why this ME region is important? It doesn't overlap with BIOS region. > > Alexey, who know approximately nothing about BIOS internals The ME region contains the firmware for an embedded controller (EC) in the chipset. It is used for fan control and a number of other things and also has access to basically everything the CPU has access to. The interaction between the BIOS with this EC is not documented and it is theoretically possible that updating the BIOS alone without updating the ME firmware before would brick the PC. Flashrom plays safe and disables writes if it detects that we can not write to the ME region. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

undetected Intel X79 (8086:1d41) flash chip
by Alexey Dobriyan 10 Oct '12

10 Oct '12

This comes from Sandy Bridge mobo. Is it supported in trunk? I can experiment with the system a bit if necessary. 00:1f.0 ISA bridge [0601]: Intel Corporation Patsburg LPC Controller [8086:1d41] (rev 06) Subsystem: Super Micro Computer Inc Device [15d9:0669] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c <?> 00: 86 80 41 1d 07 00 10 02 06 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 69 06 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00 50: f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 8b 8a 85 8b d0 00 00 00 80 80 8a 87 ff 00 00 00 70: 78 f0 78 f0 78 f0 78 f0 78 f0 78 f0 78 f0 78 f0 80: 10 00 0f 3f 01 0a 0c 00 a1 0c 0c 00 41 16 1c 00 90: 00 00 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 a0: 18 0a 20 00 08 18 06 00 00 47 00 00 00 03 00 c0 b0: 00 00 00 00 00 00 00 00 00 0c 4c 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 11 00 67 45 00 00 c0 ff 00 00 0a 00 00 00 e0: 09 00 0c 10 00 00 00 00 91 02 64 0c 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 87 0f 06 08 00 00 00 00 flashrom v0.9.6.1-r1564 on Linux 2.6.39-alta-22 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.0.0, GCC 4.4.3, little endian Command line (3 args): ./flashrom -VV -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 301M loops per second, 10 myus = 10 us, 100 myus = 99 us, 1000 myus = 1010 us, 10000 myus = 10041 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. sh: dmidecode: not found dmidecode execution unsuccessful - continuing without DMI info Found chipset "Intel X79" with PCI ID 8086:1d41. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode disabled 0xff600000/0xff200000 FWH decode disabled 0xff500000/0xff100000 FWH decode disabled 0xff400000/0xff000000 FWH decode disabled Maximum FWH chip size: 0x100000 bytes BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0xa Root Complex Register Block address = 0xfed1c000 GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3800 0x04: 0x6008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=0 Programming OPCODES... program_opcodes: preop=5006 optype=463b opmenu=05d80302c79f0190 done OP Type Pre-OP op[0]: 0x02, write w/ addr, none op[1]: 0x03, read w/ addr, none op[2]: 0xd8, write w/ addr, none op[3]: 0x05, read w/o addr, none op[4]: 0x90, read w/ addr, none op[5]: 0x01, write w/o addr, none op[6]: 0x9f, read w/o addr, none op[7]: 0xc7, write w/o addr, none Pre-OP 0: 0x06, Pre-OP 1: 0x50 0x06: 0x0000 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 0x08: 0x00000000 (FADDR) 0x50: 0x00001a1b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x1a, BRRA 0x1b 0x54: 0x000f0000 FREG0: WARNING: Flash Descriptor region (0x00000000-0x0000ffff) is read-only. 0x58: 0x0fff0800 FREG1: BIOS region (0x00800000-0x00ffffff) is read-write. 0x5C: 0x07ff0020 FREG2: WARNING: Management Engine region (0x00020000-0x007fffff) is locked. 0x60: 0x00000fff FREG3: Gigabit Ethernet region is unused. 0x64: 0x001f0010 FREG4: Platform Data region (0x00010000-0x0001ffff) is read-write. 0x74: 0x00000000 (PR0 is unused) 0x78: 0x00000000 (PR1 is unused) 0x7C: 0x00000000 (PR2 is unused) 0x80: 0x00000000 (PR3 is unused) 0x84: 0x00000000 (PR4 is unused) Please send a verbose log to flashrom(a)flashrom.org if this board is not listed on http://flashrom.org/Supported_hardware#Supported_mainboards yet. Writes have been disabled. You can enforce write support with the ich_spi_force programmer option, but it will most likely harm your hardware! If you force flashrom you will get no support if something breaks. 0x90: 0x84 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xf84140 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=1, SME=0, SCF=0 0x94: 0x5006 (PREOP) 0x96: 0x463b (OPTYPE) 0x98: 0x05d80302 (OPMENU) 0x9C: 0xc79f0190 (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x00002005 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0 0xC8: 0x00002005 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0 0xD0: 0x00000000 (FPB) Reading flash descriptors mapped by the chipset via FDOC/FDOD... done. === Content Section === FLVALSIG 0x0ff0a55a FLMAP0 0x03040003 FLMAP1 0x12100206 FLMAP2 0x00210020 --- Details --- NR (Number of Regions): 4 FRBA (Flash Region Base Address): 0x040 NC (Number of Components): 1 FCBA (Flash Component Base Address): 0x030 ISL (ICH/PCH Strap Length): 18 FISBA/FPSBA (Flash ICH/PCH Strap Base Address): 0x100 NM (Number of Masters): 3 FMBA (Flash Master Base Address): 0x060 MSL/PSL (MCH/PROC Strap Length): 0 FMSBA (Flash MCH/PROC Strap Base Address): 0x200 === Component Section === FLCOMP 0x24900025 FLILL 0x00000000 --- Details --- Component 1 density: 16 MB Component 2 is not used. Read Clock Frequency: 20 MHz Read ID and Status Clock Freq.: 50 MHz Write and Erase Clock Freq.: 50 MHz Fast Read is supported. Fast Read Clock Frequency: 50 MHz No forbidden opcodes. === Region Section === FLREG0 0x000f0000 FLREG1 0x0fff0800 FLREG2 0x07ff0020 FLREG3 0x00000fff FLREG4 0x001f0010 --- Details --- Region 0 (Descr.) 0x00000000 - 0x0000ffff Region 1 (BIOS ) 0x00800000 - 0x00ffffff Region 2 (ME ) 0x00020000 - 0x007fffff Region 3 (GbE ) is unused. Region 4 (Platf.) 0x00010000 - 0x0001ffff === Master Section === FLMSTR1 0x1a1b0000 FLMSTR2 0x04050000 FLMSTR3 0x08090118 --- Details --- Descr. BIOS ME GbE Platf. BIOS r rw rw rw ME r rw GbE r rw SPI Read Configuration: prefetching enabled, caching enabled, OK. The following protocols are supported: FWH, SPI. Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L10PU, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L40PT, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L80P, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L16PT, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L16PU, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L512, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L010, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L020, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L040, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L080, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L016, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25L032, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for AMIC A25LQ032, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF021, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF041A, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF081, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF081A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF161, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF321, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF321A, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DF641(A), 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25DQ161, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25F512B, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25FS010, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT25FS040, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT26DF041, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT26DF081A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT26DF161, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT26DF161A, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT26F004, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45CS1282, 16896 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB011D, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB021D, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB041D, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB081D, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB161D, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB321C, 4224 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB321D, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel AT45DB642D, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for EMST F25L008A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B05, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B05T, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B10T, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B20T, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B40T, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B80T, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B16T, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B32T, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25B64T, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F05, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25F32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25Q40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25Q80(A), 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25Q16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25Q32(A/B), 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25Q64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25QH16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon EN25QH32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for GigaDevice GD25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L512, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L1005, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L2005, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L4005, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L8005, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L1605, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L1635D, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L1635E, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L3205, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L3235D, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L6405, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix MX25L12805, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Numonyx M25PE10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Numonyx M25PE20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Numonyx M25PE40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Numonyx M25PE80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Numonyx M25PE16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Numonyx N25Q064, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC Pm25LV010, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC Pm25LV016B, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC Pm25LV020, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC Pm25LV040, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC Pm25LV080B, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC Pm25LV512, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Sanyo LF25FW203A, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Spansion S25FL004A, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Spansion S25FL008A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Spansion S25FL016A, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Spansion S25FL032A, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for SST SST25LF040A, 512 kB: program_opcodes: preop=5006 optype=462b opmenu=05ab0302c79f0190 on-the-fly OPCODE (0xAB) re-programmed, op-pos=2 probe_spi_res2: id1 0xff, id2 0xff Probing for SST SST25LF080A, 1024 kB: probe_spi_res2: id1 0xff, id2 0xff Probing for SST SST25VF010, 128 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for SST SST25VF032B, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for SST SST25VF064C, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for SST SST25VF040, 512 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for SST SST25VF040B, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for SST SST25VF040B.REMS, 512 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for SST SST25VF080B, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P05-A, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P05, 64 kB: Ignoring RES in favour of RDID. Probing for ST M25P10-A, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P10, 128 kB: Ignoring RES in favour of RDID. Probing for ST M25P20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P40-old, 512 kB: Ignoring RES in favour of RDID. Probing for ST M25P80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25P128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25PX16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25PX32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST M25PX64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25Q80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25Q16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25Q32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Winbond W25X64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Unknown SFDP-capable chip, 0 kB: program_opcodes: preop=5006 optype=462b opmenu=055a0302c79f0190 on-the-fly OPCODE (0x5A) re-programmed, op-pos=2 SFDP revision = 1.0 SFDP number of parameter headers is 1 (NPH = 0). SFDP parameter table header 0/0: ID 0x00, version 1.0 Length 36 B, Parameter Table Pointer 0x000030 Parsing JEDEC flash parameter table... 3-Byte only addressing. Status register is non-volatile and the standard does not allow vendors to tell us whether EWSR/WREN is needed for status register writes - assuming EWSR. Write chunk size is at least 64 B. Flash chip size is 16384 kB. Block eraser 0: 4096 x 4096 B with opcode 0x20 Tried to add a duplicate block eraser: 4096 x 4096 B with opcode 0x20. Block eraser 1: 256 x 65536 B with opcode 0xd8 done. === SFDP has autodetected a flash chip which is not natively supported by flashrom yet. All standard operations (read, verify, erase and write) should work, but to support all possible features we need to add them manually. You can help us by mailing us the output of the following command to flashrom(a)flashrom.org: 'flashrom -VV [plus the -p/--programmer parameter (if needed)]' Thanks for your help! === Found Unknown flash chip "SFDP-capable chip" (16384 kB, SPI) at physical address 0x0. Probing for AMIC unknown AMIC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Atmel unknown Atmel SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Eon unknown Eon SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Macronix unknown Macronix SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for PMC unknown PMC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for SST unknown SST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for ST unknown ST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Sanyo unknown Sanyo SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0xba18 Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: Chip size 2048 kB is bigger than supported size 1024 kB of chipset/board/programmer for FWH interface, probe/read/erase/write may fail. probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: Chip size 2048 kB is bigger than supported size 1024 kB of chipset/board/programmer for FWH interface, probe/read/erase/write may fail. probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Found Unknown flash chip "SFDP-capable chip" (16384 kB, SPI). No operations were specified. Restoring MMIO space at 0x7fb022bed8a0 Restoring MMIO space at 0x7fb022bed89c Restoring MMIO space at 0x7fb022bed898 Restoring MMIO space at 0x7fb022bed896 Restoring MMIO space at 0x7fb022bed894 Restoring PCI config space for 00:1f:0 reg 0xdc

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom