flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Flashrom -V output from Tyan S2915
by Richard W.M. Jones 10 Aug '10

10 Aug '10

It still doesn't work for me. The ROM image supplied by Tyan is larger than 1MB and flashrom reports: Error: Image size doesn't match Presumably there is some sort of header in the image file. Anyway, I hope this output is useful to you in some way. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html

4 7

Re: [flashrom] [coreboot] Winflashrom plans
by Carl-Daniel Hailfinger 10 Aug '10

10 Aug '10

Hi Darmawan, nice to see you're back. flashrom has its own mailing list and I added it to CC. On 15.06.2010 21:56, Darmawan Salihun wrote: > Sorry, I haven't been able to update Winflashrom for more than 3 years now. > I'm planning to add Windows 7 support next month. > Nice! > Therefore, I'm looking for suggestions. > > A bit of Winflashrom background of the currently available Winflashrom > (at flashrom.org): > > The programming model: > a. User mode application: > - Mostly "pure" flashrom source code recompiled with MinGW. > Current flashrom can be compiled with MinGW and Cygwin, but it doesn't support any PCI accesses (USB and serial work). > - libpci recompiled with MinGW (for PCI access logic). This is > required because > the PCI access functions in the Windows API is not guaranteed > (marked as obsolete), > in Windows XP SP2 and Windows 2003 server back then. > If the PCI access functions are still available in Windows 7, can we simply ignore the "deprecated" warnings? CF8/CFC accesses from userspace are not atomic and might cause mixed up PCI accesses. > b. Device driver: > - Provides POSIX mmap() implementation in the kernel, i.e. > provides an entrypoint for mmap() function to user mode application. > Please note that we need two types of memory mapping: sys_physmap_ro_cached() and sys_physmap_rw_uncached(). For example, the low memory mapping for coreboot tables uses the readonly cached variant, and any future DMI string access will also use the readonly cached variant. Any MMIO areas (including flash access) use the uncached rw variant. Some operating systems do not care at all about cached/uncached mapping (they simply use the default caching settings of that memory region), and for those you can use the uncached rw access for both access types. > - Provides direct I/O port access for libpci. > > Well, the reason for these programming model is to reduce the burden > when moving to newer flash chip support because this programming model > "preserves" the POSIX API in the user mode application (the device > driver is generic enough). > Therefore, "only" the user mode application need to be recompiled to > support new flash chip. > > Any suggestions on what to change from the current programming model? > Current flashrom already supports PCI device flashing and onboard flashing on DOS, Linux, FreeBSD, NetBSD, DragonFlyBSD, OpenSolaris, Mac OS X and a few others. Please take a look at hwaccess.c and hwaccess.h and physmap.c for things you might want to change for Windows PCI support. I expect Windows support in flashrom to need ~60 lines of code, maybe less. The device driver (and libpci support) is a different question, though. If you have to modify any file except hwaccess.c, hwaccess.h, physmap.c or Makefile please tell us. If you have any questions, feel free to ask at flashrom(a)flashrom.org or in #flashrom on irc.freenode.net. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 3

MS-7309
by ikerc ＠web 10 Aug '10

10 Aug '10

attached

1 0

Re: [flashrom] Flashrom Issues
by Johnson, Je 10 Aug '10

10 Aug '10

