flashrom

flashrom@flashrom.org

9092 discussions

Start a nNew thread

Board Enable Needed
by Zach Stuart 27 Jan '10

27 Jan '10

Here is the relevant data requested Sincerely Zach Stuart zach(a)silvernetworks.net

2 2

flashrom with MSI P35 Platinum
by Mike Hokenson 26 Jan '10

26 Jan '10

Hi, I successfully downgraded the bios on my MSI P35 Platinum (MS-7345) <http://www.msi.com/index.php?func=proddesc&maincat_no=1&prod_no=1212> from v1.0C to v1.0A using flashrom-0.9.1. I didn't save the output from the write, but here's a flashrom without any args: # flashrom flashrom v0.9.1-r792 No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. This chipset supports the following protocols: LPC,FWH,SPI. Calibrating delay loop... OK. Found chip "Winbond W25x80" (1024 KB, SPI) at physical address 0xfff00000. No operations were specified. I saw the P35 Neo2-FIR on the supported hardware list, but I don't think that's the right MS-XXXX number for the Neo2-FIR. MS-7345 is my board. (from dmidecode) Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: V1.10 Release Date: 11/10/2008 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 1024 kB BIOS Revision: 8.14 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD Product Name: MS-7345 Version: 1.0 Thanks, Mike

1 0

[PATCH]Support large COM ports on Win32
by Patrick Georgi 26 Jan '10

26 Jan '10

Hi, Windows wants large COM ports (COM10 and higher) to be given in UPC notation, ie. \\.\COM10 To aid the user, the Win32 code now rewrites all devices with COM prefix (case insensitive) to UPC. Tested with both high and low COM port. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>

2 2

[commit] r883 - trunk
by svn＠flashrom.org 26 Jan '10

26 Jan '10

Author: oxygene Date: 2010-01-26 21:58:40 +0100 (Tue, 26 Jan 2010) New Revision: 883 Modified: trunk/serial.c Log: Windows wants UNC names for COM ports >9 (legacy COM ports only work with one digit). As UNC also works for smaller names, just retarget all requests for dev=COMx on win32 to \\.\COMx. Tested with large and small COM port numbers on XP. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/serial.c =================================================================== --- trunk/serial.c 2010-01-25 22:55:33 UTC (rev 882) +++ trunk/serial.c 2010-01-26 20:58:40 UTC (rev 883) @@ -105,7 +105,15 @@ { #ifdef _WIN32 HANDLE fd; - fd = CreateFile(dev, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); + char* dev2 = dev; + if ((strlen(dev) > 3) && (tolower(dev[0])=='c') && (tolower(dev[1])=='o') && (tolower(dev[2])=='m')) { + dev2 = malloc(strlen(dev)+5); + strcpy(dev2, "\\\\.\\"); + strcpy(dev2+4, dev); + } + fd = CreateFile(dev2, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); + if (dev2 != dev) + free(dev2); if (fd == INVALID_HANDLE_VALUE) { sp_die("Error: cannot open serial port"); }

1 0

[PATCH]Binary access to files
by Patrick Georgi 25 Jan '10

25 Jan '10

Hi, attached patch opens files in "binary" mode for reading and writing. That doesn't matter on unix, but on Windows (and maybe Mac OS) there will be newline conversions that don't belong into binary images. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Patrick

2 2

[commit] r882 - trunk
by svn＠flashrom.org 25 Jan '10

25 Jan '10

Author: oxygene Date: 2010-01-25 23:55:33 +0100 (Mon, 25 Jan 2010) New Revision: 882 Modified: trunk/flashrom.c Log: Open binary files in binary mode. No change on UNIX (or Mac OS, according to its documentation), but fixes operation on Windows. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/flashrom.c =================================================================== --- trunk/flashrom.c 2010-01-23 15:15:19 UTC (rev 881) +++ trunk/flashrom.c 2010-01-25 22:55:33 UTC (rev 882) @@ -834,7 +834,7 @@ printf("Error: No filename specified.\n"); return 1; } - if ((image = fopen(filename, "w")) == NULL) { + if ((image = fopen(filename, "wb")) == NULL) { perror(filename); exit(1); } @@ -1154,7 +1154,7 @@ fprintf(stderr, "Continuing anyway.\n"); } } - if ((image = fopen(filename, "r")) == NULL) { + if ((image = fopen(filename, "rb")) == NULL) { perror(filename); programmer_shutdown(); exit(1);

1 0

Successfully bios update
by Germán Gabriel Estévez 25 Jan '10

25 Jan '10

I successfully updated the bios of my MSI 975x Platinum Powerup Edition, attached is the output of the read and write operations. Thanks for the program, it was very useful to me.

1 0

[PATCH] Fix erase-blocks specification for the Atmel AT49F002(N)(T)
by Uwe Hermann 23 Jan '10

23 Jan '10

See patch. According to my datasheet these erase-blocks are incorrect. I tested an AT49F002(N)T chip and "./flashrom -E" did indeed fail: ERASE FAILED at 0x0003c000! Expected 0xff, Read=0x44, failed byte count from 0x0003c000-0x0003ffff: 0x3fc0 The failing location is always 0x3fc0 if the chip contains a certain image of random bytes. If I program another image the failing place is reproducibly always 0x3ef4. So it likely differs per image that is programmed on the chip before the erase is done. However, a read after an -E operation results in an image will all-0xff nonetheless. Interestingly, doing -E a second time will also report SUCCESS. My attached patch also reports the same error, still. As 0x3c000-0x03ffff is the 16KB boot block, the write-protection mechanism for that boot block seems to interfere. AFAIK we don't yet implement that mechanism (I might post a patch later). Anyway, the attached patch is more correct than svn anyway (unless I read the datasheet wrong), so we should apply it nevertheless IMHO. Oh, one question -- is the order of erase-blocks as specified in flashchips.c relevant? AT49F002(N) and AT49F002(N)T have different orders right now. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

4 5

[PATCH]Full USB init for dediprog
by Patrick Georgi 23 Jan '10

23 Jan '10

Hi, attached patch changes the dediprog code to properly initialize the access to the device. It's definitely necessary should bulk transfers be used (as in my local tree), and won't do harm. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Patrick

2 1

[PATCH] SST39SF512 support
by Uwe Hermann 23 Jan '10

23 Jan '10

See patch. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom