flashrom July 2013

flashrom@flashrom.org

31 participants
142 discussions

Re: [flashrom] W836xx: Supermicro X8DTG-D: flashrom -V
by Stefan Tauner 22 Jul '13

22 Jul '13

On Mon, 22 Jul 2013 16:01:55 -0400 "Mueller, Daniel" <DANIEL.MUELLER(a)saic.com> wrote: > Today I tested flashrom on a Supermicro X8DTG-D motherboard. Below are > the commands I ran, a link to their output, and any of my notes on that > step. > > > Test environment: 64 bit CentOS 6 image booted via PXE, linux kernel > 2.6.32-358.6.1, Supermicro X8DTG-D with BIOS Rev. 2.1a > > `flashrom -p internal -V` http://paste.flashrom.org/view.php?id=1702 > > `lspci -nnvvxxx` http://paste.flashrom.org/view.php?id=1703 > > `superiotool -deV` http://paste.flashrom.org/view.php?id=1704 > > `flashrom -V -r x8dtg-bak.bin -p internal` > http://paste.flashrom.org/view.php?id=1707 > > `flashrom -V -w X8DTG.21A` http://paste.flashrom.org/view.php?id=1708 > > Note: The BIOS binary released by Supermicro, Rev. 2.1a. > > At this point, I rebooted the system to verify the write was successful > and see if any settings were changed. > > `flashrom -V -v X8DTG.21A -p internal` > http://pase.flashrom.org/view.php?id=1705 > > Note: The return code was 255 > > > > Is it normal behavior to have the verify operation succeed after a > write, but fail after a reboot? Hello Daniel, thanks for your report! I have added your board to our list of supported hardware and will commit that later together with other small changes. The behavior you have been seeing is normal. The firmware often writes some kind of log data to the flash chip on boot, hence the verification error. If you compare a file read after writing and after rebooting in a hex editor then they should be very similar. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

W836xx: Supermicro X8DTG-D: flashrom -V
by Mueller, Daniel 22 Jul '13

22 Jul '13

Good afternoon, Today I tested flashrom on a Supermicro X8DTG-D motherboard. Below are the commands I ran, a link to their output, and any of my notes on that step. Test environment: 64 bit CentOS 6 image booted via PXE, linux kernel 2.6.32-358.6.1, Supermicro X8DTG-D with BIOS Rev. 2.1a `flashrom -p internal -V` http://paste.flashrom.org/view.php?id=1702 `lspci -nnvvxxx` http://paste.flashrom.org/view.php?id=1703 `superiotool -deV` http://paste.flashrom.org/view.php?id=1704 `flashrom -V -r x8dtg-bak.bin -p internal` http://paste.flashrom.org/view.php?id=1707 `flashrom -V -w X8DTG.21A` http://paste.flashrom.org/view.php?id=1708 Note: The BIOS binary released by Supermicro, Rev. 2.1a. At this point, I rebooted the system to verify the write was successful and see if any settings were changed. `flashrom -V -v X8DTG.21A -p internal` http://pase.flashrom.org/view.php?id=1705 Note: The return code was 255 Is it normal behavior to have the verify operation succeed after a write, but fail after a reboot? Daniel Mueller Systems Engineering co-op

1 0

Flashrom works with GA-P55A-UD7
by goodgod261 22 Jul '13

22 Jul '13

Hi, I've successfully flashed my Gigabyte GA-P55A-UD7 with flashrom (svn 1701)! Flashrom reported an error when erasing chip, but everything worked fine. Three flash chips have been detected with one physical address and the same contents. Flashing the first one changed all of them, so it's probably a bug. It might related to Gigabyte's DualBIOS. By the way, wouldn't it be relatively easy to port Coreboot to motherboards with DualBIOS? I attach output of: * flashrom -p internal -V * lspci -nnvvxxx * superiotool -deV * flashrom -p internal -c MX25L1605 -w P55AUD7.F8B -V Best regards, goodgod261

2 2

Re: [flashrom] Sapphire IPC-E350M1 mainboard read success
by Stefan Tauner 21 Jul '13

21 Jul '13

On Fri, 19 Jul 2013 19:24:36 +0400 Антон Кочков <anton.kochkov(a)gmail.com> wrote: > Just downloaded flashrom trunk and tried to read > http://paste.flashrom.org/view.php?id=1695 - as you can see it fails very interesting result (with r1701). Thanks for testing that. Can you please test r1700, and if that does not help r1697? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 1

