flashrom May 2013

flashrom@flashrom.org

30 participants
97 discussions

mac address problem with nvidia MCP55V-Pro
by Jon Morby 02 Jun '13

02 Jun '13

hi … I don't suppose anyone has any experience updating or fixing MAC addresses on Nvidea nVIDIA MCP55V-Pro (Supermicro H8DMT+) ? Following an experimental reflash everything went well, except afterwards we noticed the mac address had been reset link/ether 66:77:44:22:33:12 brd ff:ff:ff:ff:ff:ff -- Jon Morby FidoNet - the internet made simple! 10 - 16 Tiller Road, London, E14 8PX tel: 0845 004 3050 / fax: 0845 004 3051

4 5

Asrock Fatal1ty Z77 Performance > unsupported - logs attached
by "Jürgen Dorn" 01 Jun '13

01 Jun '13

regards, Jürgen

2 1

Re: [flashrom] [PATCH] Combine serialport_write and serialport_read into serialport_rw.
by Carl-Daniel Hailfinger 01 Jun '13

01 Jun '13

Am 01.04.2013 03:14 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. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > diff --git a/serial.c b/serial.c > index 49484f5..6679b7c 100644 > --- a/serial.c > +++ b/serial.c > @@ -28,6 +28,7 @@ > #include <sys/stat.h> > #include <errno.h> > #include <inttypes.h> > +#include <stdbool.h> > #ifdef _WIN32 > #include <conio.h> > #else > @@ -328,68 +329,61 @@ int serialport_shutdown(void *data) > return 0; > } > > -int serialport_write(unsigned char *buf, unsigned int writecnt) > +/* Writes (if \c outdir is true) or reads \c todo bytes from/into \c buf. > + * Tries up to 10 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) > { > + const char * const op = outdir ? "write" : "read"; > #ifdef _WIN32 > - DWORD tmp = 0; > + DWORD cur = 0; > #else > - ssize_t tmp = 0; > + ssize_t cur = 0; > #endif > - unsigned int empty_writes = 250; /* results in a ca. 125ms timeout */ > + unsigned int empty_tries = 10; > > - while (writecnt > 0) { > + while (todo > 0) { > #ifdef _WIN32 > - WriteFile(sp_fd, buf, writecnt, &tmp, NULL); > + if (outdir) > + WriteFile(sp_fd, buf, todo, &cur, NULL); > + else > + ReadFile(sp_fd, buf, todo, &cur, NULL); > #else > - tmp = write(sp_fd, buf, writecnt); > + if (outdir) > + cur = write(sp_fd, buf, todo); > + else > + cur = read(sp_fd, buf, todo); > #endif > - if (tmp == -1) { > - msg_perr("Serial port write error!\n"); > + if (cur == -1) { > + msg_perr("Serial port %s error!\n", op); > return 1; The logic of error handling is non-portable (AFAICS the number of read/written bytes for the error case is 0 on Windows and -1 on POSIX). That said, it was non-portable before, so this patch doesn't change it for the worse. > } > - if (!tmp) { > - msg_pdbg2("Empty write\n"); > - empty_writes--; > - programmer_delay(500); > - if (empty_writes == 0) { > + 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!\n"); That message is actually wrong for the read case. If the serial device (e.g. Bus Pirate) disappears, you'll get 0-byte reads forever, at least on Linux. AFAICS blocking reads shall either return an error or at least 1 byte. That rule seems to be valid on Linux and Windows. Errors can be transient, though (see EINTR and other fun stuff). Suggested alternative wording: "Serial port is unresponsive or disappeared" > return 1; > } > } > - writecnt -= tmp; > - buf += tmp; > + todo -= cur; > + buf += cur; > } > > 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 > * 0 on success, positive values on temporary errors (e.g. timeouts) and negative ones on permanent errors. > * If really_read is not NULL, this function sets its contents to the number of bytes read successfully. */ Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Script for collecting flashrom compatibility with motherboards
by Alexey Vazhnov 31 May '13

31 May '13

Hi! Perhaps we can check many hardware for compatibility with Linux. Condition: test must be fast, so no manual intervention. So now I prepare some PXE images for collect hardware information. How do I collect maximum information about motherboards chips compatible with flashrom? Currently I see only one variant — write motherboard name with «flashrom -r /dev/null» stdout. -- Yours respectfully, Alexey Vazhnov Jabber: vazhnov(a)jabber.ru

