flashrom

flashrom@flashrom.org

7 participants
9163 discussions

Re: [flashrom] [PATCH 2/4] layout: Add -i <image>[:<file>] support.
by Carl-Daniel Hailfinger 18 Sep '13

18 Sep '13

Am 12.09.2013 22:40 schrieb Stefan Tauner: > Add an optional sub-parameter to the -i parameter to allow building the > image to be written from multiple files. This will also allow regions to > be read from flash and written to separate image files in a later patch. > Document the whole layout handling including the new features a bit better. > > based on chromiumos' > d0ea9ed71e7f86bb8e8db2ca7c32a96de25343d8 > Signed-off-by: David Hendricks <dhendrix(a)chromium.org> > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Double signoff. > --- > flashrom.8.tmpl | 47 +++++++++++++-------------- > flashrom.c | 8 +++-- > layout.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++------- > 3 files changed, 116 insertions(+), 37 deletions(-) See my other mail for the man page review. > diff --git a/flashrom.c b/flashrom.c > index a00347e..cd15de7 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ -1993,9 +1993,11 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, > } > msg_cinfo("done.\n"); > > - // This should be moved into each flash part's code to do it > - // cleanly. This does the job. > - handle_romentries(flash, oldcontents, newcontents); > + if (handle_romentries(flash, oldcontents, newcontents)) { Missing ret=1 > + msg_gerr("Could not prepare the data to be written due to problems with the layout,\n" > + "aborting.\n"); > + goto out; > + } > > // //////////////////////////////////////////////////////////// > > diff --git a/layout.c b/layout.c > index 86351b8..20fe303 100644 > --- a/layout.c > +++ b/layout.c > @@ -33,6 +38,7 @@ typedef struct { > unsigned int end; > unsigned int included; > char name[256]; > + char *file; > } romentry_t; > > /* rom_entries store the entries specified in a layout file and associated run-time data */ > @@ -85,6 +91,7 @@ int read_romlayout(char *name) > rom_entries[num_rom_entries].start = strtol(tstr1, (char **)NULL, 16); > rom_entries[num_rom_entries].end = strtol(tstr2, (char **)NULL, 16); That code wasn't changed, but should we use strtoul here instead? > rom_entries[num_rom_entries].included = 0; > + rom_entries[num_rom_entries].file = NULL; > num_rom_entries++; > } > > @@ -167,19 +169,36 @@ int process_include_args(void) > > /* User has specified an area, but no layout file is loaded. */ > if (num_rom_entries == 0) { > - msg_gerr("Region requested (with -i \"%s\"), " > - "but no layout data is available.\n", > + msg_gerr("Region requested (with -i/--image \"%s\"),\n" > + "but no layout data is available. To include one use the -l/--layout syntax).\n", > include_args[0]); > return 1; > } > > for (i = 0; i < num_include_args; i++) { > - if (find_romentry(include_args[i]) < 0) { > - msg_gerr("Invalid region specified: \"%s\".\n", > - include_args[i]); > + char *name = strtok(include_args[i], ":"); /* -i <image>[:<file>] */ Side note: We should state in the man page that ":" is not a valid character for region names. > + int idx = find_romentry(name); > + if (idx < 0) { > + msg_gerr("Invalid region specified: \"%s\".\n", include_args[i]); > return 1; > } > + rom_entries[idx].included = 1; > found++; > + > + char *file = strtok(NULL, ""); /* remaining non-zero length token or NULL */ > + if (file != NULL) { > +#ifdef __LIBPAYLOAD__ > + msg_gerr("Error: No file I/O support in libpayload\n"); > + return 1; > +#else > + file = strdup(file); > + if (file == NULL) { > + msg_gerr("Out of memory!\n"); > + return 1; > + } > + rom_entries[idx].file = file; > +#endif > + } > } > > msg_ginfo("Using region%s: \"%s\"", num_include_args > 1 ? "s" : "", > @@ -232,6 +253,57 @@ romentry_t *get_next_included_romentry(unsigned int start) > return best_entry; > } > > +/* If a file name is specified for this region, read the file contents and > + * overwrite @newcontents in the range specified by @entry. */ > +static int read_content_from_file(romentry_t *entry, uint8_t *newcontents) This whole function is a broken copypaste from read_buf_from_file() in flashrom.c. Please use the original function, and add additional parameters to it if needed. > +{ > + char *file = entry->file; > + if (file == NULL) > + return 0; > + > +#ifdef __LIBPAYLOAD__ > + msg_gerr("Error: No file I/O support in libpayload\n"); > + return 1; > +#else > + int len = entry->end - entry->start + 1; > + FILE *fp; > + if ((fp = fopen(file, "rb")) == NULL) { > + msg_gerr("Error: Opening layout image file \"%s\" failed: %s\n", file, strerror(errno)); "layout image"? Sorry, that name won't fly. > + return 1; > + } > + > + struct stat file_stat; > + if (fstat(fileno(fp), &file_stat) != 0) { > + msg_gerr("Error: Getting metadata of layout image file \"%s\" failed: %s\n", file, strerror(errno)); > + fclose(fp); > + return 1; > + } > + if (file_stat.st_size != len) { > + msg_gerr("Error: Image size (%jd B) doesn't match the flash chip's size (%d B)!\n", Somebody forgot to change the text here. > + (intmax_t)file_stat.st_size, len); > + fclose(fp); > + return 1; > + } > + > + int numbytes = fread(newcontents + entry->start, 1, len, fp); > + if (ferror(fp)) { > + msg_gerr("Error: Reading layout image file \"%s\" failed: %s\n", file, strerror(errno)); > + fclose(fp); > + return 1; > + } > + if (fclose(fp)) { > + msg_gerr("Error: Closing layout image file \"%s\" failed: %s\n", file, strerror(errno)); > + return 1; > + } > + if (numbytes != len) { > + msg_gerr("Error: Failed to read layout image file \"%s\" completely.\n" > + "Got %d bytes, wanted %d!\n", file, numbytes, len); > + return 1; > + } > + return 0; > +#endif > +} > + > int handle_romentries(const struct flashctx *flash, uint8_t *oldcontents, uint8_t *newcontents) > { > unsigned int start = 0; > @@ -259,6 +331,10 @@ int handle_romentries(const struct flashctx *flash, uint8_t *oldcontents, uint8_ > if (entry->start > start) > memcpy(newcontents + start, oldcontents + start, > entry->start - start); > + /* For included region, copy from file if specified. */ > + if (read_content_from_file(entry, newcontents) != 0) > + return 1; I don't know if this behaviour is completely intended. AFAICS the following command line flashrom -r read.rom -l layout.txt -i region1:region1.bin will read the full flash chip, then replace the contents of region1 in the flash image with the contents of region1.bin, then write the combined image to disk. I don't have a problem with that, but I think it warrants thinking about it. > + > /* Skip to location after current romentry. */ > start = entry->end + 1; > /* Catch overflow. */ Looks good otherwise. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 2

Re: [flashrom] [PATCH 2/4] layout: Add -i <image>[:<file>] support.
by Stefan Tauner 17 Sep '13

17 Sep '13

On Tue, 17 Sep 2013 12:55:38 -0700 David Hendricks <dhendrix(a)google.com> wrote: > > As I tried to explain, I have no problem with the "region image" apart > > from the image/file ambiguity. "region image file" is totally fine with > > me. > > > > Be careful not to conflate the concept of an image with individual regions > (or maybe I already have). A region is simply an address range inside of an > image. A region is an address range inside a chip-size/full/ROM image. The thing that gets a name by the use of a layout file and which is selected by that name with an -i parameter. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH 2/4] layout: Add -i <image>[:<file>] support.
by Carl-Daniel Hailfinger 17 Sep '13

17 Sep '13

Am 12.09.2013 22:40 schrieb Stefan Tauner: > Add an optional sub-parameter to the -i parameter to allow building the > image to be written from multiple files. This will also allow regions to > be read from flash and written to separate image files in a later patch. > Document the whole layout handling including the new features a bit better. > > based on chromiumos' > d0ea9ed71e7f86bb8e8db2ca7c32a96de25343d8 > Signed-off-by: David Hendricks <dhendrix(a)chromium.org> > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> First review round, man page only. I want to get our terms right before the existing confusion gets worse. Code review follows in a separate mail. > --- > flashrom.8.tmpl | 47 +++++++++++++-------------- > flashrom.c | 8 +++-- > layout.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++------- > 3 files changed, 116 insertions(+), 37 deletions(-) > > diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl > index 5ede423..b1371e4 100644 > --- a/flashrom.8.tmpl > +++ b/flashrom.8.tmpl > @@ -6,7 +6,7 @@ flashrom \- detect, read, write, verify and erase flash chips > \fB\-p\fR <programmername>[:<parameters>] > [\fB\-E\fR|\fB\-r\fR <file>|\fB\-w\fR <file>|\fB\-v\fR <file>] \ > [\fB\-c\fR <chipname>] > - [\fB\-l\fR <file> [\fB\-i\fR <image>]] [\fB\-n\fR] [\fB\-f\fR]] > + [\fB\-l\fR <file> [\fB\-i\fR <image>[:<file>]]...] [\fB\-n\fR] [\fB\-f\fR]] The naming conflict between "image" (region) and "image file" (the file we write to or read from the flash chip) is very unfortunate. Unfortunately, we also lack good free single letters for a better name. While --region (instead of --image) would be a really good choice for the long option name, -r (read) and -R (revision/version) are already used and -i is an admittedly difficult association for --region. The new syntax also has one catch: You can't specify a separate file for a region without having that region actively written/read. While this won't be a problem for ordinary users, it might pose a problem for vendors like Google who want to use flashrom inside their firmware update process. Such update processes (at least when I look at the processes of other vendors) often do specify all files to source an image from, but they desire to select the to-be-written parts of the flash separately. Not sure if there is any practical relevance to this observation, though. David? > [\fB\-V\fR[\fBV\fR[\fBV\fR]]] [\fB-o\fR <logfile>] > .SH DESCRIPTION > .B flashrom > @@ -103,44 +103,45 @@ size for the flash bus. > * Force write even if write is known bad. > .TP > .B "\-l, \-\-layout <file>" > -Read ROM layout from > +Read layout entries from Do we want to call them "ROM layout", "flash layout" or simply "layout"? My preferences are 1. "ROM layout" 2. "flash layout". > .BR <file> . > .sp > -flashrom supports ROM layouts. This allows you to flash certain parts of > -the flash chip only. A ROM layout file contains multiple lines with the > -following syntax: > +A layout entry describes an address region of the flash chip and gives it a name. This allows to access certain > +parts of the flash chip only. A layout file can contain multiple entries one per line with the following syntax: I am not a native speaker, but the sentences above look odd. Suggested rewording : flashrom supports reading/writing/erasing flash chips in whole (default) or in part (when a ROM layout is given). Layouts are stored in layout files. A layout entry describes an address region/range in the virtual file representing the flash chip contents and assigns a name to that region. A layout file consists of one or more lines with the following syntax: > .sp > -.B " startaddr:endaddr imagename" > +.B " startaddr:endaddr regionname" > .sp > .BR "startaddr " "and " "endaddr " > -are hexadecimal addresses within the ROM file and do not refer to any > -physical address. Please note that using a 0x prefix for those hexadecimal > +are hexadecimal addresses within the ROM file representing the flash ROM contents. are hexadecimal addresses within the virtual file representing the flash chip contents > +Please note that using a 0x prefix for those hexadecimal > numbers is not necessary, but you can't specify decimal/octal numbers. > -.BR "imagename " "is an arbitrary name for the region/image from" > -.BR " startaddr " "to " "endaddr " "(both addresses included)." > +.BR "regionname " "is an arbitrary name for the region from " > +.BR "startaddr " "to " "endaddr " "(both addresses included)." > .sp > -Example: > +Example content of file rom.layout: > .sp > 00000000:00008fff gfxrom > 00009000:0003ffff normal > 00040000:0007ffff fallback We should use 0x prefixes in the example. That helps readability. > .sp > -If you only want to update the image named > -.BR "normal " "in a ROM based on the layout above, run" > -.sp > -.B " flashrom \-p prog \-\-layout rom.layout \-\-image normal \-w some.rom" > +.TP > +.B "\-i, \-\-image <name>[:<file>]" > +Work on the flash region > +.B name > +instead of the full address space if a layout file is given and parsed correctly. > +Multiple such image parameters can be used to include the union of different regions. s/include/work on/ > +The optional > +.B file > +parameter specifies the name of an image file that is used to map the contents of that very region only. "image file" naming again. > +This is useful for example if you want to write only a part of the flash chip and leave everything else alone > +without preparing an image of the complete chip manually: Uhh... sounds denglish. Suggested rewording: This allows replacing part of a ROM file with contents from another file before writing the resulting contents to the flash chip, eliminating the separate step of manually assembling a combined ROM image. > .sp > -To update only the images named > -.BR "normal " "and " "fallback" ", run:" > +If you only want to update the image named Plural from "images" was removed by accident. > +.BR "normal " "and " "fallback " "in a ROM based on the layout mentioned above, run" > .sp > .B " flashrom \-p prog \-l rom.layout \-i normal -i fallback \-w some.rom" > .sp > -Overlapping sections are not supported. > -.TP > -.B "\-i, \-\-image <imagename>" > -Only flash region/image > -.B <imagename> > -from flash layout. > +.RB "Overlapping sections are resolved in an implementation-dependent manner - do " "not " "rely on it." I reserve the right to have flashrom error out on overlapping regions unless you can convince me such an error would be a bad idea. Suggested rewording: .RB "Overlapping region definitions are resolved in an implementation-dependent manner or may yield an error - do " "not " "rely on any observed flashrom behaviour." > .TP > .B "\-L, \-\-list\-supported" > List the flash chips, chipsets, mainboards, and external programmers Regards, Carl-Daniel -- http://www.hailfinger.org/

