- flashrom - mail.coreboot.org

Question - Help
by Neb Radojkovic 05 Dec '15

05 Dec '15

Hello, This could be a totally wrong place for what I am trying to accomplish but it doesn't hurt to ask. I joined flashrom in hope that it will help me. I have an older HP small-factor desktop computer where the BIOS is somewhat limited for any adjusting/ changes. It takes forever to boot to any OS I load and I was hoping that by flashing and getting an open BIOS things will get faster and better. Now, I have no real knowledge for doing so - I am an old guy who would like to think that I can find enough info to do so. Is this the place that can help me for my task? If so (or not) can you point me in the right direction. I can totally understand instruction of type: open this, download that, extract and boot with to execute...etc. Too many technical terms will confuse me... I also understand if you don't have time to waste on an old guy and in that case just tell me to bug off... Thank you in advance. Cheers! Neb

1 0

W836xx: your board name: flashrom -V
by Mohit Keswani 05 Dec '15

05 Dec '15

Output for flashrom attached. Please support my board. I;ve bought the latest lenovo y700.

1 0

Re: [flashrom] Ch431 programmer
by Stefan Tauner 04 Dec '15

04 Dec '15

On Tue, 1 Dec 2015 09:25:46 +0200 Ran Weizman <ranwzmn(a)gmail.com> wrote: > Hi > Thanks a lot, unfortunately my chip model is not supported by Flashrom. And that won't change if you don't tell us what model it is :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 2

[PATCH 0/1] Add support for reading the current flash contents from a file
by Paul Kocialkowski 04 Dec '15

04 Dec '15

Here is an example script that I'm using to read the flash contents to a file once and update it as I flash newer versions of the software: #!/bin/sh flashrom="flashrom" programmer="ft2232_spi:type=openmoko,divisor=8" contents="~/flash-contents.img" image="$1" if [ -z $image ] then echo "Reading initial flash contents" timeb=$( date +%s ) $flashrom -p $programmer -r $contents timea=$( date +%s ) echo "Time: "$(( $timea - $timeb ))" seconds" else echo "Writing new flash contents" timeb=$( date +%s ) $flashrom -p $programmer -w $image -C $contents --noverify timea=$( date +%s ) cp $image $contents echo "Time: "$(( $timea - $timeb ))" seconds" fi

1 1

[PATCH v3 1/2] Add support for selecting the erased bit value with a flag
by Paul Kocialkowski 03 Dec '15

03 Dec '15

Most flash chips are erased to ones and programmed to zeros. However, some other flash chips, such as the ENE KB9012 internal flash, work the opposite way. Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- flash.h | 5 ++++- flashrom.c | 39 +++++++++++++++++++++------------------ 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/flash.h b/flash.h index 24861ba..8d557fe 100644 --- a/flash.h +++ b/flash.h @@ -123,6 +123,9 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_ERASED_ZERO (1 << 10) + +#define ERASED_VALUE(flash) (((flash)->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff) enum test_state { OK = 0, @@ -275,7 +278,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f int read_flash_to_file(struct flashctx *flash, const char *filename); char *extract_param(const char *const *haystack, const char *needle, const char *delim); int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value); void print_version(void); void print_buildinfo(void); void print_banner(void); diff --git a/flashrom.c b/flashrom.c index c9c7e31..bd8ef3f 100644 --- a/flashrom.c +++ b/flashrom.c @@ -673,12 +673,13 @@ int check_erased_range(struct flashctx *flash, unsigned int start, { int ret; uint8_t *cmpbuf = malloc(len); + const uint8_t erased_value = ERASED_VALUE(flash); if (!cmpbuf) { msg_gerr("Could not allocate memory!\n"); exit(1); } - memset(cmpbuf, 0xff, len); + memset(cmpbuf, erased_value, len); ret = verify_range(flash, cmpbuf, start, len); free(cmpbuf); return ret; @@ -731,7 +732,7 @@ out_free: } /* Helper function for need_erase() that focuses on granularities of gran bytes. */ -static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran) +static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran, const uint8_t erased_value) { unsigned int i, j, limit; for (j = 0; j < len / gran; j++) { @@ -741,7 +742,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig continue; /* have needs to be in erased state. */ for (i = 0; i < limit; i++) - if (have[j * gran + i] != 0xff) + if (have[j * gran + i] != erased_value) return 1; } return 0; @@ -761,7 +762,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig * @gran write granularity (enum, not count) * @return 0 if no erase is needed, 1 otherwise */ -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran) +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value) { int result = 0; unsigned int i; @@ -776,31 +777,31 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; case write_gran_1byte: for (i = 0; i < len; i++) - if ((have[i] != want[i]) && (have[i] != 0xff)) { + if ((have[i] != want[i]) && (have[i] != erased_value)) { result = 1; break; } break; case write_gran_128bytes: - result = need_erase_gran_bytes(have, want, len, 128); + result = need_erase_gran_bytes(have, want, len, 128, erased_value); break; case write_gran_256bytes: - result = need_erase_gran_bytes(have, want, len, 256); + result = need_erase_gran_bytes(have, want, len, 256, erased_value); break; case write_gran_264bytes: - result = need_erase_gran_bytes(have, want, len, 264); + result = need_erase_gran_bytes(have, want, len, 264, erased_value); break; case write_gran_512bytes: - result = need_erase_gran_bytes(have, want, len, 512); + result = need_erase_gran_bytes(have, want, len, 512, erased_value); break; case write_gran_528bytes: - result = need_erase_gran_bytes(have, want, len, 528); + result = need_erase_gran_bytes(have, want, len, 528, erased_value); break; case write_gran_1024bytes: - result = need_erase_gran_bytes(have, want, len, 1024); + result = need_erase_gran_bytes(have, want, len, 1024, erased_value); break; case write_gran_1056bytes: - result = need_erase_gran_bytes(have, want, len, 1056); + result = need_erase_gran_bytes(have, want, len, 1056, erased_value); break; case write_gran_1byte_implicit_erase: /* Do not erase, handle content changes from anything->0xff by writing 0xff. */ @@ -1424,6 +1425,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, unsigned int starthere = 0, lenhere = 0; int ret = 0, skip = 1, writecount = 0; enum write_granularity gran = flash->chip->gran; + const uint8_t erased_value = ERASED_VALUE(flash); /* curcontents and newcontents are opaque to walk_eraseregions, and * need to be adjusted here to keep the impression of proper abstraction @@ -1431,7 +1433,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, curcontents += start; newcontents += start; msg_cdbg(":"); - if (need_erase(curcontents, newcontents, len, gran)) { + if (need_erase(curcontents, newcontents, len, gran, erased_value)) { msg_cdbg("E"); ret = erasefn(flash, start, len); if (ret) @@ -1441,7 +1443,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, return -1; } /* Erase was successful. Adjust curcontents. */ - memset(curcontents, 0xff, len); + memset(curcontents, erased_value, len); skip = 0; } /* get_next_write() sets starthere to a new value after the call. */ @@ -1938,6 +1940,7 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, int ret = 0; unsigned long size = flash->chip->total_size * 1024; int read_all_first = 1; /* FIXME: Make this configurable. */ + const uint8_t erased_value = ERASED_VALUE(flash); if (chip_safety_check(flash, force, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -1964,15 +1967,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_gerr("Out of memory!\n"); exit(1); } - /* Assume worst case: All bits are 0. */ - memset(oldcontents, 0x00, size); + /* Assume worst case: All bits are not erased. */ + memset(oldcontents, ~erased_value, size); newcontents = malloc(size); if (!newcontents) { msg_gerr("Out of memory!\n"); exit(1); } - /* Assume best case: All bits should be 1. */ - memset(newcontents, 0xff, size); + /* Assume best case: All bits should be erased. */ + memset(newcontents, erased_value, size); /* Side effect of the assumptions above: Default write action is erase * because newcontents looks like a completely erased chip, and * oldcontents being completely 0x00 means we have to erase everything -- 1.9.1

2 5

Re: [flashrom] Ch431 programmer
by Stefan Tauner 01 Dec '15

01 Dec '15

On Thu, 26 Nov 2015 00:31:02 +0200 Ran Weizman <ranwzmn(a)gmail.com> wrote: > Hi, I have the CH341, device with version4.03, is Flashrom gonna support it > in the future ? > Can I help with something ? (I'm not a dev just Linux user. ) > Thanks > Ran Hi Ran, yes, and yes. You can test the existing patch for that programmer, see http://www.flashrom.org/pipermail/flashrom/2015-November/014009.html -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH] Rigorously check integrity of I/O stream data.
by Urja Rannikko 29 Nov '15

29 Nov '15

Hi, On Sun, Nov 22, 2015 at 7:43 PM, Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > Even if fwrite() succeeds the data is not necessarily out of the clib's buffers > and writing it eventually could fail. Even if the data is flushed out (explicitly by > fflush() or implicitly by fclose()) the kernel might still hold a buffer. > > Previously we have ignored this to a large extent - even in important cases > like writing the flash contents to a file. The results can be truncated > images that would brick the respective machine if written back as is (though > flashrom would not allow that due to a size mismatch). flashrom would not > indicate the problem in any output - so far we only check the return value > of fwrite() that is not conclusive. > > This patch checks the return values of all related system calls like fclose() > unless we only read the file and are not really interested in output errors. > In the latter case the return value is casted to void to document this fact. > Additionally, this patch explicitly calls fflush() and fsync() (on regular files only) > to do the best we can to guarantee the read image reaches the disk safely. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> > --- > flashrom.c | 67 +++++++++++++++++++++++++++++++++++++----------------- > layout.c | 6 ++--- > processor_enable.c | 4 ++-- > 3 files changed, 51 insertions(+), 26 deletions(-) > > diff --git a/flashrom.c b/flashrom.c > index c9c7e31..6e5fd68 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ -28,6 +28,7 @@ > #include <sys/stat.h> > #endif > #include <string.h> > +#include <unistd.h> > #include <stdlib.h> > #include <errno.h> > #include <ctype.h> > @@ -1255,36 +1256,39 @@ int read_buf_from_file(unsigned char *buf, unsigned long size, > msg_gerr("Error: No file I/O support in libpayload\n"); > return 1; > #else > - unsigned long numbytes; > - FILE *image; > - struct stat image_stat; > + int ret = 0; > > + FILE *image; > if ((image = fopen(filename, "rb")) == NULL) { > msg_gerr("Error: opening file \"%s\" failed: %s\n", filename, strerror(errno)); > return 1; > } > + > + struct stat image_stat; > if (fstat(fileno(image), &image_stat) != 0) { > msg_gerr("Error: getting metadata of file \"%s\" failed: %s\n", filename, strerror(errno)); > - fclose(image); > - return 1; > + ret = 1; > + goto out; > } > if (image_stat.st_size != size) { > msg_gerr("Error: Image size (%jd B) doesn't match the flash chip's size (%lu B)!\n", > (intmax_t)image_stat.st_size, size); > - fclose(image); > - return 1; > - } > - numbytes = fread(buf, 1, size, image); > - if (fclose(image)) { > - msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, strerror(errno)); > - return 1; > + ret = 1; > + goto out; > } > + > + unsigned long numbytes = fread(buf, 1, size, image); > if (numbytes != size) { > msg_gerr("Error: Failed to read complete file. Got %ld bytes, " > "wanted %ld!\n", numbytes, size); > - return 1; > + ret = 1; > } > - return 0; > +out: > + if (fclose(image)) { > + msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, strerror(errno)); > + ret = 1; > + } > + return ret; > #endif > } Why do this goto stuff and fclose fail reporting to read_buf_from_file? I'd suggest same handling as below for layout files etc (= (void)fclose()). > > @@ -1294,8 +1298,8 @@ int write_buf_to_file(const unsigned char *buf, unsigned long size, const char * > msg_gerr("Error: No file I/O support in libpayload\n"); > return 1; > #else > - unsigned long numbytes; > FILE *image; > + int ret = 0; > > if (!filename) { > msg_gerr("No filename specified.\n"); > @@ -1306,14 +1310,35 @@ int write_buf_to_file(const unsigned char *buf, unsigned long size, const char * > return 1; > } > > - numbytes = fwrite(buf, 1, size, image); > - fclose(image); > + unsigned long numbytes = fwrite(buf, 1, size, image); > if (numbytes != size) { > - msg_gerr("File %s could not be written completely.\n", > - filename); > - return 1; > + msg_gerr("Error: file %s could not be written completely.\n", filename); > + ret = 1; > + goto out; > } > - return 0; > + if (fflush(image)) { > + msg_gerr("Error: flushing file \"%s\" failed: %s\n", filename, strerror(errno)); > + ret = 1; > + } > + struct stat image_stat; > + if (fstat(fileno(image), &image_stat) != 0) { > + msg_gerr("Error: getting metadata of file \"%s\" failed: %s\n", filename, strerror(errno)); > + ret = 1; > + goto out; > + } > + /* Try to fsync only regular files. */ > + if (S_ISREG(image_stat.st_mode)) { > + if (fsync(fileno(image))) { > + msg_gerr("Error: fsyncing file \"%s\" failed: %s\n", filename, strerror(errno)); > + ret = 1; > + } > + } > +out: > + if (fclose(image)) { > + msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, strerror(errno)); > + ret = 1; > + } > + return ret; > #endif > } > > diff --git a/layout.c b/layout.c > index 0b9f6e5..d039451 100644 > --- a/layout.c > +++ b/layout.c > @@ -65,7 +65,7 @@ int read_romlayout(const char *name) > if (num_rom_entries >= MAX_ROMLAYOUT) { > msg_gerr("Maximum number of ROM images (%i) in layout " > "file reached.\n", MAX_ROMLAYOUT); > - fclose(romlayout); > + (void)fclose(romlayout); > return 1; > } > if (2 != fscanf(romlayout, "%s %s\n", tempstr, rom_entries[num_rom_entries].name)) > @@ -80,7 +80,7 @@ int read_romlayout(const char *name) > tstr2 = strtok(NULL, ":"); > if (!tstr1 || !tstr2) { > msg_gerr("Error parsing layout file. Offending string: \"%s\"\n", tempstr); > - fclose(romlayout); > + (void)fclose(romlayout); > return 1; > } > rom_entries[num_rom_entries].start = strtol(tstr1, (char **)NULL, 16); > @@ -95,7 +95,7 @@ int read_romlayout(const char *name) > rom_entries[i].end, rom_entries[i].name); > } > > - fclose(romlayout); > + (void)fclose(romlayout); > > return 0; > } > diff --git a/processor_enable.c b/processor_enable.c > index 1361dd5..117aa1e 100644 > --- a/processor_enable.c > +++ b/processor_enable.c > @@ -57,11 +57,11 @@ static int is_loongson(void) > ptr++; > while (*ptr && isspace((unsigned char)*ptr)) > ptr++; > - fclose(cpuinfo); > + (void)fclose(cpuinfo); > return (strncmp(ptr, "ICT Loongson-2 V0.3", strlen("ICT Loongson-2 V0.3")) == 0) || > (strncmp(ptr, "Godson2 V0.3 FPU V0.1", strlen("Godson2 V0.3 FPU V0.1")) == 0); > } > - fclose(cpuinfo); > + (void)fclose(cpuinfo); > return 0; > } > #endif > -- > Kind regards, Stefan Tauner > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom If you fix that (or convince me that you want to print reading fclose failure), this is acked by me. -- Urja Rannikko

1 0

W836xx: Dell Latitude E4310: flashrom -V
by Daniel Golle 27 Nov '15

27 Nov '15

flashrom v0.9.8-r1888 on Linux 4.2.5-1-ARCH (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.3.0, GCC 4.9.2 20150204 (prerelease), little endian Command line (3 args): flashrom -V -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 1563M loops per second, 10 myus = 11 us, 100 myus = 107 us, 1000 myus = 1003 us, 10000 myus = 10287 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Laptop" Laptop detected via DMI. DMI string system-manufacturer: "Dell Inc." DMI string system-product-name: "Latitude E4310" DMI string system-version: "0001" DMI string baseboard-manufacturer: "Dell Inc." DMI string baseboard-product-name: "0D8H24" DMI string baseboard-version: "A00" ========================================================================

1 0

Ch431 programmer
by Ran Weizman 25 Nov '15

25 Nov '15

Hi, I have the CH341, device with version4.03, is Flashrom gonna support it in the future ? Can I help with something ? (I'm not a dev just Linux user. ) Thanks Ran

1 0

Raspberry EN25F32
by Andrea Vinci 24 Nov '15

24 Nov '15

Hi, I’ve try to flash Eon flash chip "EN25F32” with flashrom on raspberry pi 2. The rpi found the programmer /dev/spidev0.0 but cannot recognise the chip. Someone else have the same problem or have try this? Thanks -- Andrea Vinci

1 0

Re: [flashrom] CH341 patch request
by Stefan Tauner 24 Nov '15

24 Nov '15

On Wed, 30 Sep 2015 15:18:12 +0200 Ádám Attila Nagy <osiixy(a)gmail.com> wrote: > Thank you! > That happens time to time but I am really grateful that you have even not > forgotten it. > > I am really looking forward to this cheapass programmer being arrived and > testing it with your code. Hi Ádám, here is a branch that should actually work: https://github.com/urjaman/flashrom/tree/ch341a -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

EN25F32 on raspberry 2
by Andrea Vinci 23 Nov '15

23 Nov '15

Hi, I read from http://www.flashrom.org/pipermail/flashrom/2014-September/012951.html that you have successful test the chip EN25F32 with flashrom. I try to flash this chip with a raspberry 2 but the software doesn’t recognise the chip. Can you give me more info about your test? I found this circuit, can you say me if it is right for my case? Thanks. -- Darka

1 0

Re: [flashrom] [PATCH] Rigorously check integrity of I/O stream data.
by Stefan Tauner 22 Nov '15

22 Nov '15

On Sun, 22 Nov 2015 18:29:34 +0100 Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > Nevertheless I think we should merge this patch ASAP. Or maybe with a goto from the error state of fwrite to the fclose call (skipping fflush and fsync if fwrite fails), because there is really no benefit of doing these calls in that case - it even produces one more error output when trying to fsync /dev/full... OTOH fsyncing often fails on non-regular files (e.g. /dev/null) even though everything works as intended... *sigh* -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 1

[PATCH] Rigorously check integrity of I/O stream data.
by Stefan Tauner 22 Nov '15

22 Nov '15

Even if fwrite() succeeds the data is not necessarily out of the clib's buffers and writing it eventually could fail. Even if the data is flushed out (explicitly by fflush() or implicitly by fclose()) the kernel might still hold a buffer. Previously we have ignored this to a large extent - even in important cases like writing the flash contents to a file. The results can be truncated images that would brick the respective machine if written back as is (though flashrom would not allow that due to a size mismatch). flashrom would not indicate the problem in any output - so far we only check the return value of fwrite() that is not conclusive. This patch checks the return values of all related system calls like fclose() unless we only read the file and are not really interested in output errors. In the latter case the return value is casted to void to document this fact. Additionally, this patch explicitly calls fflush() and fsync() to do the best we can to guarantee the read image reaches the disk safely. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- flashrom.c | 56 ++++++++++++++++++++++++++++++++++-------------------- layout.c | 6 +++--- processor_enable.c | 4 ++-- 3 files changed, 40 insertions(+), 26 deletions(-) The reason why I was investigating this at all was a user report on IRC that showed that flashrom on OpenWRT would create a truncated file if there is not enough space left on the file system to store the flash image file. After adding support for uclibc on our buildbot I was able to reproduce the problem. Unfortunately, checking the return value of fclose() does not help with uclibc, nor does calling fflush() or fsync() - uclibc is simply broken in this regard, cf.: https://bugs.gentoo.org/show_bug.cgi?id=543972 https://bugs.uclibc.org/5156 glibc and musl are not affected. Both notice the problem at fwrite() time. Nevertheless I think we should merge this patch ASAP. diff --git a/flashrom.c b/flashrom.c index c9c7e31..3b2388b 100644 --- a/flashrom.c +++ b/flashrom.c @@ -28,6 +28,7 @@ #include <sys/stat.h> #endif #include <string.h> +#include <unistd.h> #include <stdlib.h> #include <errno.h> #include <ctype.h> @@ -1255,36 +1256,39 @@ int read_buf_from_file(unsigned char *buf, unsigned long size, msg_gerr("Error: No file I/O support in libpayload\n"); return 1; #else - unsigned long numbytes; - FILE *image; - struct stat image_stat; + int ret = 0; + FILE *image; if ((image = fopen(filename, "rb")) == NULL) { msg_gerr("Error: opening file \"%s\" failed: %s\n", filename, strerror(errno)); return 1; } + + struct stat image_stat; if (fstat(fileno(image), &image_stat) != 0) { msg_gerr("Error: getting metadata of file \"%s\" failed: %s\n", filename, strerror(errno)); - fclose(image); - return 1; + ret = 1; + goto out; } if (image_stat.st_size != size) { msg_gerr("Error: Image size (%jd B) doesn't match the flash chip's size (%lu B)!\n", (intmax_t)image_stat.st_size, size); - fclose(image); - return 1; - } - numbytes = fread(buf, 1, size, image); - if (fclose(image)) { - msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, strerror(errno)); - return 1; + ret = 1; + goto out; } + + unsigned long numbytes = fread(buf, 1, size, image); if (numbytes != size) { msg_gerr("Error: Failed to read complete file. Got %ld bytes, " "wanted %ld!\n", numbytes, size); - return 1; + ret = 1; } - return 0; +out: + if (fclose(image)) { + msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, strerror(errno)); + ret = 1; + } + return ret; #endif } @@ -1294,8 +1298,8 @@ int write_buf_to_file(const unsigned char *buf, unsigned long size, const char * msg_gerr("Error: No file I/O support in libpayload\n"); return 1; #else - unsigned long numbytes; FILE *image; + int ret = 0; if (!filename) { msg_gerr("No filename specified.\n"); @@ -1306,14 +1310,24 @@ int write_buf_to_file(const unsigned char *buf, unsigned long size, const char * return 1; } - numbytes = fwrite(buf, 1, size, image); - fclose(image); + unsigned long numbytes = fwrite(buf, 1, size, image); if (numbytes != size) { - msg_gerr("File %s could not be written completely.\n", - filename); - return 1; + msg_gerr("Error: file %s could not be written completely.\n", filename); + ret = 1; } - return 0; + if (fflush(image)) { + msg_gerr("Error: flushing file \"%s\" failed: %s\n", filename, strerror(errno)); + ret = 1; + } + if (fsync(fileno(image))) { + msg_gerr("Error: fsyncing file \"%s\" failed: %s\n", filename, strerror(errno)); + ret = 1; + } + if (fclose(image)) { + msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, strerror(errno)); + ret = 1; + } + return ret; #endif } diff --git a/layout.c b/layout.c index 0b9f6e5..d039451 100644 --- a/layout.c +++ b/layout.c @@ -65,7 +65,7 @@ int read_romlayout(const char *name) if (num_rom_entries >= MAX_ROMLAYOUT) { msg_gerr("Maximum number of ROM images (%i) in layout " "file reached.\n", MAX_ROMLAYOUT); - fclose(romlayout); + (void)fclose(romlayout); return 1; } if (2 != fscanf(romlayout, "%s %s\n", tempstr, rom_entries[num_rom_entries].name)) @@ -80,7 +80,7 @@ int read_romlayout(const char *name) tstr2 = strtok(NULL, ":"); if (!tstr1 || !tstr2) { msg_gerr("Error parsing layout file. Offending string: \"%s\"\n", tempstr); - fclose(romlayout); + (void)fclose(romlayout); return 1; } rom_entries[num_rom_entries].start = strtol(tstr1, (char **)NULL, 16); @@ -95,7 +95,7 @@ int read_romlayout(const char *name) rom_entries[i].end, rom_entries[i].name); } - fclose(romlayout); + (void)fclose(romlayout); return 0; } diff --git a/processor_enable.c b/processor_enable.c index 1361dd5..117aa1e 100644 --- a/processor_enable.c +++ b/processor_enable.c @@ -57,11 +57,11 @@ static int is_loongson(void) ptr++; while (*ptr && isspace((unsigned char)*ptr)) ptr++; - fclose(cpuinfo); + (void)fclose(cpuinfo); return (strncmp(ptr, "ICT Loongson-2 V0.3", strlen("ICT Loongson-2 V0.3")) == 0) || (strncmp(ptr, "Godson2 V0.3 FPU V0.1", strlen("Godson2 V0.3 FPU V0.1")) == 0); } - fclose(cpuinfo); + (void)fclose(cpuinfo); return 0; } #endif -- Kind regards, Stefan Tauner

1 0

Image size doesn't match the flash chip's size
by Adam Nielsen 22 Nov '15

22 Nov '15

Hi all, I'm in the process of setting up a retro PC (a 286) and because the machine's BIOS doesn't support IDE drives, I am hoping to put the open source XTIDE BIOS in this machine as an option ROM. I have a network card that can make EEPROMs visible at the right memory locations, so all I need to do is flash the XTIDE code onto an EEPROM and install it in the old PC. I have an EEPROM I am planning to use for this (an SST29EE020) and I'm using a 3Com NIC to attempt to flash the XTIDE code into it. However when I try this, I get an error: Error: Image size (8192 B) doesn't match the flash chip's size (262144 B)! While I understand this would normally be a problem, for me it's fine - I'm only interested in the first 8kB and the rest of the chip is not important to me. But I couldn't find any options to tell flashrom to continue and flash anyway, and --force didn't help. My first thought was that perhaps I just need to pad the ROM image out so that it matches the chip size, but then I run into a problem. The chip is 256kB, but the 3Com NIC is apparently (according to flashrom) only capable of addressing up to 128kB. This means if I force it, the second 128kB (the padding) will probably just get written over the first 128kB, overwriting the data I want to keep. I guess I could pad out the 8kB XTIDE image to only 128kB, then double that to get a 256kB image, but it's all very kludgy! Since flashrom has options to erase the chip, would it be possible to add another option to allow partial flashing? This would allow me to flash my 8kB image without worrying about address wraparound or having to flash 248kB of blanks when I don't have to! BTW flashrom (latest stable) tells me the SST29EE020 is untested, so I would be happy to report back with my results, assuming you accept flashing a 256kB chip in a 128kB programmer as a valid test ;-) Many thanks, Adam.

2 3

[PATCH] Add support for SST25WF080B 1 MB flash.
by Ben Gardner 22 Nov '15

22 Nov '15

Apart from the JEDEC ID (621614) the difference from the SST25WF080 is that it lacks op codes 0xAD (AAI Word program) and 0x52 (32K erase). Tested under Linux with spidev. Signed-off-by: Ben Gardner <bgardner(a)wabtec.com> --- flashchips.c | 35 +++++++++++++++++++++++++++++++++++ flashchips.h | 3 ++- 2 files changed, 37 insertions(+), 1 deletion(-) diff --git a/flashchips.c b/flashchips.c index 8b5d1ec..b71bd2c 100644 --- a/flashchips.c +++ b/flashchips.c @@ -11803,6 +11803,41 @@ const struct flashchip flashchips[] = { { .vendor = "SST", + .name = "SST25WF080B", + .bustype = BUS_SPI, + .manufacture_id = SST_ID_62, + .model_id = SST_SST25WF080B, + .total_size = 1024, + .page_size = 256, + .feature_bits = FEATURE_WRSR_EITHER, + .tested = TEST_OK_PREW, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 256} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {64 * 1024, 16} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_sst25, /* *does* have a BP3 but it is useless */ + .unlock = spi_disable_blockprotect_bp3_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B) supported */ + .voltage = {1650, 1950}, + }, + + { + .vendor = "SST", .name = "SST28SF040A", .bustype = BUS_PARALLEL, .manufacture_id = SST_ID, diff --git a/flashchips.h b/flashchips.h index 07ae49d..d6b2b8d 100644 --- a/flashchips.h +++ b/flashchips.h @@ -659,6 +659,7 @@ * byte of device ID is related to log(bitsize) at least for some chips. */ #define SST_ID 0xBF /* SST */ +#define SST_ID_62 0x62 /* SST */ #define SST_SST25LF020_REMS 0x43 /* REMS or RES opcode */ #define SST_SST25WF512 0x2501 #define SST_SST25WF010 0x2502 @@ -669,7 +670,7 @@ * IDs and were not spotted in the wild yet. Their datasheets show a 4 byte long response w/o a vendor ID. */ #define SST_SST25WF020A /* 0x62 0x16 0x12 0x00 */ #define SST_SST25WF040B /* 0x62 0x16 0x13 0x00 */ -#define SST_SST25WF080B /* 0x62 0x16 0x14 0x00 */ +#define SST_SST25WF080B 0x1614 /* 0x62 0x16 0x14 0x00 */ #define SST_SST25VF512_REMS 0x48 /* REMS or RES opcode, same as SST25VF512A */ #define SST_SST25VF010_REMS 0x49 /* REMS or RES opcode, same as SST25VF010A */ #define SST_SST25VF020_REMS 0x43 /* REMS or RES opcode, same as SST25LF020A */ -- 1.9.1 This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

3 2

Re: [flashrom] flashrom on PowerPC
by Stefan Tauner 22 Nov '15

22 Nov '15

On Fri, 20 Nov 2015 17:16:44 +0100 Peter Lemenkov <lemenkov(a)gmail.com> wrote: > Hello All! > > 2011-10-23 0:20 GMT+02:00 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>: > > On Wed, 27 Jul 2011 18:20:19 +0200 > > Mattias Mattsson <vitplister(a)gmail.com> wrote: > > > >> Hi all, > >> > >> I was able to run flashrom under Linux on PPC (big endian) hardware > >> with two small modifications in internal.c and processor_enable.c (see > >> attached patch). Not sure if this is the right way to do it but it > >> seems to work for me. > >> > > > > i am resending this patch (unchanged) because patchwork did not pick it > > up correctly. please do send one patch per mail only in the future > > until we have something really working. :) > > Sorry for bringing up this again but what's the status of this? It > does works on old PPC-based Apple Macs and it still applies cleanly. > Maybe it's time to apply this, otherwise we won't see any potential > users very soon :) Hi Peter, it does not apply to the current version, but that's not the issue. It seems like a simple hack that was not thought through completely and I certainly won't merge it as is. IMHO the things mentioned in the comment in internal.c below the single hunk needs to be addressed first. I am not sure ATM what that even means and won't look into it soon. Also, I don't think it would even work in its current form (no programmer registration happens there that was introduced since the original patch)... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[commit] r1901 - trunk
by repository service 22 Nov '15

22 Nov '15

Author: stefanct Date: Sun Nov 22 03:23:31 2015 New Revision: 1901 URL: http://flashrom.org/trac/flashrom/changeset/1901 Log: Add support for SST SST25WF020A, SST25WF040B, SST25WF080B. Apart from the strange ID (using Sanyo's vendor ID 0x62) the main difference from the plain SST25WF series is that they lack op codes 0xAD (AAI Word program) and 0x52 (32K erase). The smallest version does not support dual I/O operations either. SST25WF080B was tested under Linux with spidev. Tested-by: Ben Gardner <bgardner(a)wabtec.com> Signed-off-by: Ben Gardner <bgardner(a)wabtec.com> Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Modified: trunk/chipdrivers.h trunk/flashchips.c trunk/flashchips.h trunk/spi25_statusreg.c Modified: trunk/chipdrivers.h ============================================================================== --- trunk/chipdrivers.h Sun Nov 22 00:35:47 2015 (r1900) +++ trunk/chipdrivers.h Sun Nov 22 03:23:31 2015 (r1901) @@ -72,6 +72,7 @@ int spi_prettyprint_status_register_bp3_srwd(struct flashctx *flash); int spi_prettyprint_status_register_bp4_srwd(struct flashctx *flash); int spi_prettyprint_status_register_bp2_bpl(struct flashctx *flash); +int spi_prettyprint_status_register_bp2_tb_bpl(struct flashctx *flash); int spi_disable_blockprotect(struct flashctx *flash); int spi_disable_blockprotect_bp1_srwd(struct flashctx *flash); int spi_disable_blockprotect_bp2_srwd(struct flashctx *flash); Modified: trunk/flashchips.c ============================================================================== --- trunk/flashchips.c Sun Nov 22 00:35:47 2015 (r1900) +++ trunk/flashchips.c Sun Nov 22 03:23:31 2015 (r1901) @@ -11857,6 +11857,111 @@ { .vendor = "SST", + .name = "SST25WF020A", + .bustype = BUS_SPI, + .manufacture_id = SANYO_ID, /* See flashchips.h */ + .model_id = SST_SST25WF020A, + .total_size = 256, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 64} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {64 * 1024, 4} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {256 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {256 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B) supported */ + .voltage = {1650, 1950}, + }, + + { + .vendor = "SST", + .name = "SST25WF040B", + .bustype = BUS_SPI, + .manufacture_id = SANYO_ID, /* See flashchips.h */ + .model_id = SST_SST25WF040B, + .total_size = 512, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 128} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {64 * 1024, 8} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {512 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {512 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B), dual O (0x3B), dual I/O read (0xBB) supported */ + .voltage = {1650, 1950}, + }, + + { + .vendor = "SST", + .name = "SST25WF080B", + .bustype = BUS_SPI, + .manufacture_id = SANYO_ID, /* See flashchips.h */ + .model_id = SST_SST25WF080B, + .total_size = 1024, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN, + .tested = TEST_OK_PREW, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 256} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {64 * 1024, 16} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B), dual O (0x3B), dual I/O read (0xBB) supported */ + .voltage = {1650, 1950}, + }, + + { + .vendor = "SST", .name = "SST25VF080B", .bustype = BUS_SPI, .manufacture_id = SST_ID, Modified: trunk/flashchips.h ============================================================================== --- trunk/flashchips.h Sun Nov 22 00:35:47 2015 (r1900) +++ trunk/flashchips.h Sun Nov 22 03:23:31 2015 (r1901) @@ -670,11 +670,12 @@ #define SST_SST25WF020 0x2503 #define SST_SST25WF040 0x2504 #define SST_SST25WF080 0x2505 -/* There exist some successors to members of the SST25WF family with alphabetic suffixes. They have very weird - * IDs and were not spotted in the wild yet. Their datasheets show a 4 byte long response w/o a vendor ID. */ -#define SST_SST25WF020A /* 0x62 0x16 0x12 0x00 */ -#define SST_SST25WF040B /* 0x62 0x16 0x13 0x00 */ -#define SST_SST25WF080B /* 0x62 0x16 0x14 0x00 */ +/* There exist some successors to members of the SST25WF family with alphabetic suffixes. Their datasheets show + * a 4 byte long response w/o a vendor ID. The first byte is 0x62 that is actually Sanyo's and might be due to + * a collaboration in the mid 2000ies between Sanyo and SST. */ +#define SST_SST25WF020A 0x1612 +#define SST_SST25WF040B 0x1613 +#define SST_SST25WF080B 0x1614 #define SST_SST25VF512_REMS 0x48 /* REMS or RES opcode, same as SST25VF512A */ #define SST_SST25VF010_REMS 0x49 /* REMS or RES opcode, same as SST25VF010A */ #define SST_SST25VF020_REMS 0x43 /* REMS or RES opcode, same as SST25LF020A */ Modified: trunk/spi25_statusreg.c ============================================================================== --- trunk/spi25_statusreg.c Sun Nov 22 00:35:47 2015 (r1900) +++ trunk/spi25_statusreg.c Sun Nov 22 03:23:31 2015 (r1901) @@ -374,6 +374,19 @@ return 0; } +int spi_prettyprint_status_register_bp2_tb_bpl(struct flashctx *flash) +{ + uint8_t status = spi_read_status_register(flash); + spi_prettyprint_status_register_hex(status); + + spi_prettyprint_status_register_bpl(status); + spi_prettyprint_status_register_bit(status, 6); + msg_cdbg("Chip status register: Top/Bottom (TB) is %s\n", (status & (1 << 5)) ? "bottom" : "top"); + spi_prettyprint_status_register_bp(status, 2); + spi_prettyprint_status_register_welwip(status); + return 0; +} + /* === Amic === * FIXME: spi_disable_blockprotect is incorrect but works fine for chips using * spi_prettyprint_status_register_bp1_srwd or

1 0

Re: [flashrom] Winbond flash chip "W39V080FA" (1024 kB, FWH)
by Stefan Tauner 22 Nov '15

22 Nov '15

On Sun, 22 Nov 2015 00:37:20 +0100 "Fabian Hoffmann" <fab1997(a)gmx.net> wrote: > Habe seit kurzem ein neues Mainboard und kann den Command deshalb leider nicht ausführen. Das alte MB funktioniert aber noch. OK, if you ever happen to start it up again please think of flashrom ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

SST49LF040B
by Rikard Åhlund 22 Nov '15

22 Nov '15

Flash Chip : SST49LF040B Mainboard : NF-M2S (Acer E380) Erase And Write Tested and working

2 1

CHIPSET: ASRock N68C-S UCC
by Alexey Belyaev 22 Nov '15

22 Nov '15

Здравствуйте, Flashrom. BIOS image was readed successfully! http://www.asrock.com/mb/NVIDIA/N68C-S%20UCC/index.ru.asp $ lspci 00:00.0 RAM memory: NVIDIA Corporation MCP61 Host Bridge (rev a1) 00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2) 00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2) 00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2) 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3) 00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3) 00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1) 00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2) 00:06.0 IDE interface: NVIDIA Corporation MCP61 IDE (rev a2) 00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2) 00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2) 00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2) 00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) 00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) 00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) 00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] (rev a2) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control 01:08.0 Network controller: Ralink corp. RT5360 Wireless 802.11n 1T/1R 01:0a.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) -- С уважением, Alexey mailto:spider@spider.vc

2 3

Re: [flashrom] Flash chip/chipset not found
by Stefan Tauner 22 Nov '15

22 Nov '15

Hi Mark, thanks for the testing! We have merged the patch with r1900 now and marked the chipset as supported. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] Winbond flash chip "W39V080FA" (1024 kB, FWH)
by Stefan Tauner 22 Nov '15

22 Nov '15

On Tue, 3 Nov 2015 14:47:37 +0100 "Fabian Hoffmann" <fab1997(a)gmx.net> wrote: > Hello, you may be interested on the following log. > My system: > OS: Arch Linux 64-Bit > Mainboard: ASUS P5LD2-VM/S 4.00g (MAXDATA OEM-Board, pretty rare I think. It is not listed on the ASUS page.) > CPU: Intel Core 2 Duo E4400 @ 2 GHz > > Flash read went almost fine, I was able to extract the bootlogo out of the rom file, but the MD5 hash sum of the rom file didn't match with an original rom file. Hi Fabian, you should be able to use the code that supports other versions of the P5LD2-VM mainboard to enable writing. Something like this: flashrom --programmer internal:mainboard="ASUS:P5LD2-VM DH" -w modded0404.rom -o ./flashrom-write.txt Should work, I think. Can you please provide us with the output of the following command so that we can add auto-detection for your version too. lspci -nnxxxvv The MD5 mismatch might be normal. The BIOS might use the flash memory as persistent storage area... that is common nowadays. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[commit] r1900 - trunk
by repository service 22 Nov '15

22 Nov '15

Author: stefanct Date: Sun Nov 22 00:35:47 2015 New Revision: 1900 URL: http://flashrom.org/trac/flashrom/changeset/1900 Log: Add support for VIA VT8251. Seems to work on IBM SurePOS 700 and IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. Tested-by: Jason Vannest <Jason_Vannest(a)abercrombie.com> Tested-by: Rowlinson Mark <Mark.Rowlinson(a)uk.fujitsu.com> Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/chipset_enable.c Modified: trunk/chipset_enable.c ============================================================================== --- trunk/chipset_enable.c Sat Nov 14 03:55:22 2015 (r1899) +++ trunk/chipset_enable.c Sun Nov 22 00:35:47 2015 (r1900) @@ -1582,6 +1582,7 @@ {0x1106, 0x3147, OK, "VIA", "VT8233A", enable_flash_vt823x}, {0x1106, 0x3177, OK, "VIA", "VT8235", enable_flash_vt823x}, {0x1106, 0x3227, OK, "VIA", "VT8237(R)", enable_flash_vt823x}, + {0x1106, 0x3287, OK, "VIA", "VT8251", enable_flash_vt823x}, {0x1106, 0x3337, OK, "VIA", "VT8237A", enable_flash_vt823x}, {0x1106, 0x3372, OK, "VIA", "VT8237S", enable_flash_vt8237s_spi}, {0x1106, 0x8231, NT, "VIA", "VT8231", enable_flash_vt823x},

1 0

Asus M2N-MX/DVI2
by Лисовой Игорь 21 Nov '15

21 Nov '15

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom