flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Re: [flashrom] [PATCH 5/6] improve output in case run_opcode fails
by Stefan Tauner 30 Apr '11

30 Apr '11

On Fri, 1 Apr 2011 14:33:19 +0200 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote: > diff --git a/ichspi.c b/ichspi.c > index b24b6a0..0ad4f20 100644 > --- a/ichspi.c > +++ b/ichspi.c > ... > @@ -974,7 +973,19 @@ int ich_spi_send_command(unsigned int writecnt, > unsigned int readcnt, > result = run_opcode(*opcode, addr, count, data); > if (result) { > - msg_pdbg("run OPCODE 0x%02x failed\n", > opcode->opcode); > + msg_pdbg("run OPCODE 0x%02x failed at address > 0x%06x.\n", > + opcode->opcode, addr); > + /* Print out the data array if it contains data to > write. > + * Errors are detected before the received data is > read back into > + * the array so it won't make sense to print it > then. */ > + if (((opcode->spi_type == > SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS) || > + (opcode->spi_type == > SPI_OPCODE_TYPE_WRITE_NO_ADDRESS))) { > + msg_pspew("The data was:\n"); > + uint8_t i; > + for(i=0; i<count; i++){ > + msg_pspew("%3d: 0x%02x\n", i, > data[i]); > + } > + } > } self-NAK :) uint8_t is too small and could result in an endless loop. oops. :( this should not happen normally, because devices supported by ichspi.c allow only 16B or 64B data lengths, but we could be called with something bigger i guess. how should this be solved? since "count" will get truncated implicitly when it is used as parameter for "run_opcode" we could do so explicitly before the loop. or an if around the loop checking for count<256. also i would like to include the count like so: "run OPCODE 0x%02x failed at address 0x%06x (length %d).\n" RFC :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

Here's the now (if) ready patch.
by Brandon Dowdy 30 Apr '11

30 Apr '11

Probably this patch is ready now. If not, then a few more problems to fix then.

1 0

Re: [flashrom] [PATCH] ichspi: Increase timeout to 60s for atomic operations
by Carl-Daniel Hailfinger 30 Apr '11

30 Apr '11

Am 29.04.2011 16:01 schrieb Michael Karcher: > Signed-off-by: Michael Karcher<flashrom(a)mkarcher.dialup.fu-berlin.de> > Thanks for the patch and for tracking this down and for writing a thorough analysis! Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Could you fix the whitespace before commit? > @@ -581,6 +588,7 @@ static int ich7_run_opcode(OPCODE op, uint32_t offset, > case 1: > /* Atomic command (preop+op) */ > temp16 |= SPIC_ACS; > + timeout = 100 * 1000* 60; /* 60 seconds */ > Should have a space after 1000 > break; > } > > @@ -720,6 +734,7 @@ static int ich9_run_opcode(OPCODE op, uint32_t offset, > case 1: > /* Atomic command (preop+op) */ > temp32 |= SSFC_ACS; > + timeout = 100 * 1000* 60; /* 60 seconds */ > Same here. > break; > } > > Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

[commit] r1290 - trunk
by repository service 30 Apr '11

30 Apr '11

Author: mkarcher Date: Sat Apr 30 00:11:36 2011 New Revision: 1290 URL: http://flashrom.org/trac/flashrom/changeset/1290 Log: ichspi: Increase timeout to 60s for atomic operations Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/ichspi.c Modified: trunk/ichspi.c ============================================================================== --- trunk/ichspi.c Wed Apr 27 16:34:08 2011 (r1289) +++ trunk/ichspi.c Sat Apr 30 00:11:36 2011 (r1290) @@ -572,7 +572,14 @@ } temp16 |= ((uint16_t) (opcode_index & 0x07)) << 4; - /* Handle Atomic */ + timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ + /* Handle Atomic. Atomic commands include three steps: + - sending the preop (mainly EWSR or WREN) + - sending the main command + - waiting for the busy bit (WIP) to be cleared + This means the timeout must be sufficient for chip erase + of slow high-capacity chips. + */ switch (op.atomic) { case 2: /* Select second preop. */ @@ -581,6 +588,7 @@ case 1: /* Atomic command (preop+op) */ temp16 |= SPIC_ACS; + timeout = 100 * 1000 * 60; /* 60 seconds */ break; } @@ -591,7 +599,6 @@ REGWRITE16(ICH7_REG_SPIC, temp16); /* Wait for Cycle Done Status or Flash Cycle Error. */ - timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ while (((REGREAD16(ICH7_REG_SPIS) & (SPIS_CDS | SPIS_FCERR)) == 0) && --timeout) { programmer_delay(10); @@ -711,7 +718,14 @@ } temp32 |= ((uint32_t) (opcode_index & 0x07)) << (8 + 4); - /* Handle Atomic */ + timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ + /* Handle Atomic. Atomic commands include three steps: + - sending the preop (mainly EWSR or WREN) + - sending the main command + - waiting for the busy bit (WIP) to be cleared + This means the timeout must be sufficient for chip erase + of slow high-capacity chips. + */ switch (op.atomic) { case 2: /* Select second preop. */ @@ -720,6 +734,7 @@ case 1: /* Atomic command (preop+op) */ temp32 |= SSFC_ACS; + timeout = 100 * 1000 * 60; /* 60 seconds */ break; } @@ -730,7 +745,6 @@ REGWRITE32(ICH9_REG_SSFS, temp32); /* Wait for Cycle Done Status or Flash Cycle Error. */ - timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ while (((REGREAD32(ICH9_REG_SSFS) & (SSFS_CDS | SSFS_FCERR)) == 0) && --timeout) { programmer_delay(10);

1 0

Here's the properly fixed patch.
by Brandon Dowdy 29 Apr '11

29 Apr '11

Here is the properly and completely fixed patch.

1 0

Re: [flashrom] Problem H55M-S Foxconn
by Idwer Vollering 29 Apr '11

29 Apr '11

Forwarding his reply. 2011/4/29 Marcelo Sales Moreira <marcelo.sales(a)litecnologia.com.br>: > Good morning, > > I tested with version 0.9.3 and not work with the bios file that the > vendor sent me to work I had to update the bios file with custom bios / > upgrade software and then save with AFUDOS.EXE FlashROM, ai yes I could > replicate the bios saved for other boards. > > Attached is the original bios and bios saved with FlashROM Attached were: bios_save_flash.rom 4194304 bytes bios_logo.rom 1048576 bytes You can create a file that has the same size as "bios_save_flash.rom" / the chip size by doing this: cat bios_logo.rom bios_logo.rom bios_logo.rom bios_logo.rom >> bios_logo_4megabyte.rom We are also interested in the output of "flashrom -V -w bios_logo_4megabyte.rom" > > Att > Marcelo Moreira Sales > > > Em Qui, 2011-04-28 às 22:12 +0200, Idwer Vollering escreveu: >> 2011/4/28 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>: >> > >> > >> > Begin forwarded message: >> > >> > Date: Thu, 28 Apr 2011 13:46:51 -0300 >> > From: Marcelo Sales Moreira <marcelo.sales(a)litecnologia.com.br> >> > To: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> >> > Subject: Re: [flashrom] Problem H55M-S Foxconn >> > >> > >> > Good afternoon, >> > >> > Attached is the output from-v FlashROM >> >> By looking at the output, I recommend to use version 0.9.3 or building >> the latest development code: >> http://www.flashrom.org/Downloads#Installation_from_source >> >> > >> > Att >> > Marcelo Moreira Sales >> > >> > >> > -- >> > Kind regards/Mit freundlichen Grüßen, Stefan Tauner >> > >> > _______________________________________________ >> > flashrom mailing list >> > flashrom(a)flashrom.org >> > http://www.flashrom.org/mailman/listinfo/flashrom >> > >> > >

1 0

[PATCH] ichspi: Increase timeout to 60s for atomic operations
by Michael Karcher 29 Apr '11

29 Apr '11

Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> --- ichspi.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/ichspi.c b/ichspi.c index ed92893..db5ec75 100644 --- a/ichspi.c +++ b/ichspi.c @@ -572,7 +572,14 @@ static int ich7_run_opcode(OPCODE op, uint32_t offset, } temp16 |= ((uint16_t) (opcode_index & 0x07)) << 4; - /* Handle Atomic */ + timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ + /* Handle Atomic. Atomic commands include three steps: + - sending the preop (mainly EWSR or WREN) + - sending the main command + - waiting for the busy bit (WIP) to be cleared + This means the timeout must be sufficient for chip erase + of slow high-capacity chips. + */ switch (op.atomic) { case 2: /* Select second preop. */ @@ -581,6 +588,7 @@ static int ich7_run_opcode(OPCODE op, uint32_t offset, case 1: /* Atomic command (preop+op) */ temp16 |= SPIC_ACS; + timeout = 100 * 1000* 60; /* 60 seconds */ break; } @@ -591,7 +599,6 @@ static int ich7_run_opcode(OPCODE op, uint32_t offset, REGWRITE16(ICH7_REG_SPIC, temp16); /* Wait for Cycle Done Status or Flash Cycle Error. */ - timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ while (((REGREAD16(ICH7_REG_SPIS) & (SPIS_CDS | SPIS_FCERR)) == 0) && --timeout) { programmer_delay(10); @@ -711,7 +718,14 @@ static int ich9_run_opcode(OPCODE op, uint32_t offset, } temp32 |= ((uint32_t) (opcode_index & 0x07)) << (8 + 4); - /* Handle Atomic */ + timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ + /* Handle Atomic. Atomic commands include three steps: + - sending the preop (mainly EWSR or WREN) + - sending the main command + - waiting for the busy bit (WIP) to be cleared + This means the timeout must be sufficient for chip erase + of slow high-capacity chips. + */ switch (op.atomic) { case 2: /* Select second preop. */ @@ -720,6 +734,7 @@ static int ich9_run_opcode(OPCODE op, uint32_t offset, case 1: /* Atomic command (preop+op) */ temp32 |= SSFC_ACS; + timeout = 100 * 1000* 60; /* 60 seconds */ break; } @@ -730,7 +745,6 @@ static int ich9_run_opcode(OPCODE op, uint32_t offset, REGWRITE32(ICH9_REG_SSFS, temp32); /* Wait for Cycle Done Status or Flash Cycle Error. */ - timeout = 100 * 60; /* 60 ms are 9.6 million cycles at 16 MHz. */ while (((REGREAD32(ICH9_REG_SSFS) & (SSFS_CDS | SSFS_FCERR)) == 0) && --timeout) { programmer_delay(10); -- 1.7.4.1

1 0

reading BIOS setting using Flashrom
by ganesh.patwardhan＠wipro.com 29 Apr '11

29 Apr '11

Hi, Is it possible to read only BIOS setting and store in a file using Flashrom? Example :- say I want to read BIOS settings like Signature, boot order, Numlock setting etc... from Linux using Flashrom. Regards Ganesh Patwardhan Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

CHIPSET: Sun Fire x4100
by Stefan Reinauer 29 Apr '11

29 Apr '11

flashrom v0.9.3-r1283 on Linux 2.6.31.14-0.6-default (x86_64), built with libpci 3.1.3, GCC 4.4.1 [gcc-4_4-branch revision 150839], 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 "NVIDIA CK804", enabling flash write... OK. WARNING: unexpected second chipset match: "NVIDIA CK804" ignoring, please report lspci and board URL to flashrom(a)flashrom.org with 'CHIPSET: your board name' in the subject line. This chipset supports the following protocols: Non-SPI. Found chip "ST M50FLW080A" (1024 KB, LPC,FWH) at physical address 0xfff00000. === This flash part has status UNTESTED for operations: WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -Vw, -VE), and mention which mainboard or programmer you tested. Please mention your board in the subject line. Thanks for your help! No operations were specified. ra:~ # lspci 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev f1) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a4) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev f2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4) 80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev f1) 80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3) 80:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3) 80:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3) 80:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3) 80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 80:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12) 80:10.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12) 80:11.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12) 80:11.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12) 86:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 03) 86:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 03) 86:02.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064 PCI-X Fusion-MPT SAS (rev 02)

1 0

Debugging FT4232H
by David Hendricks 29 Apr '11

29 Apr '11

Hi, I'm using Flashrom with an FTDI FT4232H to read a 1MB SPI ROM (w25q80), but am encountering difficulties. I believe we may be missing some steps in ft2232_spi_init(), however I don't have much experience with libftdi or usb debugging so I hope someone on the list does :-) When the programmer is plugged into a "full-speed" USB port slow, things seem to work well. However, when plugged into a "high-speed" port, bytes simply disappear. There does not seem to be a pattern with regard to where the problems start. Sometimes it will fail very early and Flashrom will not be able to detect the chip. Sometimes we'll get lucky and we can read the full chip. It can fail anywhere in between. The only pattern I've seen is that usb bulk reads return less than the requested number of bytes before it fails entirely. For example, if we request 256 bytes, then it might return 256-N data bytes. libftdi will request the remaining bytes, and libusb will provide the remaining N data bytes. On the next 256-byte request, libusb will not return any data bytes (only the 2-byte USB header). I added a bunch of debug prints to libftdi and libusb to get a better idea of what's happening deeper in the stack. Here is a sample of what we see (with added comments) when it fails: Invocation: flashrom -p ft2232_spi:type=4232H,port=A -r /tmp/foo.bin Successful 256-byte read: writecnt: 4, writearr: 03 02 c3 00 <--- SPI command. 03 indicates read, 02 c3 00 is the address. getting buffer from ftdi... usb_bulk_read ret: 258 "offset" from ftdi_read_data(): 256 get_buf returned with 0 A troubled 256-byte read follows: writecnt: 4, writearr: 03 02 c4 00 getting buffer from ftdi... usb_bulk_read ret: 45 <--- (45-2) + (142-2) + (75-2) = 256 usb_bulk_read ret: 142 usb_bulk_read ret: 75 "offset" from ftdi_read_data(): 256 get_buf returned with 0 And now it simply fails to read anything: writecnt: 4, writearr: 03 02 c5 00 getting buffer from ftdi... usb_bulk_read ret: 211 <--- returns 209 data bytes usb_bulk_read ret: 2 <--- fails to read any more data bytes "offset" from ftdi_read_data(): 209 usb_bulk_read ret: 2 get_buf: no data was available "offset" from ftdi_read_data(): 0 usb_bulk_read ret: 2 libftdi's ftdi_read_data() will loop indefinitely here until the remaining data bytes arrive, which never happens. Any ideas on what could be causing this are appreciated! -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom