flashrom June 2011

flashrom@flashrom.org

50 participants
297 discussions

Re: [flashrom] [PATCH 3/8] ichspi.c: add FPB (Flash Partition Boundary) macros and init printing
by Carl-Daniel Hailfinger 01 Jul '11

01 Jul '11

Am 28.06.2011 05:33 schrieb Stefan Tauner: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > I think we really have to introduce a dbg2 level for messages and cut down on printing such stuff for -V. Until that happens, we can use dbg. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Re: [flashrom] [PATCH 2/8] ichspi.c: simplify ich_set_bbar
by Carl-Daniel Hailfinger 01 Jul '11

01 Jul '11

Am 28.06.2011 05:33 schrieb Stefan Tauner: > less code, documenting better what the differences are (i.e. offset of BBAR only). > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > Good code simplification. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Re: [flashrom] [PATCH 1/8] ichspi.c: make REGWRITE* macros safer
by Carl-Daniel Hailfinger 01 Jul '11

01 Jul '11

Am 28.06.2011 05:33 schrieb Stefan Tauner: > '+' does have a quite high precedence so "calling" those macros with a term including weaker > operators in the off parameter may have unexpected consequences > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > Good find! Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Re: [flashrom] [PATCH 2/3] add check_block_erasers which returns the number of well-defined erasers for a chip
by Carl-Daniel Hailfinger 01 Jul '11

01 Jul '11

Am 24.06.2011 16:53 schrieb Stefan Tauner: > This can be used in various situations (including one in the upcoming SFDP patch) and > removes one FIXME in current HEAD. Needed to move check_block_eraser (which checks a > single eraser) up to avoid (upcoming) forward declaration(s). > Since nobody objected to the "forward declarations" RFC, I think we can safely say that moving code around inside a file is a bad idea. Please kill that part. > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > flashrom.c | 70 ++++++++++++++++++++++++++++++++++------------------------- > 1 files changed, 40 insertions(+), 30 deletions(-) > > diff --git a/flashrom.c b/flashrom.c > index 6979d84..aed10aa 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ @@ > +/* Returns the number of well-defined erasers for a chip. > + * The log parameter controls output. */ > +static int check_block_erasers(const struct flashchip *flash, int log) > Hm. Can you call it count_usable_erasers or count_usable_block_erasers instead? > +{ > + 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; > +} > + > Rest looks good to me. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 10

[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

← Newer
1
...
5
6
7
8
9
10
11
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom June 2011