flashrom November 2015

flashrom@flashrom.org

27 participants
78 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom November 2015