flashrom October 2012

flashrom@flashrom.org

26 participants
89 discussions

NEED help for programing the EEPROM on intel NIC 9400PT
by zz z 16 Oct '12

16 Oct '12

Hello flashrom's developers: I want to save my ethernet adapter. I have an Intel 9400PT nic, the controller is 82572EI which was on your supported list, but the PCI ID is not match, mine is 8086-107D, and your list show 8086-10B9.And these two NIC is totally identical in hardware, just different eeprom contents. My problem is I used "eeupdate" clear the PCI Vendor ID to 0000 by my mistake. Now the PCI device id is 0000-107D. As the result BIOS & OS can't recognise it at all, even eeupdate itself ! But some software (like AIDA64 ) can recognise it as a unknown device which pci vendor id is 0000. So I google that flashrom can help me ,(I have the original eep file.) I download it and run it in DOS. I used command "flashrom -w 9400pt.eep -p -nicintel_spi", then flashrom told me: * > > Calibrating delay loop... OK. > No EEPROM/flash device found. > Note: flashrom can never write if the flash chip isn't found automatically. * So I need help how to using flashrom to program the eeprom on NIC. And can flashrom use SMBUS address to flash?(I know the SMBUS address of this NIC.) Thanks a lot. yours sincerely

1 0

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 15 Oct '12

15 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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom October 2012