2 2

Re: [flashrom] Read test - Dell Dimension C521
by Stefan Tauner 31 May '13

31 May '13

On Wed, 15 May 2013 10:39:44 +0200 Gil <agile81(a)gmail.com> wrote: > seems fine > > flashrom v0.9.6.1-r1563 on Linux generic (i686) > flashrom was built with libpci 3.1.9, GCC 4.7.1, little endian > Command line (5 args): flashrom -VVV -p internal -o fl1 > Calibrating delay loop... OS timer resolution is 2 usecs, 948M loops > per second, 10 myus = 12 us, 100 myus = 101 us, 1000 myus = 997 us, > 10000 myus = 10369 us, 8 myus = 9 us, OK. > Initializing internal programmer > No coreboot table found. > DMI string system-manufacturer: "Dell Inc" > DMI string system-product-name: "Dimension C521" > DMI string system-version: " " > DMI string baseboard-manufacturer: "Dell Inc" > DMI string baseboard-product-name: " " > DMI string baseboard-version: " " > DMI string chassis-type: "Desktop" > Found chipset "NVIDIA MCP51" with PCI ID 10de:0260. Enabling flash write... > OK. > ... > The following protocols are supported: Non-SPI. > ... > Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x9d, id2 0x6e > Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) at physical > address 0xfff80000. > ... > Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH). > No operations were specified. > Restoring PCI config space for 00:0a:0 reg 0x6d > > Saved BIOS ROM ok Hi Gil and thanks for your report. We are not really interested in (successful) read tests for boards (because they don't tell anything about writes and we do not keep track of that separately). Also, please do not prune logs even if you think you do us a favor and that there is lots of useless stuff in it. :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Winbond W25X20 on Tumpa programmer works
by J. Domburg 31 May '13

31 May '13

As subject. Verbose read and write output of flashrom is attached. Cheers, Jeroen

2 3

Asus P8P67 LE works, successfully wrote and verified
by artemis3 30 May '13

30 May '13

Hello, I checked your wiki matrix, and I'm not sure i quite understand where it says "NO (42)" what exactly means. I have this motherboard, which is a B2. there is a B3 next to it in your hardware table with a green "OK" (P8P67 PRO). I went ahead and tried flashing anyway and it worked!, It could write and verify back an old bios (1104) downloaded from Asus page. This board was nearly bricked by the writing of a B3 bios which made all sort of trouble to it, after several attempts (wouldn't post) i managed to boot linux and went with flashrom. Note 42 has this written: "Probing works (Winbond W25Q32, 4096 kB, SPI), but parts of the flash are problematic: descriptor is r/o (conforming to ICH reqs), ME region is locked." But this is wrong, flashrom identified chip MX25L3205 like the other 2 previous models. I have no idea what this ME and ICH business is to deserve a red NO, but it worked with mine. Asus page happily mentions "Pre-B3 revision motherboard users can also download and use the new B3 revision BIOS, drivers and utilities." http://event.asus.com/2011/mb/Identify_B3_Motherboards/ That is absolutely wrong!, Pre B3 users can't use any B3 BIOS image!. In my case, the bios got all sensor values wrong, and it wanted to shutdown as it thought the processor was over/under temp, voltage etc, i managed to turn off all power setting things i could to be able to post, and the bios would often freeze requiring moving the clear jumper before even wanting to turn the power on again many times. I also learned something about Asus: while their BIOS EZ Flash tool happily allows upgrading to this dangerous B3 bios in a B2 board, it won't let you flash back to the older working version, genius move... I used flashrom 0.9.5.2+r1517-1 from the Ubuntu repository. flashrom v0.9.5.2-r1517 on Linux 3.5.0-28-generic (x86_64), built with libpci 3.1.8, GCC 4.6.3, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "Intel P67". Enabling flash write... OK. Found Macronix flash chip "MX25L3205" (4096 kB, SPI) at physical address 0xffc00000.

2 3

Re: [flashrom] New board for list
by Stefan Tauner 30 May '13

30 May '13

