flashrom

flashrom@flashrom.org

5 participants
9161 discussions

[commit] r1358 - trunk
by repository service 01 Jul '11

01 Jul '11

Author: stefanct Date: Fri Jul 1 02:19:12 2011 New Revision: 1358 URL: http://flashrom.org/trac/flashrom/changeset/1358 Log: add count_usable_erasers which returns the number of well-defined erasers for a chip It solves one FIXME and consequentially allows to remove a later check right now, and is used in the upcoming SFDP patch. Adds a forward declaration of check_block_eraser. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/flashrom.c Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Sun Jun 26 22:45:35 2011 (r1357) +++ trunk/flashrom.c Fri Jul 1 02:19:12 2011 (r1358) @@ -465,6 +465,8 @@ */ static int may_register_shutdown = 0; +static int check_block_eraser(const struct flashchip *flash, int k, int log); + /* Register a function to be executed on programmer shutdown. * The advantage over atexit() is that you can supply a void pointer which will * be used as parameter to the registered function upon programmer shutdown. @@ -711,6 +713,19 @@ return extract_param(&programmer_param, param_name, ","); } +/* Returns the number of well-defined erasers for a chip. + * The log parameter controls output. */ +static unsigned int count_usable_erasers(const struct flashchip *flash, int log) +{ + unsigned int usable_erasefunctions = 0; + int k; + for (k = 0; k < NUM_ERASEFUNCTIONS; k++) { + if (!check_block_eraser(flash, k, 0)) + usable_erasefunctions++; + } + return usable_erasefunctions; +} + /* start is an offset to the base address of the flash chip */ int check_erased_range(struct flashchip *flash, int start, int len) { @@ -1467,7 +1482,7 @@ return 0; } -static int check_block_eraser(struct flashchip *flash, int k, int log) +static int check_block_eraser(const struct flashchip *flash, int k, int log) { struct block_eraser eraser = flash->block_erasers[k]; @@ -1496,18 +1511,9 @@ int k, ret = 0; uint8_t *curcontents; unsigned long size = flash->total_size * 1024; - int usable_erasefunctions = 0; + unsigned int usable_erasefunctions = count_usable_erasers(flash, 0); - for (k = 0; k < NUM_ERASEFUNCTIONS; k++) - if (!check_block_eraser(flash, k, 0)) - usable_erasefunctions++; msg_cinfo("Erasing and writing flash chip... "); - if (!usable_erasefunctions) { - msg_cerr("ERROR: flashrom has no erase function for this flash " - "chip.\n"); - return 1; - } - curcontents = (uint8_t *) malloc(size); /* Copy oldcontents to curcontents to avoid clobbering oldcontents. */ memcpy(curcontents, oldcontents, size); @@ -1825,7 +1831,11 @@ return 1; msg_cerr("Continuing anyway.\n"); } - /* FIXME: Check if at least one erase function exists. */ + if(count_usable_erasers(flash, 0) == 0) { + msg_cerr("flashrom has no erase function for this " + "flash chip.\n"); + return 1; + } } if (write_it) { if (flash->tested & TEST_BAD_WRITE) {

1 0

[PATCH 09/10] fixup! ichspi.c: refactor filling and reading the fdata/spid registers (was Re: [PATCH 5/8] ichspi.c: refactor filling and reading the fdata/spid registers)
by Stefan Tauner 01 Jul '11

01 Jul '11

On Wed, 29 Jun 2011 15:06:00 -0700 David Hendricks <dhendrix(a)google.com> wrote: > A couple quick comments in-line below... > > On Mon, Jun 27, 2011 at 8:33 PM, Stefan Tauner < > stefan.tauner(a)student.tuwien.ac.at> wrote: > > > > > + static void ich_read_data(uint8_t *data, uint8_t len, int reg0_off) > > + { > > + int a; > > + uint32_t temp32 = 0; > > + > > + if (len > spi_programmer->max_data_read) > > + len = spi_programmer->max_data_read; > > + > > + for (a = 0; a < len; a++) { > > + if ((a % 4) == 0) > > + temp32 = REGREAD32(reg0_off + (a)); > > + > > + data[a] = (temp32 & (((uint32_t) 0xff) << ((a % 4) * 8))) > > + >> ((a % 4) * 8); > > > > How about "data[a] = (temp32 >> ((a % 4) * 8)) & 0xff" instead? That is > clearer IMHO, and you won't even need to break the line. (80 columns really > *is* enough :-P) i just copied the existing code from swseq and did not change it at all on purpose. improvements are welcome... the code certainly is not very readable. i wonder if this is due to some compiler optimization friendly style... but changes should be in their on commit though anyway and so we can postpone it. > On Mon, Jun 27, 2011 at 8:33 PM, Stefan Tauner < > stefan.tauner(a)student.tuwien.ac.at> wrote: > > > +static uint8_t ich_fill_data(const uint8_t *data, uint8_t len, int > > reg0_off) > > > As mentioned on IRC, the caller tends to pass in a "len" value > 255, e.g. 1 > block of 4096 bytes or more. Since len is handled as an int in the caller, > it should probably get passed in as an int here. inderdaad. i would have expected the compiler to warn in such cases. obviously i am too used to my usual embedded makefile with ~20 -W terms :) please see 9/10 and 10/10 for my proposed fixes of this (and other problems like the possibility of setting SME ) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 4

Flashrom as a payload with usb flash drive support
by Tadas Slotkus 01 Jul '11

01 Jul '11

Hi, this is for testing. Works for me with seabios. First optimize coreboot for your board, to get some space (remove microcode updates or sth, we need about 60 KB). Sorry haven't checked latest libpayload changes, so something might not work. I will write a blog post about this tomorrow. Thanks, Tadas Slotkus

1 0

msi-E350IA-E45 e-350 amd cpu
by Fabio Semino 30 Jun '11

30 Jun '11

Erase and write ok with 1.50 bios, i'm attaching the output of the operation. Nice piece of software guys Fabio from Italy

3 3

[patch] typo fix
by Mark Johnston 30 Jun '11

30 Jun '11

Fixed a small typo in an output message. Signed-off-by: Mark Johnston <markjdb at gmail.com> --- Index: dmi.c =================================================================== --- dmi.c (revision 1357) +++ dmi.c (working copy) @@ -119,7 +119,7 @@ while (!feof(dmidecode_pipe)) getc(dmidecode_pipe); if (pclose(dmidecode_pipe) != 0) { - msg_pinfo("dmidecode execution unsucessfull - continuing " + msg_pinfo("dmidecode execution unsuccessful - continuing " "without DMI info\n"); return NULL; }

2 2

Asus E35M1-I Deluxe / Winbond W25Q32
by Mattias Mattsson 30 Jun '11

30 Jun '11

Hi, I have tested flashrom r1349 on an Asus E35M1-I Deluxe rev. 1.01 (revision silk-screened on PCB) board with a Winbond W25Q32 flash chip. Probe, read, erase and write all work. Logs attached. Details for the flash part: Winbond 25Q32BVAIG 1114 This MB has an ITE IT8771E Super I/O chip (currently not fully detected by superiotool). I have confirmed the part number by visual inspection (it is not visible on photos because it is located under the heat sink). This chip seems to be specially made for Asus: http://vip.asus.com/forum/view.aspx?id=20110319032211863#20110327052243133 (Just like IT8707F..) Another interesting thing with this board is that it has a 5-pin debug port with unknown pinout. I have checked with a meter and none of the pins (except ground) are directly connected to the flash chip. Thanks, -mattias

2 2

Re: [flashrom] [Patch] Add support for EN25Q series SPI flash chips
by Carl-Daniel Hailfinger 30 Jun '11

30 Jun '11

Am 23.06.2011 01:04 schrieb David Hendricks: > I'm still not sure what the best course of action is for dealing with the > D16 versus Q16 evil twin scenario. Let's see if Carl-Daniel has further > comments. > > Signed-off-by: David Hendricks <dhendrix(a)google.com> > > As we discussed on IRC, this particular chip supports "Serial Flash > Discoverable Parameters" (SFDP). I tried to add support using the values > listed in Table 9 of their datasheet, and left a TODO to update the probe > routine later on. > Ah yes, SFDP. Stefan has implemented a patch to support that in the meantime. > On Wed, Jun 22, 2011 at 9:15 AM, Stefan Tauner wrote: >> somewhere below... >> +#define EON_EN25QH16 0x7015 > > Done. I rearranged the EN25Q* #defines a bit so they're in alphabetical > order with respect to the other EN25* chips. > > > >>> Index: flashchips.c >>> =================================================================== >>> --- flashchips.c (revision 1285) >>> +++ flashchips.c (working copy) >>> @@ -2807,6 +2807,8 @@ >>> }, >>> >>> { >>> + /* Note: EN25Q16 is an evil twin which shares the model ID >>> + but has different write protection capabilities */ >>> .vendor = "Eon", >>> .name = "EN25D16", >>> >> change according to the macro name chosen (if applicable see above) >> > The EN25D16 was there first... I'm not sure if we should change it. I > imagine the D16 is out of production, but I assume *somebody* is using it. > > WWCDD? (What Would Carl-Daniel Do?) > Evil twins... I have a patch for that: http://patchwork.coreboot.org/patch/1861/ The rules are simple: If two chips are identical from a flashrom POV (same command set and write/erase characteristics), combine them into one entry. If those chips differ, give them two entries and mark them as evil twins. Differing write protection is a corner case... we don't really have a good write protection handling in flashrom (yet), and until one of the four suggested/implemented designs is chosen, this is difficult to handle. Is there a way to probe for the write protection capabilities? Side note: Probing could be a bit more intelligent for the case of almost-identical chips. It could calculate the greatest common command set and offer to use that merging result. Other tricks are possible as well. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

[PATCH] flashrom: fix typos in comments
by Peter Huewe 30 Jun '11

30 Jun '11

This patch fixes some common misspellings/typos in comments. Changes generated using codespell and reviewed manually lenght->length 2 ocassional->occasional 1 unsucessfull->unsuccessful 1 upto->up to 5 Signed-off-by: Peter Huewe <peterhuewe(a)gmx.de> --- buspirate_spi.c | 2 +- dmi.c | 2 +- serprog-protocol.txt | 2 +- serprog.c | 10 +++++----- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/buspirate_spi.c b/buspirate_spi.c index 3b9f487..f872309 100644 --- a/buspirate_spi.c +++ b/buspirate_spi.c @@ -203,7 +203,7 @@ int buspirate_spi_init(void) * sufficient either. Use a 1.5 ms delay inside the loop to make * mostly sure that at least one USB frame had time to arrive. * Looping only 5 times is not sufficient and causes the - * ocassional failure. + * occasional failure. * Folding the delay into the loop above is not reliable either. */ for (i = 0; i < 10; i++) { diff --git a/dmi.c b/dmi.c index cda6656..836b38b 100644 --- a/dmi.c +++ b/dmi.c @@ -119,7 +119,7 @@ static char *get_dmi_string(const char *string_name) while (!feof(dmidecode_pipe)) getc(dmidecode_pipe); if (pclose(dmidecode_pipe) != 0) { - msg_pinfo("dmidecode execution unsucessfull - continuing " + msg_pinfo("dmidecode execution unsuccessful - continuing " "without DMI info\n"); return NULL; } diff --git a/serprog-protocol.txt b/serprog-protocol.txt index c5464a4..52f901a 100644 --- a/serprog-protocol.txt +++ b/serprog-protocol.txt @@ -88,7 +88,7 @@ This define listing should help C coders - (it's here to be the single source fo #define S_CMD_Q_BUSTYPE 0x05 /* Query supported bustypes */ #define S_CMD_Q_CHIPSIZE 0x06 /* Query supported chipsize (2^n format) */ #define S_CMD_Q_OPBUF 0x07 /* Query operation buffer size */ -#define S_CMD_Q_WRNMAXLEN 0x08 /* Query Write to opbuf: Write-N maximum lenght */ +#define S_CMD_Q_WRNMAXLEN 0x08 /* Query Write to opbuf: Write-N maximum length */ #define S_CMD_R_BYTE 0x09 /* Read a single byte */ #define S_CMD_R_NBYTES 0x0A /* Read n bytes */ #define S_CMD_O_INIT 0x0B /* Initialize operation buffer */ diff --git a/serprog.c b/serprog.c index b91e376..124aa41 100644 --- a/serprog.c +++ b/serprog.c @@ -56,7 +56,7 @@ static int serprog_shutdown(void *data); #define S_CMD_Q_BUSTYPE 0x05 /* Query supported bustypes */ #define S_CMD_Q_CHIPSIZE 0x06 /* Query supported chipsize (2^n format) */ #define S_CMD_Q_OPBUF 0x07 /* Query operation buffer size */ -#define S_CMD_Q_WRNMAXLEN 0x08 /* Query opbuf-write-N maximum lenght */ +#define S_CMD_Q_WRNMAXLEN 0x08 /* Query opbuf-write-N maximum length */ #define S_CMD_R_BYTE 0x09 /* Read a single byte */ #define S_CMD_R_NBYTES 0x0A /* Read n bytes */ #define S_CMD_O_INIT 0x0B /* Initialize operation buffer */ @@ -168,9 +168,9 @@ static void sp_synchronize(void) usleep(1000 * 1000); sp_flush_incoming(); - /* Then try upto 8 times to send syncnop and get the correct special * - * return of NAK+ACK. Timing note: upto 10 characters, 10*50ms = * - * upto 500ms per try, 8*0.5s = 4s; +1s (above) = upto 5s sync * + /* Then try up to 8 times to send syncnop and get the correct special * + * return of NAK+ACK. Timing note: up to 10 characters, 10*50ms = * + * up to 500ms per try, 8*0.5s = 4s; +1s (above) = up to 5s sync * * attempt, ~1s if immediate success. */ for (i = 0; i < 8; i++) { int n; @@ -180,7 +180,7 @@ static void sp_synchronize(void) msg_pdbg("."); fflush(stdout); for (n = 0; n < 10; n++) { - c = sp_sync_read_timeout(5); /* wait upto 50ms */ + c = sp_sync_read_timeout(5); /* wait up to 50ms */ if (c != S_NAK) continue; c = sp_sync_read_timeout(2); -- 1.7.3.4

2 1

[PATCH 10/10] fixup! ichspi.c: add support for Intel Hardware Sequencing (was Re: [PATCH 8/8] squash! ichspi:c add support for Intel Hardware Sequencing)
by Stefan Tauner 30 Jun '11

30 Jun '11

the missing "& HSFC_FDBC" there makes it possible to enable smm interrupts as happened to dhendrix. lesson to learn: always check/limit input values even if they were previously constants ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH 5/8] ichspi.c: refactor filling and reading the fdata/spid registers
by David Hendricks 30 Jun '11

30 Jun '11

A couple quick comments in-line below... On Mon, Jun 27, 2011 at 8:33 PM, Stefan Tauner < stefan.tauner(a)student.tuwien.ac.at> wrote: > > + static void ich_read_data(uint8_t *data, uint8_t len, int reg0_off) > + { > + int a; > + uint32_t temp32 = 0; > + > + if (len > spi_programmer->max_data_read) > + len = spi_programmer->max_data_read; > + > + for (a = 0; a < len; a++) { > + if ((a % 4) == 0) > + temp32 = REGREAD32(reg0_off + (a)); > + > + data[a] = (temp32 & (((uint32_t) 0xff) << ((a % 4) * 8))) > + >> ((a % 4) * 8); > How about "data[a] = (temp32 >> ((a % 4) * 8)) & 0xff" instead? That is clearer IMHO, and you won't even need to break the line. (80 columns really *is* enough :-P) On Mon, Jun 27, 2011 at 8:33 PM, Stefan Tauner < stefan.tauner(a)student.tuwien.ac.at> wrote: > +static uint8_t ich_fill_data(const uint8_t *data, uint8_t len, int > reg0_off) As mentioned on IRC, the caller tends to pass in a "len" value > 255, e.g. 1 block of 4096 bytes or more. Since len is handled as an int in the caller, it should probably get passed in as an int here. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom