flashrom January 2010

flashrom@flashrom.org

49 participants
216 discussions

successful: ST M50FLW040A chip
by Lenar Shakirov 22 Jan '10

22 Jan '10

Hi! Because this chip listed here as unknown: > http://www.flashrom.org/Supported_hardware#Supported_chips I want you to know that this chip works fine out of the box with the latest flashrom release (r3892). Feel free to add this board now to the "Supported chips" list READ: > [root@testpc ~]# flashrom -r /tmp/bios.bin > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "AMD CS5536", enabling flash write... OK. > Found chip "ST M50FLW040A" (512 KB) at physical address 0xfff80000. > === > This flash part has status UNTESTED for operations: PROBE READ ERASE > WRITE > Please email a report to flashrom(a)coreboot.org if any of the above > operations > work correctly for you with this flash part. Please include the full > output > from the program, including chipset found. Thank you for your help! > === > Reading flash... done. WRITE: > [root@testpc ~]# flashrom -w /tmp/bios.bin > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "AMD CS5536", enabling flash write... OK. > Found chip "ST M50FLW040A" (512 KB) at physical address 0xfff80000. > === > This flash part has status UNTESTED for operations: PROBE READ ERASE > WRITE > Please email a report to flashrom(a)coreboot.org if any of the above >operations > work correctly for you with this flash part. Please include the full > output > from the program, including chipset found. Thank you for your help! > === > Flash image seems to be a legacy BIOS. Disabling checks. > Programming page: > 0000 at address: 0x00000000 DONE BLOCK 0x0 > 0001 at address: 0x00010000 DONE BLOCK 0x10000 > 0002 at address: 0x00020000 DONE BLOCK 0x20000 > 0003 at address: 0x00030000 DONE BLOCK 0x30000 > 0004 at address: 0x00040000 DONE BLOCK 0x40000 > 0005 at address: 0x00050000 DONE BLOCK 0x50000 > 0006 at address: 0x00060000 DONE BLOCK 0x60000 > 0007 at address: 0x00070000 DONE BLOCK 0x70000 ERASE: > [root@testpc ~]# flashrom -E > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "AMD CS5536", enabling flash write... OK. > Found chip "ST M50FLW040A" (512 KB) at physical address 0xfff80000. > === > This flash part has status UNTESTED for operations: PROBE READ ERASE > WRITE > Please email a report to flashrom(a)coreboot.org if any of the above >operations > work correctly for you with this flash part. Please include the full > output > from the program, including chipset found. Thank you for your help! > === > Erasing flash chip... Erasing page: > 0000 at address: 0x00000000 DONE BLOCK 0x0 > 0001 at address: 0x00010000 DONE BLOCK 0x10000 > 0002 at address: 0x00020000 DONE BLOCK 0x20000 > 0003 at address: 0x00030000 DONE BLOCK 0x30000 > 0004 at address: 0x00040000 DONE BLOCK 0x40000 > 0005 at address: 0x00050000 DONE BLOCK 0x50000 > 0006 at address: 0x00060000 DONE BLOCK 0x60000 > 0007 at address: 0x00070000 DONE BLOCK 0x70000 > > FAILED! > ERROR at 0x00080000: Expected=0xff, Read=0x00 VERIFY: > [root@testpc ~]# flashrom -v /tmp/bios.bin > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "AMD CS5536", enabling flash write... OK. > Found chip "ST M50FLW040A" (512 KB) at physical address 0xfff80000. > === > This flash part has status UNTESTED for operations: PROBE READ ERASE > WRITE > Please email a report to flashrom(a)coreboot.org if any of the above >operations > work correctly for you with this flash part. Please include the full > output > from the program, including chipset found. Thank you for your help! > === > Flash image seems to be a legacy BIOS. Disabling checks. > Verifying flash... VERIFIED. Thanks a lot! -- С уважением, инженер отдела ИИС ООО «Центр» Шакиров Ленар Наилевич shakirov(a)cg.ru (843) 533-88-14 Российская Федерация Казань, ул. Зинина, 3а 420029, а/я 81 http://www.cg.ru/

1 0

[PATCH] Use of CFLAGS and CPPFLAGS
by Stefan Reinauer 22 Jan '10

22 Jan '10

See patch -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info(a)coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

3 5

[commit] r880 - trunk
by svn＠flashrom.org 22 Jan '10

22 Jan '10

Author: stepan Date: 2010-01-22 11:49:33 +0100 (Fri, 22 Jan 2010) New Revision: 880 Modified: trunk/Makefile Log: backout unintentional chunk. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/Makefile =================================================================== --- trunk/Makefile 2010-01-22 02:53:30 UTC (rev 879) +++ trunk/Makefile 2010-01-22 10:49:33 UTC (rev 880) @@ -221,7 +221,7 @@ rm -f .dependencies .features .libdeps dep: - $(CC) $(CPPFLAGS) $(SVNDEF) -MM *.c > .dependencies + @$(CC) $(CPPFLAGS) $(SVNDEF) -MM *.c > .dependencies strip: $(PROGRAM) $(STRIP) $(STRIP_ARGS) $(PROGRAM)

1 0

Re: [flashrom] [PATCH] Dediprog SF100 support
by Carl-Daniel Hailfinger 22 Jan '10

22 Jan '10

Hi Stefan, On 14.01.2010 14:08, Stefan Reinauer wrote: > On 1/14/10 5:24 AM, Carl-Daniel Hailfinger wrote: > >> Dediprog SF100 support. Very fragile, lots of stuff guessed from logs. >> May explode spontaneously. >> >> I think I know enough to actually use it to ID the chip, but that's it. >> A USB log with which includes writing an image from the original >> software (pretty much any image) would help clear up a few ambiguities. >> >> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> >> >> > > Awesome..! > Thanks! > It seems to be talking to the device and get through the initialization, > but it ends up with no "SPI" chips being "incompatible": > Actually, that's intentional. That way I could avoid hooking up the driver in the SPI core (which would mean I'd have to create dummy command functions) and still get initialization testing. > MacPro:flashrom stepan$ ./flashrom -p dediprog -V > flashrom v0.9.1-r862 > Found USB device (0483:dada). > Sending RDID > Receiving response: 20 20 16 10 00 00 00 00 00 00 00 00 00 00 00 00 Which flash chip is this? The response suggests a ST M25P32 flash chip, but the extra "10" at the end looks rather strange. > Not sure if this code is intended: > >> /* URB 9. Command Receive Device String. */ >> memset(buf, 0, sizeof(buf)); >> ret = usb_control_msg(dediprog_handle, 0xc2, 0x8, 0xff, 0xff, buf, >> 0x10, DEFAULT_TIMEOUT); >> if ((ret != 0x10) || !memcmp(buf, "SF100 V:2.1.1 ", 0x10)) { >> > This would bail out if the version string is "SF100 V:2.1.1 " > Right, that's a bug. Considering that this was coded at 5am, I'm surprised there was only one bug. >> msg_perr("Unexpected response 3!\n"); >> return 1; >> } >> > Here I added this: > >> buf[0xf]=0; >> msg_pdbg("Found a Dediprog %s\n", buf); >> That potentially truncates the string. I'll use strnlen/strncpy to write the string to a separate buffer which is big enough. > Which got me: > > flashrom v0.9.1-r862 > Found USB device (0483:dada). > Found a Dediprog SF100 V:3.1.8 > Hm. The best idea might be to match against the model name and the major version. > Let me know if you need more information > A log with SniffUsb 2.0.0006 from http://www.pcausa.com/Utilities/UsbSnoop/ would be very appreciated. I wrote a tool to decode the log generated with that SniffUsb version. Feel free to point me to a private upload via IRC (the log may contain programmer serial numbers). What the log should contain: - Plugging in the SF100 - Starting the programming software - SPI device detection/probe - Full read - Erase (optional) - Full write (optional) - No custom settings (but you can do a probe-only run with changed settings in another file if you want to help decode a few more commands) It would be cool if you could use a small SPI chip (4 Mbit or so) because the logs roughly have 4x-20x the size of the flash chip. Please do not use a SST chip (log would be at least 100x the size of the flash chip). Pretty much all other vendors are OK. I will post an updated patch soon. Regards, Carl-Daniel -- Developer quote of the year: "We are juggling too many chainsaws and flaming arrows and tigers."

3 24

[commit] r879 - trunk
by svn＠flashrom.org 22 Jan '10

22 Jan '10

Author: hailfinger Date: 2010-01-22 03:53:30 +0100 (Fri, 22 Jan 2010) New Revision: 879 Modified: trunk/dediprog.c trunk/spi.c Log: Add write support. Speed up reads by a factor of 4 by switching block size from 4 to 16. Add support for 4 byte RDID. Add USB error decoding via usb_strerror. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/dediprog.c =================================================================== --- trunk/dediprog.c 2010-01-21 20:26:30 UTC (rev 878) +++ trunk/dediprog.c 2010-01-22 02:53:30 UTC (rev 879) @@ -145,8 +145,9 @@ int dediprog_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len) { - /* Maximum read length is 4 bytes for now. */ - return spi_read_chunked(flash, buf, start, len, 4); + 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); } int dediprog_spi_send_command(unsigned int writecnt, unsigned int readcnt, @@ -154,19 +155,22 @@ { int ret; + msg_pspew("%s, writecnt=%i, readcnt=%i\n", __func__, writecnt, readcnt); /* Paranoid, but I don't want to be blamed if anything explodes. */ - if ((writecnt != 1) && (writecnt != 4)) + if (writecnt > 5) { msg_perr("Untested writecnt=%i, aborting.\n", writecnt); - if (readcnt > 4) + return 1; + } + /* 16 byte reads should work. */ + if (readcnt > 16) { msg_perr("Untested readcnt=%i, aborting.\n", readcnt); - if ((readcnt == 0) && (writecnt != 1)) - msg_perr("Untested writecnt=%i, readcnt=%i combination, " - "aborting.\n", writecnt, readcnt); + return 1; + } ret = usb_control_msg(dediprog_handle, 0x42, 0x1, 0xff, readcnt ? 0x1 : 0x0, (char *)writearr, writecnt, DEFAULT_TIMEOUT); if (ret != writecnt) { - msg_perr("Command Send SPI failed, ret=%i, expected %i!\n", - ret, writecnt); + msg_perr("Send SPI failed, expected %i, got %i %s!\n", + writecnt, ret, usb_strerror()); return 1; } if (!readcnt) @@ -174,8 +178,8 @@ memset(readarr, 0, readcnt); ret = usb_control_msg(dediprog_handle, 0xc2, 0x01, 0xbb8, 0x0000, (char *)readarr, readcnt, DEFAULT_TIMEOUT); if (ret != readcnt) { - msg_perr("Command Receive SPI failed, ret=%i, expected %i!\n", - ret, readcnt); + msg_perr("Receive SPI failed, expected %i, got %i %s!\n", + readcnt, ret, usb_strerror()); return 1; } return 0; Modified: trunk/spi.c =================================================================== --- trunk/spi.c 2010-01-21 20:26:30 UTC (rev 878) +++ trunk/spi.c 2010-01-22 02:53:30 UTC (rev 879) @@ -335,6 +335,9 @@ #if BUSPIRATE_SPI_SUPPORT == 1 case SPI_CONTROLLER_BUSPIRATE: #endif +#if DEDIPROG_SUPPORT == 1 + case SPI_CONTROLLER_DEDIPROG: +#endif return probe_spi_rdid_generic(flash, 4); default: printf_debug("4b ID not supported on this SPI controller\n");

1 0

FOSDEM DevRoom schedule completed.
by Luc Verhaegen 22 Jan '10

22 Jan '10

http://www.coreboot.org/FOSDEM_2010 Schedule is now complete: * 13:00 : Peter Stuge - coreboot introduction. * 14:00 : Peter Stuge - coreboot and PC technical details. * 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot. * 16:00 : Rudolf Marek - coreboot board porting. * 17:00 : Carl-Daniel Hailfinger - Flashrom. * 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering. Hope to see tons of people there. Luc Verhaegen.

2 1

[PATCH] Avoid bogus gcc warning
by Michael Karcher 21 Jan '10

21 Jan '10

recent gcc/glibc combinations warn about ignoring the fgets() result. The problem exists on Ubuntu 9.10 with current updates. This "fix" of the non-problem (as I check ferror() afterwards) should even be a (negligible) performance optimization. Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> --- dmi.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dmi.c b/dmi.c index ca75461..d165e9f 100644 --- a/dmi.c +++ b/dmi.c @@ -79,8 +79,8 @@ void dmi_init(void) printf_debug("DMI pipe open error\n"); goto out_free; } - fgets(answerbuf, DMI_MAX_ANSWER_LEN, dmidecode_pipe); - if (ferror(dmidecode_pipe)) + if (!fgets(answerbuf, DMI_MAX_ANSWER_LEN, dmidecode_pipe) && + ferror(dmidecode_pipe)) { printf_debug("DMI pipe read error\n"); pclose(dmidecode_pipe); -- 1.6.5

1 0

[commit] r878 - trunk
by svn＠flashrom.org 21 Jan '10

21 Jan '10

Author: stepan Date: 2010-01-21 21:26:30 +0100 (Thu, 21 Jan 2010) New Revision: 878 Modified: trunk/Makefile Log: This patch fixes the use of CFLAGS and CPPFLAGS in the flashrom makefile Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Sean Nelson <audiohacked(a)gmail.com> Modified: trunk/Makefile =================================================================== --- trunk/Makefile 2010-01-20 20:55:53 UTC (rev 877) +++ trunk/Makefile 2010-01-21 20:26:30 UTC (rev 878) @@ -33,11 +33,11 @@ STRIP_ARGS = -s endif ifeq ($(OS_ARCH), Darwin) -CFLAGS += -I/usr/local/include -LDFLAGS += -framework IOKit -framework DirectIO -L/usr/local/lib +CPPFLAGS += -I/opt/local/include -I/usr/local/include +LDFLAGS += -framework IOKit -framework DirectIO -L/opt/local/lib -L/usr/local/lib endif ifeq ($(OS_ARCH), FreeBSD) -CFLAGS += -I/usr/local/include +CPPFLAGS += -I/usr/local/include LDFLAGS += -L/usr/local/lib endif @@ -221,7 +221,7 @@ rm -f .dependencies .features .libdeps dep: - @$(CC) $(CPPFLAGS) $(SVNDEF) -MM *.c > .dependencies + $(CC) $(CPPFLAGS) $(SVNDEF) -MM *.c > .dependencies strip: $(PROGRAM) $(STRIP) $(STRIP_ARGS) $(PROGRAM) @@ -230,7 +230,7 @@ @printf "Checking for a C compiler... " @$(shell ( echo "int main(int argc, char **argv)"; \ echo "{ return 0; }"; ) > .test.c ) - @$(CC) $(CFLAGS) $(LDFLAGS) .test.c -o .test >/dev/null && \ + @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .test.c -o .test >/dev/null && \ echo "found." || ( echo "not found."; \ rm -f .test.c .test; exit 1) @rm -f .test.c .test @@ -242,7 +242,7 @@ echo "struct pci_access *pacc;"; \ echo "int main(int argc, char **argv)"; \ echo "{ pacc = pci_alloc(); return 0; }"; ) > .test.c ) - @$(CC) -c $(CFLAGS) .test.c -o .test.o >/dev/null 2>&1 && \ + @$(CC) -c $(CPPFLAGS) $(CFLAGS) .test.c -o .test.o >/dev/null 2>&1 && \ echo "found." || ( echo "not found."; echo; \ echo "Please install libpci headers (package pciutils-devel)."; \ echo "See README for more information."; echo; \ @@ -251,7 +251,7 @@ @$(shell ( echo "#include <pci/pci.h>"; \ echo "int main(int argc, char **argv)"; \ echo "{ return 0; }"; ) > .test1.c ) - @$(CC) $(CFLAGS) $(LDFLAGS) .test1.c -o .test1 -lpci $(LIBS) >/dev/null 2>&1 && \ + @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .test1.c -o .test1 -lpci $(LIBS) >/dev/null 2>&1 && \ echo "found." || ( echo "not found."; echo; \ echo "Please install libpci (package pciutils)."; \ echo "See README for more information."; echo; \ @@ -282,7 +282,7 @@ echo "struct ftdi_context *ftdic = NULL;"; \ echo "int main(int argc, char **argv)"; \ echo "{ return ftdi_init(ftdic); }"; ) > .featuretest.c ) - @$(CC) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest $(FTDILIBS) $(LIBS) >/dev/null 2>&1 && \ + @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest $(FTDILIBS) $(LIBS) >/dev/null 2>&1 && \ ( echo "found."; echo "FTDISUPPORT := yes" >> .features.tmp ) || \ ( echo "not found."; echo "FTDISUPPORT := no" >> .features.tmp ) @$(DIFF) -q .features.tmp .features >/dev/null 2>&1 && rm .features.tmp || mv .features.tmp .features

1 0

[Patch] Boards: Remove it8705_rom_write_enable.
by Luc Verhaegen 20 Jan '10

20 Jan '10

4 8

[Patch] Boards: Add max_rom_decode_parallel entry to board enable table.
by Luc Verhaegen 20 Jan '10

20 Jan '10

2 4

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

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom January 2010