On Sat, 18 May 2013 15:48:56 -0400 Aurelius R <maxrowsell(a)gmail.com> wrote: > The board from the HP Pavilion a6200n which has the NVIDIA nForce 430 > Chipset works great -- I tested it multiple times reading, writing and > erasing the BIOS chip, no flaws, no errors at all. I'm also going to try > and write the VESA chip (nVidia MCP61-80) which seems to be a separate > chip, because that is the chip that seems to be causing all the trouble on > this board. > > Anyway, just thought you'd like to add that info to your list. I can also > provide the dump from flashrom -V that the program says to email to you, as > support isn't quite complete for my board/chip if you want. Hello Alexander, yes please send a verbose log (probing for the chip is good enough for now, no need to read/write). Can you confirm that this is the board in question? http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01077676&tmp_task=prod… You seem to be under the impression that the graphics core uses a separate flash chip for its firmware. This is probably not the case. Instead it shares it with the "BIOS" chip that flashrom accesses. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Fwd: Re: Added chipsets
by Steven Zakulec 28 May '13

28 May '13

---------- Forwarded message ---------- From: "Николай Николаев" <evrinoma(a)gmail.com> Date: May 28, 2013 1:28 AM Subject: Re: [flashrom] Added chipsets To: "Steven Zakulec" <spzakulec(a)gmail.com> Cc: Hi Steven, Other people can provide more details on the general case, but in this > instance, with only a WREN instruction, the FEATURE line should be: > I've been informed by others that your original idea of dropping the > FEATURE line is actually correct, so you should do that instead of what I > proposed. > i dropped this line because this line for chips fetch Numonyx N25Q00AA13- >>> I'll admit I don't really know how this chip works, but it seems there >>> should be a 3rd eraseblock from the description of the memory organization >>> (datasheet is Rev E, 2/12): >>> >>> Memory Configuration and Block Diagram >>> The memory is a stacked device comprised of four 256Mb chips. Each chip >>> is internally >>> partitioned into two 128Mb segments. Each page of memory can be >>> individually pro- >>> grammed. Bits are programmed from one through zero. The device is >>> subsector, sector, >>> or single 256Mb chip erasable, but not page-erasable. Bits are erased >>> from zero through >>> one. The memory is configured as 134,217,728 bytes (8 bits each); 2048 >>> sectors (64KB >>> each); 32,768 subsectors (4KB each); and 524,288 pages (256 bytes each); >>> and 64 OTP >>> bytes are located outside the main memory array. >>> >>> You've got: >>> + .eraseblocks = { {4 * 1024, 32768 } }, >>> + .block_erase = spi_block_erase_20, >>> + }, { >>> + .eraseblocks = { {64 * 1024, 2048 } }, >>> + .block_erase = spi_block_erase_d8, >>> >>> There's a die erase opcode, which I am unfamiliar with- maybe it handles >>> erasing a single 256Mb chip at a time? >>> >> >> You right this chip used a four 256 Mb chips. And 256 Mb chip has a three >> instruction subsector 20(hex) sector D8(hex) bulk C7(hex) erase commands. >> But chip N25Q00AA13 has a other op-code to initiate die erase command >> C4 (hex) >> >> So, how do you do a single-chip erase for this chip? > I think this function is feature, because use "not general" op-code C4 for die erase command. Also first we need to write a special function feature extended addressing for chips more than 128 mb, after that we will think about how to initiate die erase instruction. What data sheets do you have for those chips? The ones below list the > small sector erase op-code as D7. > LE25FW418A: 61709 SY 20090428-S00004 No.A1432 > LE25FW808: 61009 SY IM 20090319-S00003 No.A0839 > LE25FW806: 70208 SY IM 20070628-S00004 No.A0838 > I have a equivalence data sheets. LE25FW808 has a general op-code 20(hex) to initiate small sector erase. Other chips use a feature op-code as D7. -- With best regards Nikolay Nikolaev

1 0

Please help
by Aaron Brown 28 May '13

28 May '13

Hi . I installed flashrom 9.6.1 but cant find any button that says "write flashrom" please tell me, how exactly I can write the bios ? ------------------------------------------------------------------------------ with big honor. Aaron

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom May 2013