flashrom November 2010

flashrom@flashrom.org

58 participants
146 discussions

[PATCH] Support Dediprog SF100 bulk read
by Carl-Daniel Hailfinger 16 Nov '10

16 Nov '10

Support Dediprog SF100 bulk read. Packet size is 512 bytes. Depending on your USB hardware and the Dediprog firmware version, this may not work at all. Untested, experimental, may hang/crash the programmer. Read tests of random images are appreciated. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-dediprog_read_bulk/dediprog.c =================================================================== --- flashrom-dediprog_read_bulk/dediprog.c (Revision 1225) +++ flashrom-dediprog_read_bulk/dediprog.c (Arbeitskopie) @@ -26,6 +26,7 @@ #define DEFAULT_TIMEOUT 3000 static usb_dev_handle *dediprog_handle; +static int dediprog_endpoint; #if 0 /* Might be useful for other pieces of code as well. */ @@ -148,9 +149,36 @@ int dediprog_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len) { + int ret; + int i; + int chunksize = 0x200; /* 512 */ + int count = flash->total_size * 1024 / chunksize; + /* Guessed. */ + const char count_and_chunk[] = {(count >> 8) & 0xff, + count & 0xff, + (chunksize >> 8) & 0xff, + chunksize & 0xff}; + msg_pspew("%s, start=0x%x, len=0x%x\n", __func__, start, len); - /* Chosen read length is 16 bytes for now. */ - return spi_read_chunked(flash, buf, start, len, 16); + if ((len != flash->total_size * 1024) || (start != 0)) { + msg_perr("Only a full chip read is supported for now. Wanted " + "start=%i, length=%i\n.", start, len); + return 1; + } + + /* Command Read SPI Bulk. No idea which read command is used on the SPI side. */ + usb_control_msg(dediprog_handle, 0x42, 0x20, 0x0000, 0x0000, (char *)count_and_chunk, 0x0004, DEFAULT_TIMEOUT); + + for (i = 0; i < count; i++) { + ret = usb_bulk_read(dediprog_handle, dediprog_endpoint, (char *)buf + i * chunksize, chunksize, DEFAULT_TIMEOUT); + if (ret != chunksize) { + msg_perr("SPI bulk read failed, expected %i, got %i %s!\n", + chunksize, ret, usb_strerror()); + return 1; + } + } + + return 0; } int dediprog_spi_send_command(unsigned int writecnt, unsigned int readcnt, @@ -301,6 +329,7 @@ dediprog_handle = usb_open(dev); usb_set_configuration(dediprog_handle, 1); usb_claim_interface(dediprog_handle, 0); + dediprog_endpoint = 2; /* URB 6. Command A. */ if (dediprog_command_a()) return 1; -- http://www.hailfinger.org/

4 14

[PATCH] Use large reads for verify
by Carl-Daniel Hailfinger 16 Nov '10

16 Nov '10