serprog with arduino UNO
by Hugo Petrucci 20 Jul '13

20 Jul '13

Hi, I followed the steps in this link http://flashrom.org/Serprog/Arduino_flasher for write the SST25LF040A flash chip run first time and asked to specify which chip was using run specifying the chip, the error not found the chip follows the commands executed hugo@hugo-linux ~/flashrom $ sudo ./flashrom -p serprog:dev=/dev/ttyACM0:2000000 flashrom v0.9.6.1-r1701 on Linux 3.5.0-17-generic (i686) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. serprog: Programmer name is "serprog-duino" Found SST flash chip "SST25LF040A" (512 kB, SPI) on serprog. Found SST flash chip "SST25VF040" (512 kB, SPI) on serprog. Multiple flash chips were detected: "SST25LF040A", "SST25VF040" Please specify which chip to use with the -c <chipname> option. specified the chip and verbose hugo@hugo-linux ~/flashrom $ sudo ./flashrom -c "SST25LF040A" -V -p serprog:dev=/dev/ttyACM0:2000000 flashrom v0.9.6.1-r1701 on Linux 3.5.0-17-generic (i686) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.9, GCC 4.7.2, little endian Command line (5 args): ./flashrom -c SST25LF040A -V -p serprog:dev=/dev/ttyACM0:2000000 Calibrating delay loop... OS timer resolution is 1 usecs, 1004M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 myus = 10002 us, 4 myus = 4 us, OK. Initializing serprog programmer Baud rate is 2000000. serprog: connected - attempting to synchronize ..... serprog: Synchronized serprog: Interface version ok. serprog: Bus support: parallel=off, LPC=off, FWH=off, SPI=on Warning: Automatic command availability check failed for cmd 0x08 - won't execute cmd Warning: Automatic command availability check failed for cmd 0x11 - won't execute cmd serprog: Programmer name is "serprog-duino" serprog: Serial buffer size is 65535 serprog: Warning: Programmer does not support toggling its output drivers The following protocols are supported: SPI. Probing for SST SST25LF040A, 512 kB: probe_spi_res2: id1 0x0, id2 0x0 No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.

3 4

[PATCH] Makefile: Print data model of C types.
by Stefan Tauner 20 Jul '13

20 Jul '13