Helge, Unable to recover the server that was corrupted yesterday. I've followed the procedures provided by Supermicro and I'm going to have to send back the server to be re-flashed. During my initial testing I back leveled the BIOS to 1.0B and with "flashrom" I was able to move the BIOS to version 1.1 and it boot just fine. My second test which caused the corrupted state was a change in a setting of the 1.1 BIOS (to ensure if an maintainer makes a BIOS change I can recover by loading up the original settings) and a reboot which work. When I reload 1.1 with the original settings it finished correctly but now I'm failing to boot? Thanks again, John From: Johnson, Je Sent: Tuesday, August 10, 2010 8:40 AM To: 'Wagner, Helge (GE Intelligent Platforms)' Cc: flashrom(a)flashrom.org Subject: RE: [flashrom] Flashrom Issues Helge, Thanks for the information concerning the SPI ROMs errors. I'll test the patch this morning and let you know the results. I'm still a little concerned that reloading the same BIOS and rebooting caused my server to stop booting and I'm not seeing any displays? I did run a verify after flashing the BIOS and everything seemed fine. I'm the OS technical lead here in Manassas and I support over 12 different programs. I'm pushing to start using the "flashrom" program for all of our BIOS updates (as long as the motherboards are supported). It's time we get away from the floppy/CD solution of installing and updating the BIOS. Thanks again, John From: Wagner, Helge (GE Intelligent Platforms) [mailto:Helge.Wagner@ge.com] Sent: Tuesday, August 10, 2010 2:53 AM To: Johnson, Je Cc: flashrom(a)flashrom.org Subject: EXTERNAL: RE: [flashrom] Flashrom Issues You can ignore these "spi_block_erase_xx failed" errors as for the SPI ROMs there are some erase functions defined (with different block sizes), and when at least one of them is successful, the erase will finally work. And as you told it stated that it was successfully, so what you have in the flash should be the same as in the file. Can you try to clear the RTC/CMOS RAM? (remove battery for 10 minutes, use a jumper if available, see manual)? If that doesn't help: follow the procedure outlined in the "AMI BIOS Recovery" manual at http://www.supermicro.com/support/manuals/ Some additional notes about the erase error messages: The errors occur because on the ICH SPI engines you have to program a list of supported commands. This list is filled at program start with the most common SPI commands, and if one of the commands used by the erase functions is not in this list, this specific erase will fail (but as told before: one of the erase functions defined for your SPI flash chips should work). I have created a patch to dynamically re-program the list of supported commands on-the-fly, so that no command should fail after the patch is applied. You can find the patch here: http://www.flashrom.org/pipermail/flashrom/2010-August/004331.html ("[flashrom] Speedup SST 25VF032B and 25VF064C programming"). Regards, Helge ________________________________ From: flashrom-bounces(a)flashrom.org [mailto:flashrom-bounces@flashrom.org] On Behalf Of Johnson, Je Sent: Montag, 9. August 2010 21:38 To: flashrom(a)flashrom.org Subject: [flashrom] Flashrom Issues I've been working with a Supermicro X8DA3/DAI mother board running with RHEL ES 5.4 (2.6.30.9). I compiled the latest version of "flashrom 0.9.2) and was able to capture my current BIOS by running "flashrom -r X8DA3.BIOS". After capturing the BIOS I reloaded it by issuing the following command "flashrom -w X8DA3.BIOS". I was told that the write was successful, but saw the following errors: Writing flash chip... Erasing flash before programming Erasing Flash Chip... spi_block_erase_20 failed during command execution at address 0x0 Spi_block_erase_52 failed during command execution at address 0x0 Since it stated that it was successfully, I simply reset the server and now it's failing to boot? Any help in understanding in what went wrong or if my motherboard is not fully support ( I did run the check initially to ensure the chipset was support). Thanks, John Johnson Lockheed Martin Manassas, VA

2 1

Re: [flashrom] Flashrom Issues
by Johnson, Je 10 Aug '10

10 Aug '10

Helge, Thanks for the information concerning the SPI ROMs errors. I'll test the patch this morning and let you know the results. I'm still a little concerned that reloading the same BIOS and rebooting caused my server to stop booting and I'm not seeing any displays? I did run a verify after flashing the BIOS and everything seemed fine. I'm the OS technical lead here in Manassas and I support over 12 different programs. I'm pushing to start using the "flashrom" program for all of our BIOS updates (as long as the motherboards are supported). It's time we get away from the floppy/CD solution of installing and updating the BIOS. Thanks again, John From: Wagner, Helge (GE Intelligent Platforms) [mailto:Helge.Wagner@ge.com] Sent: Tuesday, August 10, 2010 2:53 AM To: Johnson, Je Cc: flashrom(a)flashrom.org Subject: EXTERNAL: RE: [flashrom] Flashrom Issues You can ignore these "spi_block_erase_xx failed" errors as for the SPI ROMs there are some erase functions defined (with different block sizes), and when at least one of them is successful, the erase will finally work. And as you told it stated that it was successfully, so what you have in the flash should be the same as in the file. Can you try to clear the RTC/CMOS RAM? (remove battery for 10 minutes, use a jumper if available, see manual)? If that doesn't help: follow the procedure outlined in the "AMI BIOS Recovery" manual at http://www.supermicro.com/support/manuals/ Some additional notes about the erase error messages: The errors occur because on the ICH SPI engines you have to program a list of supported commands. This list is filled at program start with the most common SPI commands, and if one of the commands used by the erase functions is not in this list, this specific erase will fail (but as told before: one of the erase functions defined for your SPI flash chips should work). I have created a patch to dynamically re-program the list of supported commands on-the-fly, so that no command should fail after the patch is applied. You can find the patch here: http://www.flashrom.org/pipermail/flashrom/2010-August/004331.html ("[flashrom] Speedup SST 25VF032B and 25VF064C programming"). Regards, Helge ________________________________ From: flashrom-bounces(a)flashrom.org [mailto:flashrom-bounces@flashrom.org] On Behalf Of Johnson, Je Sent: Montag, 9. August 2010 21:38 To: flashrom(a)flashrom.org Subject: [flashrom] Flashrom Issues I've been working with a Supermicro X8DA3/DAI mother board running with RHEL ES 5.4 (2.6.30.9). I compiled the latest version of "flashrom 0.9.2) and was able to capture my current BIOS by running "flashrom -r X8DA3.BIOS". After capturing the BIOS I reloaded it by issuing the following command "flashrom -w X8DA3.BIOS". I was told that the write was successful, but saw the following errors: Writing flash chip... Erasing flash before programming Erasing Flash Chip... spi_block_erase_20 failed during command execution at address 0x0 Spi_block_erase_52 failed during command execution at address 0x0 Since it stated that it was successfully, I simply reset the server and now it's failing to boot? Any help in understanding in what went wrong or if my motherboard is not fully support ( I did run the check initially to ensure the chipset was support). Thanks, John Johnson Lockheed Martin Manassas, VA

1 0

Flashrom Issues
by Johnson, Je 10 Aug '10

10 Aug '10

I've been working with a Supermicro X8DA3/DAI mother board running with RHEL ES 5.4 (2.6.30.9). I compiled the latest version of "flashrom 0.9.2) and was able to capture my current BIOS by running "flashrom -r X8DA3.BIOS". After capturing the BIOS I reloaded it by issuing the following command "flashrom -w X8DA3.BIOS". I was told that the write was successful, but saw the following errors: Writing flash chip... Erasing flash before programming Erasing Flash Chip... spi_block_erase_20 failed during command execution at address 0x0 Spi_block_erase_52 failed during command execution at address 0x0 Since it stated that it was successfully, I simply reset the server and now it's failing to boot? Any help in understanding in what went wrong or if my motherboard is not fully support ( I did run the check initially to ensure the chipset was support). Thanks, John Johnson Lockheed Martin Manassas, VA

2 1

[PATCH][superiotool] ITE IT8500 EC support
by Donald.Huang＠ite.com.tw 10 Aug '10

10 Aug '10

The attached patch adds a register table for the IT8500 embedded controller. Here is a sample of the output: superiotool r5679 Found ITE IT8500 (id=0x8500, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 25 2d 2e 2f 30 val 85 00 01 01 00 00 00 00 01 def 85 00 01 01 00 00 NA NA 00 LDN 0x04 (System Wake-Up Control (SWUC)) idx 30 60 61 62 63 70 71 val 01 00 00 00 00 00 01 def 00 00 00 00 00 00 01 LDN 0x05 (KBC/Mouse Interface) idx 30 60 61 62 63 70 71 val 01 00 00 00 00 0c 01 def 00 00 00 00 00 0c 01 LDN 0x06 (KBC/Keyboard Interface) idx 30 60 61 62 63 70 71 val 01 00 60 00 64 01 01 def 00 00 60 00 64 01 01 LDN 0x0f (Shared Memory/Flash Interface (SMFI)) idx 30 60 61 62 63 70 71 f4 val 01 02 00 00 00 00 00 09 def 00 00 00 00 00 00 00 NA LDN 0x10 (BRAM) idx 30 62 63 70 71 f3 f4 f5 val 01 05 00 08 01 00 3f 3f def 00 00 72 08 01 NA NA NA LDN 0x11 (Power Management I/F Channel 1 (PMC1)) idx 30 60 61 62 63 70 71 val 01 00 62 00 66 00 01 def 00 00 62 00 66 01 01 LDN 0x12 (Power Management I/F Channel 2 (PMC2)) idx 30 60 61 62 63 64 65 70 71 f0 val 01 00 80 00 84 04 00 02 01 00 def 00 00 68 00 6c 00 00 01 01 NA Found SMSC SCH5317 (id=0x85, rev=0x00) at 0x2e No dump available for this Super I/O Signed-off by: Donald Huang (donald.huang(a)ite.com.tw) Signed-off by: Yung-chieh Lo (yjlou(a)google.com) Signed-off by: David Hendricks (dhendrix(a)google.com)

1 0

ASUS A8N/A8N-SLI Deluxe clarification (was: Re: erase failed on ASUS A8N-SLI Deluxe.)
by Uwe Hermann 09 Aug '10

09 Aug '10

Hi, On Tue, Dec 15, 2009 at 03:39:49PM +0100, Luc Verhaegen wrote: > On Fri, Nov 06, 2009 at 03:40:20PM +0100, Andreas Henriksson wrote: > > Hello everybody! > > > > I've been unsuccessful in updating by BIOS on my ASUS A8N-SLI Deluxe > > motherboard using flashrom. To my novice eyes it looks like the first > > 768kB has been erased and the rest left as is.... > > > > I'll put some information below.... > > > > Although i think that this will be more a flashchip issue than > anything else, please give this patch a whirl. > > Luc Verhaegen. > >From 1279b579a377a638c7f9045519a1b9e0e8497828 Mon Sep 17 00:00:00 2001 > From: Luc Verhaegen <libv(a)skynet.be> > Date: Tue, 15 Dec 2009 15:28:18 +0100 > Subject: [PATCH] Board: Add Asus A8N. > > Signed-off-by: Luc Verhaegen <libv(a)skynet.be> > --- > board_enable.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/board_enable.c b/board_enable.c > index 19a77e9..f8b1e10 100644 > --- a/board_enable.c > +++ b/board_enable.c > @@ -1128,6 +1128,7 @@ struct board_pciid_enable board_pciid_enables[] = { > {0x1106, 0x3189, 0x1043, 0x807F, 0x1106, 0x3065, 0x1043, 0x80ED, NULL, NULL, "ASUS", "A7V600-X", board_asus_a7v600x}, > {0x1106, 0x3189, 0x1043, 0x807F, 0x1106, 0x3177, 0x1043, 0x808C, NULL, NULL, "ASUS", "A7V8X", board_asus_a7v8x}, > {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL, NULL, "ASUS", "A7V8X-MX SE", w836xx_memw_enable_2e}, > + {0x10DE, 0x005E, 0x1043, 0x815A, 0x10DE, 0x0054, 0x1043, 0x815A, NULL, NULL, "ASUS", "A8N", board_shuttle_fn25}, Hi, this patch was comitted as r949. We currently mark the board-enable as untested. Andreas, can you please try if the latest flashrom version from svn trunk detects your board correctly and (more importantly) if writing/erasing the chip in that board works OK? Also, which board exactly do you have, the "ASUS A8N-SLI Deluxe" or "ASUS A8N"? If the first, we need to fix the name in our code. The A8N seems to be a laptop also, see: http://www.asus.com/product.aspx?P_ID=piUw2tNdosMjBF36 Please post the following output if possible: * flashrom -V * lspci -nnvvvxxx (as root) * superiotool -deV If you can recover please also post the output of a write or erase operation (using the latest flashrom from svn). Thanks, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org

2 1

Re: [flashrom] New Intel Chipsets
by Michael Karcher 09 Aug '10

09 Aug '10

Am Montag, den 09.08.2010, 09:55 +0200 schrieb Wagner, Helge (GE Intelligent Platforms): > Hi Michael, > > >This patch has one minor issue: flash_enable_ich_dc_spi decodes the > BIOS type select straps. > > The function is called "enable_flash_ich_dc_spi" (for those that try to > find it in the source). > > In this function the BIOS type select strap is not honored at all except > for ICH7: > ... > if (ich_generation == 7) { > if(bbs == ICH_STRAP_LPC) { > /* No further SPI initialization required */ > return ret; > } > else > /* Disable LPC/FWH if strapped to PCI or SPI */ > buses_supported = 0; > } > ... > So it should all be ok already for new chipsets. Do you agree? The state it is now (that the bbs is ignored for newer chipsets) is becasue we were already aware of the problem. Still the debugging print in the beginning is wrong, especially for 5 Series/3400 series. I'm going to commit your patch as it does not break anything, and adds working support for the new chipsets. We are checking bbs for ICH7 because that chipset supports *either* LPC/FWH *or* the SPI interface and never both interfaces run at the same time. This is different for later chipsets where the SPI chip can be addressed through the software sequencing registers even if the system boots from LPC flash. Regards, Michael Karcher

1 0

Re: [flashrom] Blank check
by Wagner, Helge (GE Intelligent Platforms) 09 Aug '10

09 Aug '10

>There is at least one (old crappy) chip that needs also the 0xff bytes. Which flash chip(s) are affected? Maybe there should be an additional field named "requires_full_programming" in the "struct flashchip". And/or there should be a command line option to switch full programming on/off (depending on the default state). Regards, Helge -----Original Message----- From: Reinder de Haan [mailto:rs@mveas.com] Sent: Samstag, 7. August 2010 01:16 To: Wagner, Helge (GE Intelligent Platforms) Subject: Re: [flashrom] Blank check Just a note : There is at least one (old crappy) chip that needs also the 0xff bytes.. afaik flashrom already skips 0xff (atleast the jedec write does iirc) greetings, Reinder Wagner, Helge (GE Intelligent Platforms) wrote: > I am not sure if this was discussed before, but i would suggest to > skip programming blocks/areas which should be programmed to the erased state. > E.g. if half of the input file consists of 0xFF areas, we could half > the programming time. > > And on chips where read is much faster than erase (e.g. SST 25VF...) > we can speed up erasing if we do a read before erase and only erase > that blocks that are not already in the erased state. > > Regards, > Helge > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom