flashrom October 2010

flashrom@flashrom.org

66 participants
181 discussions

[PATCH] W83697xx superio flash enable
by David Borg 05 May '12

05 May '12

Adds a function to enable the flash interface on w83697xx superio's. Still needs to be hooked up to the superio detection framework though. Signed-off-by: David Borg <borg.db(a)gmail.com>

2 1

ASUS OPLX-M results (no flash device found)
by Ville Skyttä 17 Feb '12

17 Feb '12

Hello, I tried out flashrom on a ASUS OPLX-M motherboard, and it didn't find a flash device. I found some info by googling (that I cannot verify) that the OPLX-M would be an OEM (or something) version of the ASUS MEL-M; I suppose this particular board originally came with a Fujitsu/Siemens PC. http://support.asus.com/download/download.aspx?modelname=MEL-M&SLanguage=en…

3 4

Re: [flashrom] Trial of ARIMA:HDAMA Motherboard
by Carl-Daniel Hailfinger 09 Feb '12

09 Feb '12

Hi Mike, On 23.02.2010 05:45, Spangler, Mike T wrote: > I can probe with a continuity tester, but would need to know specific > pin locations to try. Do you have any generic info on doing this? Yes (well, I'd have to write up something), but the solution mentioned by Michael is way easier, so I'll wait until Michael has diagnosed the GPIO settings from the flashrom run on factory BIOS. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth

2 1

AMD SB7xx/SB8xx w/IMC: enable specs
by Joshua Roys 03 Jan '12

03 Jan '12

Hello all, The specific board this is for is the Supermicro H8DGT. Attached is only the specification, which is not guaranteed to be correct. Use with care. Also, after using this, you may want to turn off and unplug the computer for a few minutes to restore the correct operational state. The AMD SB700/710/750 Register Reference Guide (#43009) was used as a reference. Thanks, Josh

2 2

[PATCH] Fintek SPI driver, based off it87spi
by Sean Nelson 23 Oct '11

23 Oct '11

I've been extremely busy with preparing for the US Air Force, which I leave for Basic on November 2nd. But... Fintek SPI Flashrom Driver: * based off of it87spi.c * untested * should be good for F71882 and F71889 Signed-off-by: Sean Nelson <audiohacked(a)gmail.com>

2 3

patch to add support for Xilinx parallel III/DLC5 programmer cable
by Jakab Peter 12 Sep '11

12 Sep '11

Hi list, I modified the rayer spi programmer source to be used with a Xilinx parallel III (also called DLC5) programmer cable. It's a trivial change of parallel port pins, but I did not know how the support for this cable should be included into the source code. Copying the same code to a separate file may not be a good idea. --- flashrom/rayer_spi.c 2010-09-18 19:48:27.000000000 +0200 +++ ../flashrom/rayer_spi.c 2010-09-18 02:12:59.000000000 +0200 @@ -37,11 +37,11 @@ * independent and are bitshift values, not real pin numbers. */ /* Pins for master->slave direction */ -#define SPI_CS_PIN 5 -#define SPI_SCK_PIN 6 -#define SPI_MOSI_PIN 7 +#define SPI_CS_PIN 2 +#define SPI_SCK_PIN 1 +#define SPI_MOSI_PIN 0 /* Pins for slave->master direction */ -#define SPI_MISO_PIN 6 +#define SPI_MISO_PIN 4 static int lpt_iobase; Thank you for working on this software, with access to the source code I was able to program my w25q64 flash chip. -- Peter JAKAB http://jap.hu/

3 3

Re: [flashrom] [PATCH] Board enable for ASUS P5LP-LE
by Uwe Hermann 25 Aug '11

25 Aug '11

On Wed, Aug 18, 2010 at 06:27:15PM +0200, Michael Karcher wrote: > + * - ASUS P5LP-LE (Epson/HP OEM) OK, this one is going to be interesting. The board is made by ASUS for HP, it seems. HP calls it "Leonite" or "Leonite-GL8E". http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&dlc=en&cc=us&docname=c008… But that would have been too easy. There are a bunch of other boards on the HP site which are also called P5LP-LE, but have different HP code names. From a quick glance I see at least: P5LP-LE (Leonite) P5LP-LE (Leonite2) P5LP-LE (Lithium) P5LP-LE (Limestone) P5LP-LE (Emery) Fun! I don't know how to differ between them, the dmidecode from Leon Zhang <leoncamel(a)gmail.com> said: DMI string system-manufacturer: "EPSON DIRECT CORP." DMI string system-product-name: "Endeavor MT7700" DMI string system-version: "" DMI string baseboard-manufacturer: "ASUSTek Computer INC." DMI string baseboard-product-name: "P5LP-LE" We don't know if other "P5LP-LE" might have the "Leonite" (or other) HP code name in there or not. Maybe something is printed as silkscreen on the board? An then one of these HP OEM boards is built into the Epson "Endeavor MT7700" system/PC. So it's a bit unclear which vendor/board name we should use in this case. It's probably best to mention all of them for better googling results. Attached is a slightly updated patch for review, let me know what you think. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org

3 2

[PATCH] internal dmi decoder
by Sean Nelson 16 Aug '11

16 Aug '11

Here is a new version of the internal dmi decoding. To use the new decoder, the user needs to use "-p internal:dmi=new", to cross-check with the external dmidecode use "-p internal:dmi=check". Hopefully if this is comitted, it will make it easier for people to test the new internal decoder. Signed-off-by: Sean Nelson <audiohacked(a)gmail.com>

5 8

[PATCH] Always read chip before writing, avoid emergency messages
by Carl-Daniel Hailfinger 15 Aug '11

15 Aug '11

Always read the flash chip before writing. This will allow flashrom to skip erase of already-erased blocks and to skip write of blocks which already have the wanted contents. Avoid emergency messages by checking if the chip contents after a failed write operation (erase/write) are unchanged. Keep the emergency messages after a failed pure erase. That part is debatable because if someone wants erase, he pretty sure doesn't care about the flash contents anymore. Please note that this introduces additional overhead of a full chip read before write. This is frowned upon by people with slow programmers. Maybe we should make this configurable. Either way, this patch needs a review to make sure I'm not going in the wrong direction. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-always_read_no_scary_warning/flash.h =================================================================== --- flashrom-always_read_no_scary_warning/flash.h (Revision 1212) +++ flashrom-always_read_no_scary_warning/flash.h (Arbeitskopie) @@ -239,7 +239,7 @@ /* layout.c */ int read_romlayout(char *name); int find_romentry(char *name); -int handle_romentries(uint8_t *buffer, struct flashchip *flash); +int handle_romentries(struct flashchip *flash, uint8_t *oldcontents, uint8_t *newcontents); /* spi.c */ struct spi_command { Index: flashrom-always_read_no_scary_warning/layout.c =================================================================== --- flashrom-always_read_no_scary_warning/layout.c (Revision 1212) +++ flashrom-always_read_no_scary_warning/layout.c (Arbeitskopie) @@ -205,7 +205,7 @@ return -1; } -int handle_romentries(uint8_t *buffer, struct flashchip *flash) +int handle_romentries(struct flashchip *flash, uint8_t *oldcontents, uint8_t *newcontents) { int i; @@ -225,13 +225,12 @@ // normal will be updated and the rest will be kept. for (i = 0; i < romimages; i++) { - if (rom_entries[i].included) continue; - flash->read(flash, buffer + rom_entries[i].start, - rom_entries[i].start, - rom_entries[i].end - rom_entries[i].start + 1); + memcpy(newcontents + rom_entries[i].start, + oldcontents + rom_entries[i].start, + rom_entries[i].end - rom_entries[i].start + 1); } return 0; Index: flashrom-always_read_no_scary_warning/flashrom.c =================================================================== --- flashrom-always_read_no_scary_warning/flashrom.c (Revision 1212) +++ flashrom-always_read_no_scary_warning/flashrom.c (Arbeitskopie) @@ -1343,6 +1343,19 @@ return ret; } +void nonfatal_help_message(void) +{ + msg_gerr("Writing to the flash chip apparently didn't do anything.\n" + "This means we have to add special support for your board, " + "programmer or flash chip.\n" + "Please report this on IRC at irc.freenode.net (channel " + "#flashrom) or\n" + "mail flashrom(a)flashrom.org!\n" + "-------------------------------------------------------------" + "------------------\n" + "You may now reboot or simply leave the machine running.\n"); +} + void emergency_help_message(void) { msg_gerr("Your flash chip is in an unknown state.\n" @@ -1602,9 +1615,10 @@ */ int doit(struct flashchip *flash, int force, char *filename, int read_it, int write_it, int erase_it, int verify_it) { - uint8_t *buf; + uint8_t *oldcontents; + uint8_t *newcontents; int ret = 0; - unsigned long size; + unsigned long size = flash->total_size * 1024; if (chip_safety_check(flash, force, filename, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -1612,9 +1626,6 @@ return 1; } - size = flash->total_size * 1024; - buf = (uint8_t *) calloc(size, sizeof(char)); - /* Given the existence of read locks, we want to unlock for read, * erase and write. */ @@ -1627,6 +1638,12 @@ return ret; } if (erase_it) { + /* FIXME: Do we really want the scary warning if erase failed? + * After all, after erase the chip is either blank or partially + * blank or it has the old contents. A blank chip won't boot, + * so if the user wanted erase and reboots afterwards, the user + * knows very well that booting won't work. + */ if (erase_flash(flash)) { emergency_help_message(); programmer_shutdown(); @@ -1634,33 +1651,71 @@ } } + newcontents = (uint8_t *) calloc(size, sizeof(char)); + if (write_it || verify_it) { - if (read_buf_from_file(buf, flash->total_size * 1024, filename)) { + if (read_buf_from_file(newcontents, size, filename)) { programmer_shutdown(); return 1; } #if CONFIG_INTERNAL == 1 - show_id(buf, size, force); + if (programmer == PROGRAMMER_INTERNAL) + show_id(newcontents, size, force); #endif } + oldcontents = (uint8_t *) calloc(size, sizeof(char)); + + /* Read the whole chip to be able to check whether regions need to be + * erased and to give better diagnostics in case write fails. + * The alternative would be to read only the regions which are to be + * preserved, but in that case we might perform unneeded erase which + * takes time as well. + */ + msg_cdbg("Reading old flash chip contents...\n"); + if (flash->read(flash, oldcontents, 0, size)) { + programmer_shutdown(); + return 1; + } + // This should be moved into each flash part's code to do it // cleanly. This does the job. - handle_romentries(buf, flash); + handle_romentries(flash, oldcontents, newcontents); // //////////////////////////////////////////////////////////// if (write_it) { if (erase_flash(flash)) { + msg_cerr("Uh oh. Erase failed. Checking if anything " + "changed.\n"); + if (!flash->read(flash, newcontents, 0, size)) { + if (!memcmp(oldcontents, newcontents, size)) { + msg_cinfo("Good. It seems nothing was " + "changed.\n"); + nonfatal_help_message(); + programmer_shutdown(); + return 1; + } + } emergency_help_message(); programmer_shutdown(); return 1; } msg_cinfo("Writing flash chip... "); - ret = flash->write(flash, buf, 0, flash->total_size * 1024); + ret = flash->write(flash, newcontents, 0, size); if (ret) { - msg_cerr("FAILED!\n"); + msg_cerr("Uh oh. Write failed. Checking if anything " + "changed.\n"); + if (!flash->read(flash, newcontents, 0, size)) { + if (!memcmp(oldcontents, newcontents, size)) { + msg_cinfo("Good. It seems nothing was " + "changed.\n"); + nonfatal_help_message(); + programmer_shutdown(); + return 1; + } + } emergency_help_message(); programmer_shutdown(); return 1; @@ -1673,7 +1728,7 @@ /* Work around chips which need some time to calm down. */ if (write_it) programmer_delay(1000*1000); - ret = verify_flash(flash, buf); + ret = verify_flash(flash, newcontents); /* If we tried to write, and verification now fails, we * might have an emergency situation. */ -- http://www.hailfinger.org/

4 8

[PATCH] Warn about unhandled one-time programmable memory
by Daniel Lenski 14 Aug '11

14 Aug '11

Added feature bit FEATURE_UNHANDLED_OTP, and a warning for chips like AMIC A25L032 and A25LQ032 which contain small regions of one-time programmable memory that flashrom can neither read, nor write, nor erase. Signed-off-by: Daniel Lenski <dlenski(a)gmail.com> --- flash.h | 1 + flashchips.c | 2 ++ flashrom.c | 8 ++++++++ 3 files changed, 11 insertions(+), 0 deletions(-) diff --git a/flash.h b/flash.h index 6f0d7c0..6db4c48 100644 --- a/flash.h +++ b/flash.h @@ -85,6 +85,7 @@ enum chipbustype { #define FEATURE_ADDR_SHIFTED (1 << 5) #define FEATURE_WRSR_EWSR (1 << 6) #define FEATURE_WRSR_WREN (1 << 7) +#define FEATURE_UNHANDLED_OTP (1 << 8) #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) struct flashchip { diff --git a/flashchips.c b/flashchips.c index efd7599..07b9635 100644 --- a/flashchips.c +++ b/flashchips.c @@ -817,6 +817,7 @@ struct flashchip flashchips[] = { .model_id = AMIC_A25L032, .total_size = 4096, .page_size = 256, + .feature_bits = FEATURE_UNHANDLED_OTP, .tested = TEST_UNTESTED, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, @@ -852,6 +853,7 @@ struct flashchip flashchips[] = { .model_id = AMIC_A25LQ032, .total_size = 4096, .page_size = 256, + .feature_bits = FEATURE_UNHANDLED_OTP, .tested = TEST_UNTESTED, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, diff --git a/flashrom.c b/flashrom.c index 2690151..a7471a6 100644 --- a/flashrom.c +++ b/flashrom.c @@ -1434,6 +1434,14 @@ void check_chip_supported(struct flashchip *flash) "Thanks for your help!\n" "===\n"); } + if (flash->feature_bits & FEATURE_UNHANDLED_OTP) { + msg_cinfo("===\n" + "This flash part contains a region of one-time programmable memory\n" + "which flashrom cannot read, and may never be able to write or\n" + "erase. flashrom may not be able to completely backup and rewrite\n" + "the contents of this chip.\n" + "===\n"); + } } int main(int argc, char *argv[]) -- 1.7.0.4

2 1

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom October 2010