verify_range() and check_erased_range() check each page separately. While that may have seemed like a good idea back when the code was introduced, it has no benefits for any of the chips where we support write because all of them handle cross-page reads nicely. The only class of chips where this change could be a problem is chips with non power of two sector sizes which have gaps in the address space. We could simply require their read functions to provide gap-free results and leave it at that. This patch should speed up verify on Dediprog by a factor of ~100. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-verify_not_chunked/flashrom.c =================================================================== --- flashrom-verify_not_chunked/flashrom.c (Revision 1232) +++ flashrom-verify_not_chunked/flashrom.c (Arbeitskopie) @@ -726,9 +726,8 @@ */ int verify_range(struct flashchip *flash, uint8_t *cmpbuf, int start, int len, char *message) { - int i, j, starthere, lenhere, ret = 0; - int page_size = flash->page_size; - uint8_t *readbuf = malloc(page_size); + int i, ret = 0; + uint8_t *readbuf = malloc(len); int failcount = 0; if (!len) @@ -753,37 +752,21 @@ if (!message) message = "VERIFY"; - /* Warning: This loop has a very unusual condition and body. - * The loop needs to go through each page with at least one affected - * byte. The lowest page number is (start / page_size) since that - * division rounds down. The highest page number we want is the page - * where the last byte of the range lives. That last byte has the - * address (start + len - 1), thus the highest page number is - * (start + len - 1) / page_size. Since we want to include that last - * page as well, the loop condition uses <=. - */ - for (i = start / page_size; i <= (start + len - 1) / page_size; i++) { - /* Byte position of the first byte in the range in this page. */ - starthere = max(start, i * page_size); - /* Length of bytes in the range in this page. */ - lenhere = min(start + len, (i + 1) * page_size) - starthere; - ret = flash->read(flash, readbuf, starthere, lenhere); - if (ret) { - msg_gerr("Verification impossible because read failed " - "at 0x%x (len 0x%x)\n", starthere, lenhere); - break; + ret = flash->read(flash, readbuf, start, len); + if (ret) { + msg_gerr("Verification impossible because read failed " + "at 0x%x (len 0x%x)\n", start, len); + } + + for (i = 0; i < len; i++) { + if (cmpbuf[i] != readbuf[i]) { + /* Only print the first failure. */ + if (!failcount++) + msg_cerr("%s FAILED at 0x%08x! " + "Expected=0x%02x, Read=0x%02x,", + message, start + i, cmpbuf[i], + readbuf[i]); } - for (j = 0; j < lenhere; j++) { - if (cmpbuf[starthere - start + j] != readbuf[j]) { - /* Only print the first failure. */ - if (!failcount++) - msg_cerr("%s FAILED at 0x%08x! " - "Expected=0x%02x, Read=0x%02x,", - message, starthere + j, - cmpbuf[starthere - start + j], - readbuf[j]); - } - } } if (failcount) { msg_cerr(" failed byte count from 0x%08x-0x%08x: 0x%x\n", -- http://www.hailfinger.org/

3 4

[commit] r1233 - trunk
by repository service 16 Nov '10

16 Nov '10

Author: hailfinger Date: Tue Nov 16 18:21:58 2010 New Revision: 1233 URL: http://flashrom.org/trac/flashrom/changeset/1233 Log: Read the to-be-verified area in one go. verify_range() and check_erased_range() check each page separately. While that may have seemed like a good idea back when the code was introduced, it has no benefits for any of the chips where we support write because all of them handle cross-page reads nicely. The only class of chips where this change could be a problem is chips with non power of two sector sizes which have gaps in the address space. We simply require their read functions to provide gap-free results and leave it at that. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-By: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Modified: trunk/flashrom.c Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Wed Nov 10 16:25:18 2010 (r1232) +++ trunk/flashrom.c Tue Nov 16 18:21:58 2010 (r1233) @@ -726,9 +726,8 @@ */ int verify_range(struct flashchip *flash, uint8_t *cmpbuf, int start, int len, char *message) { - int i, j, starthere, lenhere, ret = 0; - int page_size = flash->page_size; - uint8_t *readbuf = malloc(page_size); + int i, ret = 0; + uint8_t *readbuf = malloc(len); int failcount = 0; if (!len) @@ -753,36 +752,21 @@ if (!message) message = "VERIFY"; - /* Warning: This loop has a very unusual condition and body. - * The loop needs to go through each page with at least one affected - * byte. The lowest page number is (start / page_size) since that - * division rounds down. The highest page number we want is the page - * where the last byte of the range lives. That last byte has the - * address (start + len - 1), thus the highest page number is - * (start + len - 1) / page_size. Since we want to include that last - * page as well, the loop condition uses <=. - */ - for (i = start / page_size; i <= (start + len - 1) / page_size; i++) { - /* Byte position of the first byte in the range in this page. */ - starthere = max(start, i * page_size); - /* Length of bytes in the range in this page. */ - lenhere = min(start + len, (i + 1) * page_size) - starthere; - ret = flash->read(flash, readbuf, starthere, lenhere); - if (ret) { - msg_gerr("Verification impossible because read failed " - "at 0x%x (len 0x%x)\n", starthere, lenhere); - break; - } - for (j = 0; j < lenhere; j++) { - if (cmpbuf[starthere - start + j] != readbuf[j]) { - /* Only print the first failure. */ - if (!failcount++) - msg_cerr("%s FAILED at 0x%08x! " - "Expected=0x%02x, Read=0x%02x,", - message, starthere + j, - cmpbuf[starthere - start + j], - readbuf[j]); - } + ret = flash->read(flash, readbuf, start, len); + if (ret) { + msg_gerr("Verification impossible because read failed " + "at 0x%x (len 0x%x)\n", start, len); + return ret; + } + + for (i = 0; i < len; i++) { + if (cmpbuf[i] != readbuf[i]) { + /* Only print the first failure. */ + if (!failcount++) + msg_cerr("%s FAILED at 0x%08x! " + "Expected=0x%02x, Read=0x%02x,", + message, start + i, cmpbuf[i], + readbuf[i]); } } if (failcount) {

1 0

Board enable needed: Gigabyte 6IEM
by Степанов Константин 16 Nov '10

16 Nov '10

11/02/2001-6IEM-6A69RG0HC-00 http://paste.flashrom.org/view.php?id=222 http://paste.flashrom.org/view.php?id=221 http://paste.flashrom.org/view.php?id=223

1 0

Ibex Peak hangs
by John 16 Nov '10

16 Nov '10

Here is my lspci: http://flashrom.pastebin.com/4zVD3z7S When attempting to read, the chipset is not detected. After editing chipset_enable.c, changing the "3b00" in '{0x8086, 0x3b02, NT, "Intel", "3400 Desktop", enable_flash_ich10}' to "3b02", the following is output, followed immediately by a hard freeze: http://flashrom.pastebin.com/jNBdZ4YC "sudo ./flashrom -VV -c SST25VF016B" output: http://flashrom.pastebin.com/UA4vBm52 After applying this patch: http://patchwork.coreboot.org/patch/1532/ the output of "sudo ./flashrom -VV -c SST25VF016B" is: http://flashrom.pastebin.com/rCEgShPk And the output of "sudo ./flashrom -VV" was another freeze and output identical to: http://flashrom.pastebin.com/jNBdZ4YC Carldani said to mention that "flashrom hangs the machine on RES/REMS probe after you add an ich10 chipset enable for PCI ID 8086:3b02". -- http://www.fastmail.fm - mmm... Fastmail...

2 3

[PATCH] build: detect availability of TYPE_x232H in libftdi
by Alex Badea 15 Nov '10

15 Nov '10

Makefile: test-compile a small program to check whether ftdi.h defines TYPE_4232H; define CONFIG_LIBFTDI_HS=1 if so. ft2232_spi: omit checking for 2232H or 4232H chip types if libftdi is too old to report them. In that case, assume the chip supports the disable-divide-by-5 command, which was the previous behaviour before chip type-checking was introduced. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- Apologies for the late reply. Test-built with libftdi-dev 0.17-1 (ubuntu lucid) and 0.13-2 (debian lenny). I added the .featuretest2.c cruft because for some reason .featuretest.c contained the utsname program at the time gcc ran. I lack the necessary make-Fu to figure out why. Cheers, Alex Makefile | 9 ++++++++- ft2232_spi.c | 2 ++ 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 3215992..82aaad1 100644 --- a/Makefile +++ b/Makefile @@ -225,6 +225,7 @@ ifeq ($(CONFIG_FT2232_SPI), yes) FTDILIBS := $(shell pkg-config --libs libftdi 2>/dev/null || printf "%s" "-lftdi -lusb") # This is a totally ugly hack. FEATURE_CFLAGS += $(shell LC_ALL=C grep -q "FTDISUPPORT := yes" .features && printf "%s" "-D'CONFIG_FT2232_SPI=1'") +FEATURE_CFLAGS += $(shell LC_ALL=C grep -q "FTDIHSSUPPORT := yes" .features && printf "%s" "-D'CONFIG_LIBFTDI_HS=1'") FEATURE_LIBS += $(shell LC_ALL=C grep -q "FTDISUPPORT := yes" .features && printf "%s" "$(FTDILIBS)") PROGRAMMER_OBJS += ft2232_spi.o endif @@ -401,6 +402,12 @@ features: compiler @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest$(EXEC_SUFFIX) $(FTDILIBS) $(LIBS) >/dev/null 2>&1 && \ ( echo "found."; echo "FTDISUPPORT := yes" >> .features.tmp ) || \ ( echo "not found."; echo "FTDISUPPORT := no" >> .features.tmp ) + @printf "Checking for FTDI high-speed chip support... " + @$(shell ( echo "#include <ftdi.h>"; \ + echo "int type = TYPE_4232H;"; ) > .featuretest2.c ) + @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest2.c -c -o .featuretest$(EXEC_SUFFIX) >/dev/null 2>&1 && \ + ( echo "found."; echo "FTDIHSSUPPORT := yes" >> .features.tmp ) || \ + ( echo "not found."; echo "FTDIHSSUPPORT := no" >> .features.tmp ) @printf "Checking for utsname support... " @$(shell ( echo "#include <sys/utsname.h>"; \ echo "struct utsname osinfo;"; \ @@ -410,7 +417,7 @@ features: compiler ( echo "found."; echo "UTSNAME := yes" >> .features.tmp ) || \ ( echo "not found."; echo "UTSNAME := no" >> .features.tmp ) @$(DIFF) -q .features.tmp .features >/dev/null 2>&1 && rm .features.tmp || mv .features.tmp .features - @rm -f .featuretest.c .featuretest$(EXEC_SUFFIX) + @rm -f .featuretest.c .featuretest2.c .featuretest$(EXEC_SUFFIX) else features: compiler @echo "FEATURES := yes" > .features.tmp diff --git a/ft2232_spi.c b/ft2232_spi.c index 7373624..dad116f 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -196,11 +196,13 @@ int ft2232_spi_init(void) exit(-1); // TODO } +#if CONFIG_LIBFTDI_HS if (ftdic->type != TYPE_2232H && ftdic->type != TYPE_4232H) { msg_pdbg("FTDI chip type %d is not high-speed\n", ftdic->type); clock_5x = 0; } +#endif if (ftdi_set_interface(ftdic, ft2232_interface) < 0) { msg_perr("Unable to select interface: %s\n", -- 1.7.0.4

1 0

P4V800D-X need BIOS modification for PCI-E
by Tomasz Czapiewski 14 Nov '10

14 Nov '10

Hi, I've been told at Phoronix forums few months ago that you can help solve my problem as you really do miracles with BIOS. The problem is that I have Asus P4V800D-X mainboard from few years which has Via PT880Ultra chipset. The mainboard is for Intel Pentium4 with socket 478 and DDR1 and has two graphic slots (AGP x8 and PCI-E 1.0). OT: The MP spec tells it could not handle both cards but I use both Radeons R3xx (AGP RV350 - 9600 and PCI-E RV370 - x300 in multiseat) just fine althrough before doing kernel mode settings on Linux I can see BIOS POST only on one of them but that's not the case... Back to topic... Some time ago I've get PCI-E 2.0 Radeon HD4670 which I wanted to use as a replace for PCI-E 1.0 Radeon X300 and I've saw it runs without problems on different MB but with the same chipset (Asrock 775Dual-VSTA - only PCI-E without AGP, P4/DualCore socket 775, both DDR1 and DDR2) after BIOS upgrade served by Asrock. I've found that the card I've get does couply PCI-E 1.0 power requirements specs so it really should be possible to use it on PCI-E 1.0 MBs. When I put this card in PCI-E slot of my MB BIOS and even Linux after BOOT does not see that anything is put in PCI-E slot (lspci, lshw, etc... does not show anything related to this card). I know that CoreBoot site does not list any of MBs that contain such chipset so I'm still stuck with proprietary BIOS from my MB vendor. As I've said before Asrock did release BIOS updates for it's MB with fixes for Radeon HD2xxx and HD3xxx cards (althrough some people reported that after this BIOS update Radeon HD4670 works, too) but Asus did forget about P4V800D-X users long time ago and haven't released and wont release such fixes. I know it will be very hard but could you look at Asrock 775Dual-VSTA BIOS changes (last BIOSes contain only fixes for Radeon HD3xxx cards) and somekind use it for fix my Asus P4V800D-X BIOS to support such cards? I don't even imagine how would you do this but anyway I've get here to ask for help as you're the only people who could do something like this. Thanks in advance. Asus P4V800D-X spec: http://motherboardland.blogspot.com/2006/01/asus-p4v800d-x-motherboard.html Asus P4V800D-X user guide: ftp://ftp.asus.com.tw/pub/ASUS/mb/sock478/p4v800d-x/e2221_P4V800D-X.pdf Asus P4V800D-X BIOS: http://dlcdnet.asus.com/pub/ASUS/mb/sock478/p4v800d-x/P4V8D704.zip Asrock 775Dual-VSTA spec: http://www.asrock.com/mb/overview.asp?Model=775Dual-vsta Asrock 775Dual-VSTA user guide: http://europe.asrock.com/manual/775Dual-VSTA.pdf Asrock 775Dual-VSTA BIOSes with changelogs: http://www.asrock.com/mb/download.asp?Model=775Dual-VSTA&o=BIOS Btw. I don't have EEPROM/BIOS programmer/flasher and my MB has only one BIOS so if you would do that BIOS modifications will flashing it will be a lot more risky than flashing any other official BIOSes? I don't mind if after flashing for any reason I could get not video or sth that would just not break Linux boot from SATA HDD so I could SSH to my machine and flash original BIOS or any other not so hard to use fallback. I don't want to change MB for the next few years because of financial reasons as I have some hardware/peripherals which use could be problematic on never MBs like these two graphic cards, PCI analog TV card, some RS232 connected hardware, a lot of DDR1 RAM, etc. With Regards, Tom

1 0

Re: [flashrom] Your flash chip is in an unknown state
by Michael Karcher 14 Nov '10

14 Nov '10

Am Sonntag, den 14.11.2010, 10:40 +0000 schrieb Matthew Chapman: > I just downloaded flashrom so I thought I had the latest version. How > do I get the latest version? There probably are no pre-compiled packages for your distribution, but you can get the source of the (not yet officially announced, but frozen) version 0.9.3 (internal revision code 1204) from http://qa.coreboot.org/snapshots/flashrom-0.9.3-r1204.tar.bz2 Read the "installation from source" section in http://flashrom.org/Downloads Regards, Michael Karcher

1 0

Your flash chip is in an unknown state
by Matthew Chapman 14 Nov '10

14 Nov '10

Hi, I inherited an old PC and decided to try out linux. I've installed the latest version of Ubuntu and all updates. The BIOS on the machine is old so I decided to try and update it using flashrom. However, it said erase failed and to contact you. I should have probably started something easier on my first attempt to use Linux... I did a backup of the current image. Here's the output: daddy@daddy-System-Name:~/Desktop/flashrom-0.9.2$ sudo flashrom -w 1018.004 flashrom v0.9.2-r1028 on Linux 2.6.35-22-generic (i686), built with libpci 3.0.0, GCC 4.4.4, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. No coreboot table found. Found chipset "VIA VT8233A", enabling flash write... OK. This chipset supports the following protocols: Non-SPI. Found chip "SST SST49LF020" (256 KB, LPC) at physical address 0xfffc0000. Flash image seems to be a legacy BIOS. Disabling checks. Writing flash chip... Erasing flash chip... ERASE FAILED at 0x00000000! Expected=0xff, Read=0x00, failed byte count from 0x00000000-0x00000fff: 0xb04 ERASE FAILED! ERASE FAILED at 0x00000000! Expected=0xff, Read=0x00, failed byte count from 0x00000000-0x00003fff: 0x3ad6 ERASE FAILED! FAILED! ERASE FAILED! FAILED! Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org! I think my machine is an ASUS A7V333 Help! Thanks, Matt

2 1

Success: C2SEA
by purpleposeidon 13 Nov '10

13 Nov '10

Output logs are attached. It says there are two chips, but I think it's actually just one. Reading the .rom off the second chip, and comparing the md5 hash with what I wrote to the first chip, gave the same thing. IDENTIFYING INFO ID from BIOS setup: C2SEA000 Newegg says I bought a "MB SUPERMICRO|MBD-C2SEA-O 775 G45 R". (I don't recommend it. And it doesn't recommend itself either; check out that interesting version number...) Motherboard product page: http://www.supermicro.com/products/motherboard/Core2Duo/G45/C2SEA.cfm DMI strings: system-manufacturer: "Supermicro" system-product-name: "C2SEA" system-version: "1234567890" baseboard-manufacturer: "Supermicro" baseboard-product-name: "C2SEA" baseboard-version: "1234567890" chassis-type: "Desktop" Let me know if there is any other info needed.

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom November 2010