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 … [View More]

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 … [View More]> 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/ [View Less]

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 … [View More]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/ [View Less]

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, > … [View More]

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 … [View More]

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)… [View More] 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 [View Less]

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... > > ===… [View More]============================================================================== > 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 [View Less]

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 … [View More]

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> … [View More]

2 1

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

11 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 … [View More]

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom October 2012