Since we are starting to support more data models and are reworking some core data types in flashrom, it might become useful to know the size of some types, hence print them at compile and run time. Because compilers do not define suitable macros for this purpose, we implement our own in arch.h and the Makefile. Because sizeof is not evaluated by the CPP, the implementation uses macros from limits.h, stdint.h and hardcoded constants. See also http://sourceforge.net/p/predef/wiki/DataModels/ Also, simplify the __FLASHROM_ARCH__ generation and parsing, and refine sysinfo printing if uname is unavailable. New output w/o uname: flashrom v0.9.6.1-r1701 on Windows 5.1 (x86 ILP32) flashrom v0.9.6.1-r1701 on Windows 5.1 (x86_64 LLP64) flashrom v0.9.6.1-r1701 on unknown OS (arm ILP32) flashrom v0.9.6.1-r1701 on unknown OS (ppc ILP32) flashrom v0.9.6.1-r1701 on unknown OS (x86 LP64) flashrom v0.9.6.1-r1701 on unknown OS (x86 ILP32) w/ uname: flashrom v0.9.6.1-r1701 on Windows 5.1 (x86 ILP32) flashrom v0.9.6.1-r1701 on Windows 5.1 (x86_64 LLP64) flashrom v0.9.6.1-r1701 on Linux 2.6.32 (armv7l ILP32) flashrom v0.9.6.1-r1701 on Linux 2.6.32 (ppc ILP32) flashrom v0.9.6.1-r1701 on Linux 3.8.0-6-generic (x86_64 LP64) flashrom v0.9.6.1-r1701 on Linux 3.8.0-6-generic (x86_64 ILP32) Handcrafted "unknown" example: flashrom v0.9.6.1-r1701 on Linux 3.8.0-6-generic (x86_64 unknown data model) Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- Makefile | 9 +++++++-- arch.h | 22 +++++++++++++++++++++- flashrom.c | 19 ++++++++++--------- 3 files changed, 38 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 0cd4e75..5e54c9f 100644 --- a/Makefile +++ b/Makefile @@ -267,7 +267,12 @@ endif # IMPORTANT: The following line must be placed before ARCH is ever used # (of course), but should come after any lines setting CC because the line # below uses CC itself. -override ARCH := $(strip $(shell LC_ALL=C $(CC) $(CPPFLAGS) -E arch.h 2>/dev/null | grep -v '^\#' | grep '"' | cut -f 2 -d'"')) +override ARCH := $(shell LC_ALL=C $(CC) $(CPPFLAGS) -E arch.h 2>/dev/null | grep '"__FLASHROM_ARCH__"' | cut -f 4 -d'"') +FLASHROM_CFLAGS += -D'FLASHROM_ARCH="$(ARCH)"' + +# As above but for the C data model +override DATAMODEL := $(shell LC_ALL=C $(CC) $(CPPFLAGS) -E arch.h 2>/dev/null | grep '"__FLASHROM_DATAMODEL__"' | cut -f 4 -d'"') +FLASHROM_CFLAGS += -D'FLASHROM_DATAMODEL="$(DATAMODEL)"' # PCI port I/O support is unimplemented on PPC/MIPS and unavailable on ARM. # Right now this means the drivers below only work on x86. @@ -692,7 +697,7 @@ compiler: featuresavailable @# FreeBSD wc will output extraneous whitespace. @echo $(ARCH)|wc -w|grep -q '^[[:blank:]]*1[[:blank:]]*$$' || \ ( echo "unknown. Aborting."; exit 1) - @printf "%s\n" '$(ARCH)' + @printf "%s %s\n" '$(ARCH)' '$(DATAMODEL)' @printf "Target OS is " @# FreeBSD wc will output extraneous whitespace. @echo $(TARGET_OS)|wc -w|grep -q '^[[:blank:]]*1[[:blank:]]*$$' || \ diff --git a/arch.h b/arch.h index f3f3b0d..1ed13fb 100644 --- a/arch.h +++ b/arch.h @@ -21,6 +21,25 @@ * Header file for CPU architecture checking. */ +#include <limits.h> +#include <stdint.h> +#define __16b 0xFFFFULL +#define __32b 0xFFFFFFFFULL +#define __64b 0xFFFFFFFFFFFFFFFFULL +#if (UINT_MAX == __16b && ULONG_MAX == __32b && UINTPTR_MAX == __32b) +#define __FLASHROM_DATAMODEL__ "LP32" +#elif (UINT_MAX == __32b && ULONG_MAX == __32b && UINTPTR_MAX == __32b) +#define __FLASHROM_DATAMODEL__ "ILP32" +#elif (UINT_MAX == __32b && ULONG_MAX == __32b && UINTPTR_MAX == __64b) +#define __FLASHROM_DATAMODEL__ "LLP64" +#elif (UINT_MAX == __32b && ULONG_MAX == __64b && UINTPTR_MAX == __64b) +#define __FLASHROM_DATAMODEL__ "LP64" +#elif (UINT_MAX == 8 && ULONG_MAX == __64b && UINTPTR_MAX == __64b) +#define __FLASHROM_DATAMODEL__ "ILP64" +#else +#define __FLASHROM_DATAMODEL__ "unknown data model" +#endif + #if defined (__i386__) || defined (__x86_64__) #define __FLASHROM_ARCH__ "x86" #elif defined (__mips) || defined (__mips__) || defined (_mips) || defined (mips) @@ -30,4 +49,5 @@ #elif defined(__arm__) #define __FLASHROM_ARCH__ "arm" #endif -__FLASHROM_ARCH__ +"__FLASHROM_ARCH__"=__FLASHROM_ARCH__ +"__FLASHROM_DATAMODEL__"=__FLASHROM_DATAMODEL__ diff --git a/flashrom.c b/flashrom.c index b05faf3..8a9b185 100644 --- a/flashrom.c +++ b/flashrom.c @@ -1578,40 +1578,41 @@ void list_programmers_linebreak(int startcol, int cols, int paren) void print_sysinfo(void) { +msg_ginfo(" on "); #ifdef _WIN32 SYSTEM_INFO si; OSVERSIONINFOEX osvi; memset(&si, 0, sizeof(SYSTEM_INFO)); memset(&osvi, 0, sizeof(OSVERSIONINFOEX)); - msg_ginfo(" on Windows"); + msg_ginfo("Windows "); /* Tell Windows which version of the structure we want. */ osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX); if (GetVersionEx((OSVERSIONINFO*) &osvi)) - msg_ginfo(" %lu.%lu", osvi.dwMajorVersion, osvi.dwMinorVersion); + msg_ginfo("%lu.%lu", osvi.dwMajorVersion, osvi.dwMinorVersion); else - msg_ginfo(" unknown version"); + msg_ginfo("unknown version"); GetSystemInfo(&si); switch (si.wProcessorArchitecture) { case PROCESSOR_ARCHITECTURE_AMD64: - msg_ginfo(" (x86_64)"); + msg_ginfo(" (x86_64"); break; case PROCESSOR_ARCHITECTURE_INTEL: - msg_ginfo(" (x86)"); + msg_ginfo(" (x86"); break; default: - msg_ginfo(" (unknown arch)"); + msg_ginfo(" (unknown arch"); break; } #elif HAVE_UTSNAME == 1 struct utsname osinfo; uname(&osinfo); - msg_ginfo(" on %s %s (%s)", osinfo.sysname, osinfo.release, - osinfo.machine); + msg_ginfo("%s %s (%s", osinfo.sysname, osinfo.release, osinfo.machine); #else - msg_ginfo(" on unknown machine"); + msg_ginfo("unknown OS (" FLASHROM_ARCH); #endif + msg_ginfo(" " FLASHROM_DATAMODEL ")"); } void print_buildinfo(void) -- Kind regards, Stefan Tauner