3 9

Re: [flashrom] [PATCH 4/4] layout: Better file parsing.
by Carl-Daniel Hailfinger 17 Sep '13

17 Sep '13

[Incomplete review, more follows later. Please already respond to this so I can decide how to proceed with the review.] Am 12.09.2013 22:40 schrieb Stefan Tauner: > A complete rewrite of the layout file parser: > - safe (unlike before) > - support for comments > - supports including/sourcing of other layout files (relative to the including > file as well as via absolute paths) > - checks for duplicate region names (breaks inclusion loops too) > - can handle region names and layout file names with spaces correctly > - way better diagnostics > - no more character arrays in struct romentry_t but pointers only > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> General comments about the format: Can we change the first line slightly to # flashrom layout v2 and also mandate that region names may neither contain whitespace nor ":" now "#", please? I'd also like to drop support for v1 layouts as part of the switchover. There is a conversion script and thus no reason to support the old interface any more. The command line invocation changed anyway, so nobody will be able to reuse old commands, and then there's no point to reuse old layout files. This should reduce the amount of code needed. > flashrom.8.tmpl | 50 +++++--- > layout.c | 348 +++++++++++++++++++++++++++++++++++++++++++++++--------- > 2 files changed, 331 insertions(+), 67 deletions(-) > > diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl > index b1371e4..8793e91 100644 > --- a/flashrom.8.tmpl > +++ b/flashrom.8.tmpl > @@ -106,23 +106,46 @@ size for the flash bus. > Read layout entries from > .BR <file> . > .sp > -A layout entry describes an address region of the flash chip and gives it a name. This allows to access certain > -parts of the flash chip only. A layout file can contain multiple entries one per line with the following syntax: > +A layout file is useful for interacting with parts of a flash chip only. It can contain comments which are > +started by a pound sign (#) and causes all following characters on the same line to be ignored with one > +exception: Every layout file > +.B must > +start with a comment in the following form to define the version of the file. Example for the current version 2: > +.sp > +.B " # flashrom layout 2" > +.sp > +Every other line may contain either a command to include another layout file, a layout entry or white space > +(and an optional comment). > +.sp > +To include another file you can use the > +.sp > +.B " source <path>" > +.sp > +syntax where > +.B path > +specifies the absolute or relative path to the file to be included. Relative paths are interpreted to be > +relative to the file containing the include command. If the path contains spaces it has to be written in double > +quotes, or else only the part before the first space will be used. Ouch! Can we please either enforce double-quotes everywhere or nowhere? > +.sp > +Each layout entry describes an address region of the flash chip and gives it a name. One entry per line is > +allowed with the following syntax: > .sp > .B " startaddr:endaddr regionname" > .sp > .BR "startaddr " "and " "endaddr " > -are hexadecimal addresses within the ROM file representing the flash ROM contents. > -Please note that using a 0x prefix for those hexadecimal > -numbers is not necessary, but you can't specify decimal/octal numbers. > -.BR "regionname " "is an arbitrary name for the region from " > -.BR "startaddr " "to " "endaddr " "(both addresses included)." > +are addresses within the ROM file representing the flash ROM contents. They are interpreted in the 'usual' form > +i.e.\ a leading 0 means octal, leading 0x or 0X means hexadecimal, everything else is just decimal. Octal support is a really bad idea IMHO. Especially when people try to align numbers by adding leading zeros. > +.BR "regionname " "is the name for the region from " "startaddr " "to " "endaddr " "(both addresses included)." > +If the name contains spaces it has to be written in double quotes, or else only the part before the first space > +will be used. > .sp > Example content of file rom.layout: > .sp > - 00000000:00008fff gfxrom > - 00009000:0003ffff normal > - 00040000:0007ffff fallback > + # flashrom layout 2 > + source /home/flashrom/include.layout > + 0x00000000:0x00008fff "gfx rom" > + 0x00009000:0x0003ffff normal > + 0x00040000:0x0007ffff fallback > .sp > .TP > .B "\-i, \-\-image <name>[:<file>]" > @@ -136,10 +159,11 @@ parameter specifies the name of an image file that is used to map the contents o > This is useful for example if you want to write only a part of the flash chip and leave everything else alone > without preparing an image of the complete chip manually: > .sp > -If you only want to update the image named > -.BR "normal " "and " "fallback " "in a ROM based on the layout mentioned above, run" > +If you only want to update the regions named > +.BR "normal " "and " "gfx rom " "in a ROM based on the layout mentioned above, run" > .sp > -.B " flashrom \-p prog \-l rom.layout \-i normal -i fallback \-w some.rom" > + > +.B " flashrom \-p prog \-l rom.layout \-i normal -i ""gfx rom"" \-w some.rom" > .sp > .RB "Overlapping sections are resolved in an implementation-dependent manner - do " "not " "rely on it." > .TP BIG FAT NOTE: The review below is of a patch which had the deleted lines stripped out to improve readability (the patch was almost unreadable due to code moves). > diff --git a/layout.c b/layout.c > index 20fe303..5b4bee4 100644 > --- a/layout.c > +++ b/layout.c > @@ -22,9 +22,11 @@ > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > +#include <ctype.h> > #include <limits.h> > #include <errno.h> > #ifndef __LIBPAYLOAD__ > +#include <libgen.h> Not available on Windows AFAICS. > #include <fcntl.h> > #include <sys/stat.h> > #endif > @@ -32,12 +34,15 @@ > #include "programmer.h" > > #define MAX_ROMLAYOUT 32 > +#define MAX_ENTRY_LEN 1024 > +#define WHITESPACE_CHARS " \t" > +#define INCLUDE_INSTR "source" > > typedef struct { > unsigned int start; > unsigned int end; > unsigned int included; > - char name[256]; > + char *name; > char *file; > } romentry_t; > > @@ -50,59 +55,307 @@ static int num_rom_entries = 0; /* the number of valid rom_entries */ > static char *include_args[MAX_ROMLAYOUT]; > static int num_include_args = 0; /* the number of valid include_args. */ > > +/* returns the index of the entry (or a negative value if it is not found) */ > +static int find_romentry(char *name) > { > int i; > + msg_gspew("Looking for region \"%s\"... ", name); > + for (i = 0; i < num_rom_entries; i++) { > + if (strcmp(rom_entries[i].name, name) == 0) { > + msg_gspew("found.\n"); > + return i; > + } > + } > + msg_gspew("not found.\n"); > + return -1; > +} > > +/* FIXME: While libpayload has no file I/O itself, code using libflashrom could still provide layout information > + * obtained by other means like user input or by fetching it from somewhere else. Therefore the parsing code > + * should be separated from the file reading code eventually. */ > +#ifndef __LIBPAYLOAD__ > +/** Parse a \em possibly quoted string. > + * > + * The function expects \a startp to point to the string to be parsed without leading white space. If the > + * string starts with a quotation mark it looks for the second one and removes both in-place, if not then it > + * looks for the first white space character and uses that as delimiter of the wanted string. > + * After returning \a startp will point to a string that is either the original string with the quotation marks > + * removed, or the first word of that string before a white space. > + * If \a endp is not NULL it will be set to point to the first character after the parsed string, which might > + * well be the '\0' at the end of the string pointed to by \a startp if there are no more characters. > + * > + * @param start Points to the input string. > + * @param end Is set to the first char following the input string. > + * @return 0 on success, 1 if the parsed string is empty or a quotation mark is not matched. > + */ > +static int unquote_string(char **startp, char **endp) If we disallow spaces in region names and if we make include file names either always-quoted or never-quoted, this complete function can die. > +{ > + char *end; > + size_t len; > + if (**startp == '"') { > + (*startp)++; > + len = strcspn(*startp, "\""); > + } else { > + len = strcspn(*startp, WHITESPACE_CHARS); > + } > + if (len == 0) > + return 1; > > + end = *startp + len; > + if (*end != '\0') { > + *end = '\0'; > + end++; > } > + if (endp != NULL) > + *endp = end; > + msg_gspew("%s: start=\"%s\", end=\"%s\"\n", __func__, *startp, end); > + return 0; > +} > > +/** Parse one line in a layout file. > + * @param file_name The name of the file this line originates from. > + * @param file_version The version of the layout specification to be used. Only v2, please. > + * @param entry If not NULL fill it with the parsed data, else just detect errors and print diagnostics. > + * @return 1 on error, > + * 0 if the line could be parsed into a layout entry succesfully, > + * -1 if a file was successfully sourced. Very odd choice of return codes. Negative values are usually associated with errors. -- http://www.hailfinger.org/

2 3

Here's my flashrom-V to help support my motherboard/chipset/flash chip s-io...
by Joshua Gnitecki 16 Sep '13

16 Sep '13

[root@manjaro joshuag]# flashrom --programmer internal --chip W25Q80.V -V flashrom v0.9.7-r1711 on Linux 3.4.61-1-MANJARO (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.2.0, GCC 4.8.1 20130725 (prerelease), little endian Command line (5 args): flashrom --programmer internal --chip W25Q80.V -V Calibrating delay loop... OS timer resolution is 1 usecs, 1405M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 myus = 9998 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "s5500z" DMI string system-version: " " DMI string baseboard-manufacturer: "PEGATRON CORPORATION" DMI string baseboard-product-name: "2A99" DMI string baseboard-version: "6.01" DMI string chassis-type: "Desktop" Found chipset "NVIDIA MCP61" with PCI ID 10de:03e0. Enabling flash write... This chipset is not really supported yet. Guesswork... ISA/LPC bridge reg 0x8a contents: 0x40, bit 6 is 1, bit 5 is 0 Flash bus type is SPI SPI on this chipset is WIP. Please report any success or failure by mailing us the verbose output to flashrom(a)flashrom.org, thanks! Found SMBus device 10de:03eb at 00:01:1 MCP SPI BAR is at 0xfec80000 Mapping NVIDIA MCP6x SPI at 0x00000000fec80000, unaligned size 0x544. SPI control is 0x0002, req=0, gnt=0 Please send the output of "flashrom -V" to flashrom(a)flashrom.org with your board name: flashrom -V as the subject to help us finish support for your chipset. Thanks. OK. The following protocols are supported: SPI. Probing for Winbond W25Q80.V, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4014 Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) at physical address 0xfff00000. Chip status register is 0x00. This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). No operations were specified. -- I'm jmon...live in Austin, TX.

1 0

2A99 Motherboard flashrom -V puked-out!
by Joshua Gnitecki 15 Sep '13

15 Sep '13

Here's my flashrom-V to help support my motherboard/chipset/flash chip s-io... [root@manjaro joshuag]# flashrom --programmer internal --chip W25Q80.V -V flashrom v0.9.7-r1711 on Linux 3.4.61-1-MANJARO (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.2.0, GCC 4.8.1 20130725 (prerelease), little endian Command line (5 args): flashrom --programmer internal --chip W25Q80.V -V Calibrating delay loop... OS timer resolution is 1 usecs, 1405M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 myus = 9998 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "s5500z" DMI string system-version: " " DMI string baseboard-manufacturer: "PEGATRON CORPORATION" DMI string baseboard-product-name: "2A99" DMI string baseboard-version: "6.01" DMI string chassis-type: "Desktop" Found chipset "NVIDIA MCP61" with PCI ID 10de:03e0. Enabling flash write... This chipset is not really supported yet. Guesswork... ISA/LPC bridge reg 0x8a contents: 0x40, bit 6 is 1, bit 5 is 0 Flash bus type is SPI SPI on this chipset is WIP. Please report any success or failure by mailing us the verbose output to flashrom(a)flashrom.org, thanks! Found SMBus device 10de:03eb at 00:01:1 MCP SPI BAR is at 0xfec80000 Mapping NVIDIA MCP6x SPI at 0x00000000fec80000, unaligned size 0x544. SPI control is 0x0002, req=0, gnt=0 Please send the output of "flashrom -V" to flashrom(a)flashrom.org with your board name: flashrom -V as the subject to help us finish support for your chipset. Thanks. OK. The following protocols are supported: SPI. Probing for Winbond W25Q80.V, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4014 Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) at physical address 0xfff00000. Chip status register is 0x00. This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). No operations were specified. -- I'm jmon...live in Austin, TX.

