January 2011 - flashrom - mail.coreboot.org

successfully flashed SST25VF040B
by Dennis Keller Jan. 20, 2011

Jan. 20, 2011

Hi, i just want to let you know that i did succesfully flash my bios with your program. flashrom told me that there are two chips, SST25VF040B and SST25VF040B.REMS, but with the same physical address, so i decided to flash both. It just worked, but the model and s/n information from lshw got lost. if you want more information about my system just tell me. Thanks a lot, Dennis My Computer: HP Pavilion m7794.de-a Prod. #: RR837AA-ABD S/N: CZH7041H7N OS: Ubuntu 10.10 Maverick Meerkat 64Bit Lang: German Country: Germany

1 0

[commit] r1254 - trunk
by repository service Jan. 20, 2011

Jan. 20, 2011

Author: stepan Date: Thu Jan 20 22:05:15 2011 New Revision: 1254 URL: http://flashrom.org/trac/flashrom/changeset/1254 Log: Secret knowledge is cool, but public knowledge is better. Implement all Dediprog commands found in USB traces, even if their purpose is not yet known. Annotate unknown commands with info about the call sequence they are embedded in and the firmware version of the log. Add a new shutdown command for firmware 5.x (of which Stefan thinks it's "switch the Pass light on" hence it is called late in the game) Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <reinauer(a)google.com> Modified: trunk/dediprog.c Modified: trunk/dediprog.c ============================================================================== --- trunk/dediprog.c Wed Jan 19 07:21:54 2011 (r1253) +++ trunk/dediprog.c Thu Jan 20 22:05:15 2011 (r1254) @@ -27,6 +27,7 @@ #define DEFAULT_TIMEOUT 3000 static usb_dev_handle *dediprog_handle; +static int dediprog_firmwareversion; static int dediprog_endpoint; #if 0 @@ -317,6 +318,7 @@ fw[1], fw[2]); return 1; } + dediprog_firmwareversion = fw[0]; return 0; } @@ -342,6 +344,32 @@ return 0; } +#if 0 +/* Something. + * Present in eng_detect_blink.log with firmware 3.1.8 + * Always preceded by Command Receive Device String + */ +static int dediprog_command_b(void) +{ + int ret; + char buf[0x3]; + + memset(buf, 0, sizeof(buf)); + ret = usb_control_msg(dediprog_handle, 0xc3, 0x7, 0x0, 0xef00, buf, 0x3, DEFAULT_TIMEOUT); + if (ret < 0) { + msg_perr("Command B failed (%s)!\n", usb_strerror()); + return 1; + } + if ((ret != 0x3) || (buf[0] != 0xff) || (buf[1] != 0xff) || + (buf[2] != 0xff)) { + msg_perr("Unexpected response to Command B!\n"); + return 1; + } + + return 0; +} +#endif + /* Command C is only sent after dediprog_check_devicestring, but not after every * invocation of dediprog_check_devicestring. It is only sent after the first * dediprog_command_a(); dediprog_check_devicestring() sequence in each session. @@ -353,7 +381,7 @@ ret = usb_control_msg(dediprog_handle, 0x42, 0x4, 0x0, 0x0, NULL, 0x0, DEFAULT_TIMEOUT); if (ret != 0x0) { - msg_perr("Unexpected response to Command C!\n"); + msg_perr("Command C failed (%s)!\n", usb_strerror()); return 1; } return 0; @@ -363,6 +391,7 @@ /* Very strange. Seems to be a programmer keepalive or somesuch. * Wait unsuccessfully for timeout ms to read one byte. * Is usually called after setting voltage to 0. + * Present in all logs with Firmware 2.1.1 and 3.1.8 */ static int dediprog_command_f(int timeout) { @@ -371,8 +400,85 @@ memset(buf, 0, sizeof(buf)); ret = usb_control_msg(dediprog_handle, 0xc2, 0x11, 0xff, 0xff, buf, 0x1, timeout); + /* This check is most probably wrong. Command F always causes a timeout + * in the logs, so we should check for timeout instead of checking for + * success. + */ + if (ret != 0x1) { + msg_perr("Command F failed (%s)!\n", usb_strerror()); + return 1; + } + return 0; +} + +/* Start/stop blinking? + * Present in eng_detect_blink.log with firmware 3.1.8 + * Preceded by Command J + */ +static int dediprog_command_g(void) +{ + int ret; + + ret = usb_control_msg(dediprog_handle, 0x42, 0x07, 0x09, 0x03, NULL, 0x0, DEFAULT_TIMEOUT); + if (ret != 0x0) { + msg_perr("Command G failed (%s)!\n", usb_strerror()); + return 1; + } + return 0; +} + +/* Something. + * Present in all logs with firmware 5.1.5 + * Always preceded by Command Receive Device String + * Always followed by Command Set SPI Voltage nonzero + */ +static int dediprog_command_h(void) +{ + int ret; + + ret = usb_control_msg(dediprog_handle, 0x42, 0x07, 0x09, 0x05, NULL, 0x0, DEFAULT_TIMEOUT); + if (ret != 0x0) { + msg_perr("Command H failed (%s)!\n", usb_strerror()); + return 1; + } + return 0; +} +#endif + +/* Shutdown for firmware 5.x? + * This command swithces the "Pass" LED on. + * Present in all logs with firmware 5.1.5 + * Often preceded by a SPI operation (Command Read SPI Bulk or Receive SPI) + * Always followed by Command Set SPI Voltage 0x0000 + */ +static int dediprog_command_i(void) +{ + int ret; + + ret = usb_control_msg(dediprog_handle, 0x42, 0x07, 0x09, 0x06, NULL, 0x0, DEFAULT_TIMEOUT); if (ret != 0x0) { - msg_perr("Unexpected response to Command F!\n"); + msg_perr("Command I failed (%s)!\n", usb_strerror()); + return 1; + } + return 0; +} + +#if 0 +/* Start/stop blinking? + * Present in all logs with firmware 5.1.5 + * Always preceded by Command Receive Device String on 5.1.5 + * Always followed by Command Set SPI Voltage nonzero on 5.1.5 + * Present in eng_detect_blink.log with firmware 3.1.8 + * Preceded by Command B in eng_detect_blink.log + * Followed by Command G in eng_detect_blink.log + */ +static int dediprog_command_j(void) +{ + int ret; + + ret = usb_control_msg(dediprog_handle, 0x42, 0x07, 0x09, 0x07, NULL, 0x0, DEFAULT_TIMEOUT); + if (ret != 0x0) { + msg_perr("Command J failed (%s)!\n", usb_strerror()); return 1; } return 0; @@ -550,9 +656,11 @@ /* URB 136 is just URB 9. */ /* URB 137 is just URB 11. */ - /* Command I is probably Start Bulk Read. Data is u16 blockcount, u16 blocksize. */ - /* Command J is probably Start Bulk Write. Data is u16 blockcount, u16 blocksize. */ - /* Bulk transfer sizes for Command I/J are always 512 bytes, rest is filled with 0xff. */ + /* Command Start Bulk Read. Data is u16 blockcount, u16 blocksize. */ + /* Command Start Bulk Write. Data is u16 blockcount, u16 blocksize. */ + /* Bulk transfer sizes for Command Start Bulk Read/Write are always + * 512 bytes, rest is filled with 0xff. + */ return 0; } @@ -562,6 +670,10 @@ { msg_pspew("%s\n", __func__); + /* Shutdown on firmware 5.x */ + if (dediprog_firmwareversion == 5) + if (dediprog_command_i()) + return 1; /* URB 28. Command Set SPI Voltage to 0. */ if (dediprog_set_spi_voltage(0x0)) return 1;

1 0

[commit] r1253 - trunk
by repository service Jan. 18, 2011

Jan. 18, 2011

Author: stepan Date: Wed Jan 19 07:21:54 2011 New Revision: 1253 URL: http://flashrom.org/trac/flashrom/changeset/1253 Log: Don't print the local memory flash chip address on programmers that don't actually map the flash chip into local memory (like the dediprog) because the value does not make sense there. This version was reworked / rewritten by Mathias Krause to have less "impact" Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Acked-by: Mathias Krause <mathias.krause(a)secunet.com> Modified: trunk/flashrom.c Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Mon Jan 17 08:50:42 2011 (r1252) +++ trunk/flashrom.c Wed Jan 19 07:21:54 2011 (r1253) @@ -1127,6 +1127,7 @@ { struct flashchip *flash; unsigned long base = 0; + char location[64]; uint32_t size; enum chipbustype buses_common; char *tmp; @@ -1178,10 +1179,16 @@ if (!flash || !flash->name) return NULL; - msg_cinfo("%s chip \"%s %s\" (%d KB, %s) at physical address 0x%lx.\n", + if (programmer_table[programmer].map_flash_region == physmap) { + snprintf(location, sizeof(location), "at physical address 0x%lx", base); + } else { + snprintf(location, sizeof(location), "on %s", programmer_table[programmer].name); + } + + msg_cinfo("%s chip \"%s %s\" (%d KB, %s) %s.\n", force ? "Assuming" : "Found", flash->vendor, flash->name, flash->total_size, - flashbuses_to_text(flash->bustype), base); + flashbuses_to_text(flash->bustype), location); /* Flash registers will not be mapped if the chip was forced. Lock info * may be stored in registers, so avoid lock info printing.

1 0

Re: [flashrom] Erase Fails on Winmate I370
by Idwer Vollering Jan. 18, 2011

Jan. 18, 2011

2011/1/17 <sdbarnes(a)rockwellcollins.com> > > FYI, > > I was able to successfully write a new BIOS file to flash for the Winbond > W39040FC by using the unlock_w39v040fb() function. > Yes, I already expected that using that unlock routine should work for all W39V040FC / W39V040F{A,B,C} chips: http://patchwork.coreboot.org/patch/2516/ > Shane > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

2 1

Macronix MX25L8005 write successful with latest r1250
by Peter Lemenkov Jan. 18, 2011

Jan. 18, 2011

Hello All! -- With best regards, Peter Lemenkov.

1 0

Re: [flashrom] [coreboot] Invite: Silicon Valley Coreboot Hackathon
by Rudolf Marek Jan. 18, 2011

Jan. 18, 2011

Hi all, Well for all those Europeans which might feel bit sad that California is "far far way" I have a following proposal. Lets meet in Prague for a weekend in April/May. I think I could get some dormitory style accommodation and we can meet at university at the weekend. Prague is not so distant: Prague - Dresden - 153km Prague - Wien - 334km Prague - Nurnberg - 291km I created some doodle (which contains just fridays from the intended weekends). http://doodle.com/2n4h3gcugwvs6c9k Thanks, Rudolf

1 0

Status of dediprog support?
by Carl Worth Jan. 17, 2011

Jan. 17, 2011

I was delighted to find flashrom when I needed to recently flash a chip with a Dediprog SF100 and I googled for "dediprog linux". I started with the 0.9.2 release of flashrom as packaged by Debian, but didn't find support for "flashrom -p dediprog". I then noticed a 0.9.3 release on the website, downloaded the latest code from subversion, compiled it and *still* didn't get support for "flashrom -p dediprog". After digging through the Makefile, it was easy enough to find the support I needed by doing: make CONFIG_DEDIPROG=yes My question is, what needs to happen before this is the default setting? (Such that the package in Debian will have this support compiled in for my convenience.) For everything I did, (writing and verifying a couple of chips on a couple of boards), the Dediprog support seems to work just fine. Is there some further testing I could help do before this support is enabled by default? Thanks, -Carl -- carl.d.worth(a)intel.com

5 10

Tyan s4881 works
by jarray52 jarray52 Jan. 17, 2011

Jan. 17, 2011

build # flashrom -w coreboot.rom flashrom v0.9.2-r1001 on Linux 2.6.36-gentoo-r5 (x86_64), built with libpci 3.1.4, GCC 4.4.4 flashrom is free software, get the source code at http://www.flashrom.org No coreboot table found. Found chipset "NVIDIA CK804", enabling flash write... OK. This chipset supports the following protocols: Non-SPI. Calibrating delay loop... OK. Found chip "SST SST49LF080A" (1024 KB, LPC) at physical address 0xfff00000. === This flash part has status UNTESTED for operations: ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -Vw, -VE), and mention which mainboard or programmer you tested. Thanks for your help! === Note: If the following flash access fails, try -m <vendor>:<mainboard>. Writing flash chip... Erasing flash chip... SUCCESS. Programming page: DONE!ss: 0x000ff000 COMPLETE. Verifying flash... VERIFIED. After running flashrom -r backup.bin and comparing the checksum to the original image, I found they were identical.

1 0

flashrom -V asus eee pc 1201n
by Marcos Wolff Jan. 17, 2011

Jan. 17, 2011

1 0

Big problem with BIOS. Questions
by Germán Rotondo Jan. 17, 2011

Jan. 17, 2011

Hi. Greetings from Argentina. My english is not so good so I hope you can understand me. I have a chinese tablet pc netbook with Atom N450 - Intel NM10 Chipset. Being the most stupid guy in the world, I've found an updated bios in a forum and downloaded it. Tablet was running Ubuntu linux. I've flashed it with flashrom 0.9.3 without reading a thing about that notebooks and netbooks are not compatible because of the embedded controller. Flashing went OK. Flash memory detected OK, erased and programmed. After reset. . . Dead netbook After powering cycle, power light turns on, but no video. No boot block access, nothing. I have electronics skills, so I've taken it apart, and found that the motherboard has two identical flash chips, EON 25F80. I've desoldered both chips, read both with an external programmer to see what was on them, first chip had the original AMI bios, that was on the netbook prior to flashing. The second one has the new ami bios I've flashed and bricked. I've programmed the second chip with the original BIOS dump I've made before update, soldered it again and nothing happened. Board is dead. I'm little lost about the two flash scenario. When first chip is removed, board does not even power up, so I think it might be the embedded controller bios, but it's a complete ami bios?. Any help, thoughts you could give me would be of great help Thanks a lot German

2 1