1 0

Re: [flashrom] New development guidelines after 0.9.7
by Stefan Tauner 19 Jul '13

19 Jul '13

On Fri, 19 Jul 2013 16:35:14 -0700 David Hendricks <dhendrix(a)google.com> wrote: > On Fri, Jul 19, 2013 at 4:31 AM, Stefan Tauner < > stefan.tauner(a)student.tuwien.ac.at> wrote: > > > I think it is a bit sad that almost all discussion in this thread is > > focused on the VCS to use and not about the guidelines. Apparently > > emotions regarding the tools are much more intense than about the > > created work. > > > > Maybe it's a sign? > > (Hint: re-read *all* the stuff you wrote, and then reconsider what Marc > said about automation) It certainly is a sign of frustration, but if I look at coreboot reviews I would even feel vindicated that the tools are not so important and one needs to set some rules, because frankly speaking... the coreboot review process has become pretty crappy lately AFAICS (but I am not that involved, maybe it was always like that). Things like Peter's patch that got merged although he did not want that and that he reverted afterwards etc. are a clear sign that there are some missing rules IMHO :) And, even if we would switch to gerrit and git, I don't see how that would influence the guidelines I proposed very much. Yes, maybe there would be more reviewing and that would ease the problem of endless patch queues, but that would just be the same uncontrolled process - just faster. So while I recognize the wish for changing tools, the pain would not go away just by switching them and we should discuss the process nevertheless :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH 5/7] Combine serialport_write and serialport_read into serialport_rw.
by Carl-Daniel Hailfinger 19 Jul '13

19 Jul '13

Am 10.07.2013 21:21 schrieb Stefan Tauner: > Because they share almost all code, combine them into serialport_rw > and export the old functions as wrappers. This makes reads "empty reads"- > aware and programmers able to detect such problems even on "blocking" > reads. Also, this fixes error detection on Windows. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > serial.c | 83 ++++++++++++++++++++++++++++++---------------------------------- > 1 file changed, 39 insertions(+), 44 deletions(-) > > diff --git a/serial.c b/serial.c > index 1b394cd..5f74fd1 100644 > --- a/serial.c > +++ b/serial.c > @@ -328,66 +330,59 @@ int serialport_shutdown(void *data) > return 0; > } > > -int serialport_write(unsigned char *buf, unsigned int writecnt) > +#define EMPTY_TRIES 10 A total of 10 ms timeout is too fast for the Bus Pirate and some slower serprog implementations AFAICS. I'd prefer a 1 s timeout before signaling an error. That should be sufficient, and callers are supposed to check for errors, so the 1 s timeout won't happen multiple times. > +/* Writes (if \c outdir is true) or reads \c todo bytes from/into \c buf. > + * Tries up to \c EMPTY_TRIES times with a timeout of \c ms ms between each try. */ > +static int serialport_rw(unsigned char *buf, unsigned int todo, bool outdir, unsigned int ms) > { > -#ifdef _WIN32 > - DWORD tmp = 0; > -#else > - ssize_t tmp = 0; > -#endif > - unsigned int empty_writes = 250; /* results in a ca. 125ms timeout */ > + const char * const op = outdir ? "write" : "read"; > + bool err = false; > + unsigned int empty_tries = EMPTY_TRIES; > > - while (writecnt > 0) { > + while (todo > 0) { > #ifdef _WIN32 > - WriteFile(sp_fd, buf, writecnt, &tmp, NULL); > + DWORD cur = 0; > + if (outdir) > + err = !WriteFile(sp_fd, buf, todo, &cur, NULL); > + else > + err = !ReadFile(sp_fd, buf, todo, &cur, NULL); Should we check for cur == 0 here? Can that happen? > #else > - tmp = write(sp_fd, buf, writecnt); > -#endif > - if (tmp == -1) { > - msg_perr("Serial port write error!\n"); > + ssize_t cur = 0; > + if (outdir) > + err = (cur = write(sp_fd, buf, todo)) < 0; OK. > + else > + err = (cur = read(sp_fd, buf, todo)) < 0; Should be <= 0 instead of < 0 AFAICS. See the POSIX man page of read(): "When attempting to read from an empty pipe or FIFO: If no process has the pipe open for writing, read() shall return 0 to indicate end-of-file." > +#endif > + if (err) { > + msg_perr("Serial port %s error!\n", op); > return 1; > } > - if (!tmp) { > - msg_pdbg2("Empty write\n"); > - empty_writes--; > - programmer_delay(500); > - if (empty_writes == 0) { > - msg_perr("Serial port is unresponsive!\n"); > + if (cur == 0) { > + msg_pdbg2("Empty %s.\n", op); > + empty_tries--; > + programmer_delay(ms * 1000); > + if (empty_tries == 0) { > + msg_perr("Serial port is unresponsive or disappeared!\n"); > return 1; > } > + continue; > } > - writecnt -= tmp; > - buf += tmp; > + todo -= cur; > + buf += cur; > + empty_tries = EMPTY_TRIES; > } > > return 0; > } > > -int serialport_read(unsigned char *buf, unsigned int readcnt) > +int serialport_write(unsigned char *buf, unsigned int writecnt) > { > -#ifdef _WIN32 > - DWORD tmp = 0; > -#else > - ssize_t tmp = 0; > -#endif > - > - while (readcnt > 0) { > -#ifdef _WIN32 > - ReadFile(sp_fd, buf, readcnt, &tmp, NULL); > -#else > - tmp = read(sp_fd, buf, readcnt); > -#endif > - if (tmp == -1) { > - msg_perr("Serial port read error!\n"); > - return 1; > - } > - if (!tmp) > - msg_pdbg2("Empty read\n"); > - readcnt -= tmp; > - buf += tmp; > - } > + return serialport_rw(buf, writecnt, true, 1); > +} > > - return 0; > +int serialport_read(unsigned char *buf, unsigned int readcnt) > +{ > + return serialport_rw(buf, readcnt, false, 10); > } > > /* Tries up to timeout ms to read readcnt characters and places them into the array starting at c. Returns Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

New development guidelines after 0.9.7
by Stefan Tauner 19 Jul '13

19 Jul '13

Our current development model with elaborate reviews has not been working for a while now. Therefore, beginning with the release of flashrom 0.9.7 our strategy on merging patches will change radically. The current rules regarding committing to subversion can be found here: http://flashrom.org/Development_Guidelines#Committing Essentially they prohibit merging non-trivial patches without explicit consent from another community member and is not too specific on the requirements for an ack. Below is my proposal for the new rules which works with implicit consent after timeouts. The exact time values are completely open for discussion of course. I would also like to introduce some kind of stable branch where we can commit important backported patches, if need be, without releasing all non-critical fixes committed in the meantime (as was the case with 0.9.6.1 for example). I would not have a problem doing this with git, but I am not so sure if I want to try that with svn... let's pretend there is a community consensus to continue with svn for now. Is that sensible to do? AFAIK this would produce odd revision numbers (which is one of the main arguments pro svn). I would also like to clean up the commit permissions and name the ones with commit rights in the wiki. IMHO the following ppl should have commit rights: carldani, stefanct, dhendrix, kmalkki, idwer I am not sure about uwe and twice11, because they are (sadly) not even active on IRC or the ml. Everyone else's permission should be revoked. = Reviews = Contributors without commit rights should receive at least a preliminary review within one week of submission by some committer. At minimum this should include a broad indication of acceptance or rejection of... * the idea/rationale/motivation, * the implementation respectively. In general, reviews should focus on the architectural changes and things that affect flashrom as a whole. This includes (but is by no means limited to) changes in APIs and types, safety, portability, extensibility, and maintainability. The purpose of reviews is not to create perfect patches, but to steer development in the right direction and produce consensus within the community. The goal of each patch should be to improve the state of the project - it does not need to fix all problems of the respective field perfectly. NB: New contributors may need more detailed advices and should be told about minor issues like formatting problems more precisely. The result of a review should either be a == Acked-by == * Trivial stuff like... ** compile fixes (that are tested on all or at least some affected and some ''unaffected'' platforms), ** marking boards/chips/programmers as tested, and ** typo and whitespace fixes etc. :do not need an Acked-by line from someone else than the author. * If the patch is something like a board enable, new chip(set) support etc. (i.e. no refactoring, no architectural impact), you can get an ack from someone who is not an experienced developer after he/she has tested the patch, or ack yourself if proof exists that it worked. * However, for more complicated patches you should get a review from someone who knows the code well if possible. ** If no one replies to the patch submission on the mailing list within 2 weeks, you may assume consent by the community and ack yourself. ** If, however, one of the known community members comments on your submission and requests changes or further information/a rationale etc., you need to come to some consensus with that member about the points complained about (only). *** If your answer (e.g. in form of a new iteration of the patch including the requested changes or a mail containing the requested information) does not get any replies for three weeks, you may ack yourself. *** When consensus in all points have been reached, but no explicit ack has been sent, then the submission falls under the same timeout rule again; i.e. if no one replies to your last e-mail within 2 weeks, you may ack yourself. * Contributions from people without commit rights should not be treated much differently. : Maintainers should merge them if there is no objection from the community within the timeframes and according to the rule set described above. = Committing = Those with commit rights to the (currently subversion-based) source repository should follow the following rules. * Reviews ** Changes should generally be discussed and reviewed before committing, see [[Development_Guidelines#Reviews|above]] * The commit log ** Should start with a short sentence summing up the changes of the patch. ** Optionally this should be prefixed with a topic or file name if the changes are targeting one area only. ** End the sentence with a full stop followed by an empty line. ** The body of the commit log should be short, but descriptive: If anyone involved in flashrom reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code (what was the motivation for the change? what are the differences to the previous behavior?). ** At the end it has to list Signed-off-by lines of all authors and at least one Acked-by line. ** Optionally one can add Tested-by lines to give credit to testers. * Committing ** If you ack something and the sender has commit rights, let him commit unless he asks you to commit. *: If the sender does not have commit rights, wait at least 24 hours after sending the ack to give him/her an opportunity to add final refinements or comments. ** After committing please reply to the mailing thread that contains the patch with at least the revision in the body to notify anyone involved of the commit and document it for references in the future and in patchwork or similar facilities. * Don't share your login(s)/password(s) (should be obvious, but sadly it is not for everyone :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 5

Re: [flashrom] Sapphire IPC-E350M1 mainboard read success
by Антон Кочков 19 Jul '13

19 Jul '13

Just downloaded flashrom trunk and tried to read http://paste.flashrom.org/view.php?id=1695 - as you can see it fails Best regards, Anton Kochkov. On Tue, Apr 16, 2013 at 4:20 PM, Антон Кочков <anton.kochkov(a)gmail.com> wrote: > Reading flash http://paste.flashrom.org/view.php?id=1607 > Writing flash http://paste.flashrom.org/view.php?id=1608 > Best regards, > Anton Kochkov. > > > On Tue, Apr 16, 2013 at 4:06 PM, Антон Кочков <anton.kochkov(a)gmail.com> wrote: >> Here is full read log on trunk flashrom >> https://mega.co.nz/#!ndQhQLxL!NgMxOTwHi_oCGUD0663wjXKIcQoGWO1VU_XnXM_sY50 >> >> Sorry for using fileshare service, but full log is about 75Mb. >> >> Best regards, >> Anton Kochkov.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom July 2013