1 0

Re: [flashrom] [PATCH 3/4] util: add script for converting legacy layout files to format 2.
by Carl-Daniel Hailfinger 15 Sep '13

15 Sep '13

Am 12.09.2013 22:40 schrieb Stefan Tauner: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Is this patch (3/4) targeting the layout files used by flashrom after 4/4 in this series is in? If yes, we should switch order between 3/4 and 4/4. Review follows later. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Re: [flashrom] [PATCH 2/2] sbxxx: Set SPI clock to 16.5 MHz and disable fast reads.
by Carl-Daniel Hailfinger 15 Sep '13

15 Sep '13

Am 12.09.2013 17:18 schrieb Stefan Tauner: > Do not rely on broken firmware to set up the SPI configuration correctly. > Some boards fail with flashrom because the firmware chose too high speeds > for the alternate SPI mode which flashrom uses. Temporarily change the > clock to the lowest common value of 16.5 MHz. > > Also, disable fast reads just to be safe. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Thanks! One nitpick, otherwise Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > diff --git a/sb600spi.c b/sb600spi.c > index febeabb..91268c0 100644 > --- a/sb600spi.c > +++ b/sb600spi.c > @@ -272,6 +272,62 @@ static int sb600_spi_send_command(struct flashctx *flash, unsigned int writecnt, > return 0; > } > > +struct spispeed { > + const char *const name; > + const int8_t speed; uint8_t instead? That would avoid a type conversion in set_speed(). > +}; > + > +static const struct spispeed spispeeds[] = { > + { "66 MHz", 0x00 }, > + { "33 MHz", 0x01 }, > + { "22 MHz", 0x02 }, > + { "16.5 MHz", 0x03 }, > +}; > + > +static int set_speed(struct pci_dev *dev, const struct spispeed *spispeed) > +{ > + bool success = false; > + uint8_t speed = spispeed->speed; > + > + msg_pdbg("Setting SPI clock to %s (0x%x).\n", spispeed->name, speed); > + if (amd_gen != CHIPSET_YANGTZE) { > + rmmio_writeb((mmio_readb(sb600_spibar + 0xd) & ~(0x3 << 4)) | (speed << 4), sb600_spibar + 0xd); > + success = (speed == ((mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3)); > + } > + > + if (!success) { > + msg_perr("Setting SPI clock failed.\n"); > + return 1; > + } > + return 0; > +} Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

[commit] r1750 - trunk
by repository service 15 Sep '13

15 Sep '13

Author: stefanct Date: Sun Sep 15 16:17:39 2013 New Revision: 1750 URL: http://flashrom.org/trac/flashrom/changeset/1750 Log: sbxxx: Set SPI clock to 16.5 MHz and disable fast reads. Do not rely on broken firmware to set up the SPI configuration correctly. Some boards fail with flashrom because the firmware chose too high speeds for the alternate SPI mode which flashrom uses. Temporarily change the clock to the lowest common value of 16.5 MHz. Also, disable fast reads just to be safe. 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/sb600spi.c Modified: trunk/sb600spi.c ============================================================================== --- trunk/sb600spi.c Sun Sep 15 16:01:06 2013 (r1749) +++ trunk/sb600spi.c Sun Sep 15 16:17:39 2013 (r1750) @@ -272,6 +272,62 @@ return 0; } +struct spispeed { + const char *const name; + const uint8_t speed; +}; + +static const struct spispeed spispeeds[] = { + { "66 MHz", 0x00 }, + { "33 MHz", 0x01 }, + { "22 MHz", 0x02 }, + { "16.5 MHz", 0x03 }, +}; + +static int set_speed(struct pci_dev *dev, const struct spispeed *spispeed) +{ + bool success = false; + uint8_t speed = spispeed->speed; + + msg_pdbg("Setting SPI clock to %s (0x%x).\n", spispeed->name, speed); + if (amd_gen != CHIPSET_YANGTZE) { + rmmio_writeb((mmio_readb(sb600_spibar + 0xd) & ~(0x3 << 4)) | (speed << 4), sb600_spibar + 0xd); + success = (speed == ((mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3)); + } + + if (!success) { + msg_perr("Setting SPI clock failed.\n"); + return 1; + } + return 0; +} + +static int handle_speed(struct pci_dev *dev) +{ + uint32_t tmp; + int8_t spispeed_idx = 3; /* Default to 16.5 MHz */ + + /* See the chipset support matrix for SPI Base_Addr below for an explanation of the symbols used. + * bit 6xx 7xx/SP5100 8xx 9xx hudson1 hudson234 yangtze + * 18 rsvd <- fastReadEnable ? <- ? SpiReadMode[0] + * 29:30 rsvd <- <- ? <- ? SpiReadMode[2:1] + */ + if (amd_gen != CHIPSET_YANGTZE) { + if (amd_gen >= CHIPSET_SB89XX && amd_gen <= CHIPSET_HUDSON234) { + bool fast_read = (mmio_readl(sb600_spibar + 0x00) >> 18) & 0x1; + msg_pdbg("Fast Reads are %sabled\n", fast_read ? "en" : "dis"); + if (fast_read) { + msg_pdbg("Disabling them temporarily.\n"); + rmmio_writel(mmio_readl(sb600_spibar + 0x00) & ~(0x1 << 18), + sb600_spibar + 0x00); + } + } + tmp = (mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3; + msg_pdbg("NormSpeed is %s\n", spispeeds[tmp].name); + } + return set_speed(dev, &spispeeds[spispeed_idx]); +} + static int sb600_handle_imc(struct pci_dev *dev, bool amd_imc_force) { /* Handle IMC everywhere but sb600 which does not have one. */ @@ -322,9 +378,6 @@ uint32_t tmp; uint8_t reg; bool amd_imc_force = false; - static const char *const speed_names[4] = { - "66/reserved", "33", "22", "16.5" - }; char *arg = extract_programmer_param("amd_imc_force"); if (arg && !strcmp(arg, "yes")) { @@ -411,7 +464,7 @@ * See the chipset support matrix for SPI Base_Addr above for an explanation of the symbols used. * bit 6xx 7xx/SP5100 8xx 9xx hudson1 hudson2+ yangtze * 17 rsvd <- <- ? <- ? <- - * 18 rsvd <- fastReadEnable<1> ? <- ? SpiReadMode[0] + * 18 rsvd <- fastReadEnable<1> ? <- ? SpiReadMode[0]<1> * 19 SpiArbEnable <- <- ? <- ? <- * 20 (FifoPtrClr) <- <- ? <- ? <- * 21 (FifoPtrInc) <- <- ? <- ? IllegalAccess @@ -420,8 +473,10 @@ * 24:26 ArbWaitCount <- <- ? <- ? <- * 27 SpiBridgeDisable <- <- ? <- ? rsvd * 28 rsvd DropOneClkOnRd = SPIClkGate ? <- ? <- - * 29:30 rsvd <- <- ? <- ? SpiReadMode[2:1] + * 29:30 rsvd <- <- ? <- ? SpiReadMode[2:1]<1> * 31 rsvd <- SpiBusy ? <- ? <- + * + * <1> see handle_speed */ tmp = mmio_readl(sb600_spibar + 0x00); msg_pdbg("(0x%08" PRIx32 ") SpiArbEnable=%i", tmp, (tmp >> 19) & 0x1); @@ -447,9 +502,6 @@ return ERROR_NONFATAL; } - tmp = (mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3; - msg_pdbg("NormSpeed is %s MHz\n", speed_names[tmp]); - if (amd_gen >= CHIPSET_SB89XX) { tmp = mmio_readb(sb600_spibar + 0x1D); msg_pdbg("Using SPI_CS%d\n", tmp & 0x3); @@ -494,6 +546,9 @@ return 0; } + if (handle_speed(dev) != 0) + return ERROR_FATAL; + if (sb600_handle_imc(dev, amd_imc_force) != 0) return ERROR_FATAL;

1 0

Re: [flashrom] [PATCH 1/4] layout: Add a method to cleanup layout data structures.
by Carl-Daniel Hailfinger 15 Sep '13

15 Sep '13

Am 12.09.2013 22:40 schrieb Stefan Tauner: > Add layout_cleanup() to layout.c and hook it up in cli_classic.c. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Not sure if you want to keep that self-ack, but anyway... Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom