flashrom

flashrom@flashrom.org

5 participants
9186 discussions

ASUS P5N-D
by Guillaume Poirier-Morency 18 Aug '11

18 Aug '11

I've been told, after an unsuccessful flashing, to send you these outputs about my motherboard. My board remained intact! If you are interested into enabling it and developing patches to make it compatible, I do not mind giving you feedback. Regards, Arteymis

1 0

Zotac GeForce 8200: flashrom -V
by LukenShiro 18 Aug '11

18 Aug '11

I've used successfully flashrom 0.9.4 with my mainboard, reading (with -r) and writing (with -w) Zotac stock BIOS (updating it to last available version). No special flag were needed. # ./flashrom -V (results are attached) Best regards. -- GNU/Linux * Slackware64 current LU #210970 SU #12583 LM #98222/#412913

2 2

Re: [flashrom] flashrom post from info@mingtaofurniture.com requires approval
by Stefan Tauner 18 Aug '11

18 Aug '11

On Thu, 18 Aug 2011 06:53:29 +0200 flashrom-owner(a)flashrom.org wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: flashrom(a)flashrom.org > From: info(a)mingtaofurniture.com > Subject: 3819289?$?$?$?$?$?$?$?uhmms > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > http://www.flashrom.org/mailman/admindb/flashrom > > to approve or deny the request. let's hope mailman does the right thing. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH 1/3] layout: change return type and name of find_next_included_romentry
by Stefan Tauner 18 Aug '11

18 Aug '11

On Mon, 15 Aug 2011 06:43:36 +0200 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote: > -typedef struct { > +static struct rom_entry { > unsigned int start; > unsigned int end; > unsigned int included; > char name[256]; > -} romlayout_t; > - > -static romlayout_t rom_entries[MAX_ROMLAYOUT]; > +} rom_entries[MAX_ROMLAYOUT]; this was a big mistake. this type is very useful - not necessarily in this setup, but in general we want a rom_entry type to pass around functions that operate on parts of the flash only (i am working on making reads obey layouts atm). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH] Makefile: fix and simplify test program compilations
by Carl-Daniel Hailfinger 17 Aug '11

17 Aug '11

Am 12.08.2011 21:38 schrieb Stefan Tauner: > this was totally broken due to the time behavior of make's shell > function's temporal behavior. > quote from the gnu make documentation > http://www.gnu.org/s/hello/manual/make/Shell-Function.html): > "The commands run by calls to the shell function are run when the > function calls are expanded" > we have used the shell function to echo the test programs to a file. > the file name used was equal for all tests and was overwritten for > each test. the result was that all tests (in a single target?) used > the last test program because the echoing of the test programs was > done before all test compilations(!) > Thanks for opening that bug report. Apparently the gnu make documentation was incorrect. > also the branching for testing ifeq ($(CONFIG_FT2232_SPI), yes) was > unnecessary. > Branching never worked for me inside a target, but I also never tried it your way. > in my approach here i am using verbatim variables (allows to define > even complex test programs in the makefile without jumping through > hoops) that get exported to environment variables (via "export", > reference afterwards with "$$<varname>"). > > i have also added the missing redirection of stderr to the compiler test. > Good. > alternatively one could just use different file names of course, but > i think my approach is superior due to the separation and > readability of the tested code and the fact that the temporal > behavior is MUCH clearer now (else this bug would have not crept in > in the first place :P) > > if line count is an issue one could of course compress the test > programs to something unreadable again :) > Haha. > side note: we use $(CC) all over the place before we even check if > it is there. e.g.: > override ARCH = $(strip $(shell LC_ALL=C $(CC) -E arch.h|grep -v '^\#')) > > this creates unwanted output like: > make -j1 CC=eiugthes > /bin/sh: eiugthes: not found > /bin/sh: eiugthes: not found > /bin/sh: eiugthes: not found > /bin/sh: eiugthes: not found > Checking for a C compiler... not found. > Hm yes. > make: *** [compiler] Error 1 > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > Makefile | 91 ++++++++++++++++++++++++++++++++++++++++---------------------- > 1 files changed, 59 insertions(+), 32 deletions(-) > > diff --git a/Makefile b/Makefile > index c72d10a..672a0df 100644 > --- a/Makefile > +++ b/Makefile > @@ -531,11 +531,62 @@ distclean: clean > strip: $(PROGRAM)$(EXEC_SUFFIX) > $(STRIP) $(STRIP_ARGS) $(PROGRAM)$(EXEC_SUFFIX) > > +# below are the definitions of test programs as verbatim variables, which get > +# exported to environment variables and are referenced with $$<varname> later > +define COMPILER_TEST > +int main(int argc, char **argv) > +{ > + (void) argafc; > Typo? > +define UTSNAME_TEST > +#include <sys/utsname.h> > +struct utsname osinfo; > +int main(int argc, char **argv) > +{ > + (void) argc; > + (void) argv; > + uname (&osinfo); > + return 0; > +} > +endef > +export UTSNAME_TEST > Hm... the alternative would be to have each of those C programs in a separate file in a config/ directory or somesuch. I don't have a strong preference either way. Given that you think verbatim variables are superior, please move them directly above the targets which use them. > + > compiler: featuresavailable > @printf "Checking for a C compiler... " > - @$(shell ( echo "int main(int argc, char **argv)"; \ > - echo "{ (void) argc; (void) argv; return 0; }"; ) > .test.c ) > - @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .test.c -o .test$(EXEC_SUFFIX) >/dev/null && \ > + @echo "$$COMPILER_TEST" > .test.c > + @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .test.c -o .test$(EXEC_SUFFIX) >/dev/null 2>&1 && \ > echo "found." || ( echo "not found."; \ > rm -f .test.c .test$(EXEC_SUFFIX); exit 1) > @rm -f .test.c .test$(EXEC_SUFFIX) > @@ -548,12 +599,7 @@ compiler: featuresavailable > ifeq ($(CHECK_LIBPCI), yes) > pciutils: compiler > @printf "Checking for libpci headers... " > - @# Avoid a failing test due to libpci header symbol shadowing breakage > - @$(shell ( echo "#define index shadow_workaround_index"; \ > - echo "#include <pci/pci.h>"; \ > - echo "struct pci_access *pacc;"; \ > - echo "int main(int argc, char **argv)"; \ > - echo "{ (void) argc; (void) argv; pacc = pci_alloc(); return 0; }"; ) > .test.c ) > + @echo "$$LIBPCI_TEST" > .test.c > @$(CC) -c $(CPPFLAGS) $(CFLAGS) .test.c -o .test.o >/dev/null 2>&1 && \ > echo "found." || ( echo "not found."; echo; \ > echo "Please install libpci headers (package pciutils-devel)."; \ > @@ -588,41 +634,22 @@ featuresavailable: > @false > endif > > -ifeq ($(CONFIG_FT2232_SPI), yes) > features: compiler > @echo "FEATURES := yes" > .features.tmp > +ifeq ($(CONFIG_FT2232_SPI), yes) > I'm really surprised that ifeq inside a target works. IIRC I tried this some time ago on my older machine and it did not work. However, if this works reliably, the code is indeed a lot more readable. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Even if we ever decide to use another build system, we need this fix now. Regards, Carl-Daniel

2 1

[commit] r1416 - trunk
by repository service 17 Aug '11

17 Aug '11

Author: stefanct Date: Thu Aug 18 04:27:19 2011 New Revision: 1416 URL: http://flashrom.org/trac/flashrom/changeset/1416 Log: Makefile: fix and simplify test program compilations this was totally broken due to the make's shell function's temporal behavior. quote from the gnu make documentation (http://www.gnu.org/s/hello/manual/make/Shell-Function.html): "The commands run by calls to the shell function are run when the function calls are expanded" we have used the shell function to echo the test programs to a file. the file name used was equal for all tests and was overwritten for each test. the result was that all tests (in a single target?) used the last test program because the echoing of the test programs was done before all test compilations(!) see my mail for details: http://lists.gnu.org/archive/html/bug-make/2011-08/msg00010.html also the branching for testing ifeq ($(CONFIG_FT2232_SPI), yes) was unnecessarily complicated. in my approach here i am using verbatim variables (allows to define even complex test programs in the makefile without jumping through hoops) that get exported to environment variables (via "export", reference afterwards with "$$<varname>"). i have also added the missing redirection of stderr to the compiler test and changed the definition of ARCH to use simple expansion (:=). the latter is still wrong, because it uses $(CC) before we check if a compiler is installed... makes the compiler check pretty much useless. The simple expansion just reduces the number of errors printed to 1. 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/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Wed Aug 17 11:50:11 2011 (r1415) +++ trunk/Makefile Thu Aug 18 04:27:19 2011 (r1416) @@ -38,7 +38,7 @@ endif # Determine the destination processor architecture -override ARCH = $(strip $(shell LC_ALL=C $(CC) -E arch.h|grep -v '^\#')) +override ARCH := $(strip $(shell LC_ALL=C $(CC) -E arch.h|grep -v '^\#')) # FIXME We have to differentiate between host and target OS architecture. OS_ARCH ?= $(shell uname) @@ -531,11 +531,23 @@ strip: $(PROGRAM)$(EXEC_SUFFIX) $(STRIP) $(STRIP_ARGS) $(PROGRAM)$(EXEC_SUFFIX) +# to define test programs we use verbatim variables, which get exported +# to environment variables and are referenced with $$<varname> later + +define COMPILER_TEST +int main(int argc, char **argv) +{ + (void) argc; + (void) argv; + return 0; +} +endef +export COMPILER_TEST + compiler: featuresavailable @printf "Checking for a C compiler... " - @$(shell ( echo "int main(int argc, char **argv)"; \ - echo "{ (void) argc; (void) argv; return 0; }"; ) > .test.c ) - @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .test.c -o .test$(EXEC_SUFFIX) >/dev/null && \ + @echo "$$COMPILER_TEST" > .test.c + @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .test.c -o .test$(EXEC_SUFFIX) >/dev/null 2>&1 && \ echo "found." || ( echo "not found."; \ rm -f .test.c .test$(EXEC_SUFFIX); exit 1) @rm -f .test.c .test$(EXEC_SUFFIX) @@ -545,15 +557,25 @@ ( echo "unknown. Aborting."; exit 1) @printf "%s\n" '$(ARCH)' +define LIBPCI_TEST +/* Avoid a failing test due to libpci header symbol shadowing breakage */ +#define index shadow_workaround_index +#include <pci/pci.h> +struct pci_access *pacc; +int main(int argc, char **argv) +{ + (void) argc; + (void) argv; + pacc = pci_alloc(); + return 0; +} +endef +export LIBPCI_TEST + ifeq ($(CHECK_LIBPCI), yes) pciutils: compiler @printf "Checking for libpci headers... " - @# Avoid a failing test due to libpci header symbol shadowing breakage - @$(shell ( echo "#define index shadow_workaround_index"; \ - echo "#include <pci/pci.h>"; \ - echo "struct pci_access *pacc;"; \ - echo "int main(int argc, char **argv)"; \ - echo "{ (void) argc; (void) argv; pacc = pci_alloc(); return 0; }"; ) > .test.c ) + @echo "$$LIBPCI_TEST" > .test.c @$(CC) -c $(CPPFLAGS) $(CFLAGS) .test.c -o .test.o >/dev/null 2>&1 && \ echo "found." || ( echo "not found."; echo; \ echo "Please install libpci headers (package pciutils-devel)."; \ @@ -588,41 +610,47 @@ @false endif -ifeq ($(CONFIG_FT2232_SPI), yes) +define FTDI_TEST +#include <ftdi.h> +struct ftdi_context *ftdic = NULL; +int main(int argc, char **argv) +{ + (void) argc; + (void) argv; + return ftdi_init(ftdic); +} +endef +export FTDI_TEST + +define UTSNAME_TEST +#include <sys/utsname.h> +struct utsname osinfo; +int main(int argc, char **argv) +{ + (void) argc; + (void) argv; + uname (&osinfo); + return 0; +} +endef +export UTSNAME_TEST + features: compiler @echo "FEATURES := yes" > .features.tmp +ifeq ($(CONFIG_FT2232_SPI), yes) @printf "Checking for FTDI support... " - @$(shell ( echo "#include <ftdi.h>"; \ - echo "struct ftdi_context *ftdic = NULL;"; \ - echo "int main(int argc, char **argv)"; \ - echo "{ (void) argc; (void) argv; return ftdi_init(ftdic); }"; ) > .featuretest.c ) + @echo "$$FTDI_TEST" > .featuretest.c @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest$(EXEC_SUFFIX) $(FTDILIBS) $(LIBS) >/dev/null 2>&1 && \ ( echo "found."; echo "FTDISUPPORT := yes" >> .features.tmp ) || \ ( echo "not found."; echo "FTDISUPPORT := no" >> .features.tmp ) +endif @printf "Checking for utsname support... " - @$(shell ( echo "#include <sys/utsname.h>"; \ - echo "struct utsname osinfo;"; \ - echo "int main(int argc, char **argv)"; \ - echo "{ (void) argc; (void) argv; uname (&osinfo); return 0; }"; ) > .featuretest.c ) - @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest$(EXEC_SUFFIX) >/dev/null 2>&1 && \ - ( echo "found."; echo "UTSNAME := yes" >> .features.tmp ) || \ - ( echo "not found."; echo "UTSNAME := no" >> .features.tmp ) - @$(DIFF) -q .features.tmp .features >/dev/null 2>&1 && rm .features.tmp || mv .features.tmp .features - @rm -f .featuretest.c .featuretest$(EXEC_SUFFIX) -else -features: compiler - @echo "FEATURES := yes" > .features.tmp - @printf "Checking for utsname support... " - @$(shell ( echo "#include <sys/utsname.h>"; \ - echo "struct utsname osinfo;"; \ - echo "int main(int argc, char **argv)"; \ - echo "{ (void) argc; (void) argv; uname (&osinfo); return 0; }"; ) > .featuretest.c ) + @echo "$$UTSNAME_TEST" > .featuretest.c @$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest$(EXEC_SUFFIX) >/dev/null 2>&1 && \ ( echo "found."; echo "UTSNAME := yes" >> .features.tmp ) || \ ( echo "not found."; echo "UTSNAME := no" >> .features.tmp ) @$(DIFF) -q .features.tmp .features >/dev/null 2>&1 && rm .features.tmp || mv .features.tmp .features @rm -f .featuretest.c .featuretest$(EXEC_SUFFIX) -endif install: $(PROGRAM)$(EXEC_SUFFIX) mkdir -p $(DESTDIR)$(PREFIX)/sbin

1 0

qflashrom dutch (nl-NL) translation
by Bernd Blaauw 17 Aug '11

17 Aug '11

I'm currently delaying things I should be doing, so in a boring moment decided to translate qflashrom language file. [ https://gitorious.org/qflashrom/qflashrom/blobs/master/locale/qflashrom_de_… ]. (btw lines 169..171 are confusing, mentioning 'read' but german part says 'write') Textfile attached, no idea if FireFox and MetaPad kept it as UTF8. Entirely untested ofcourse due to running Windows and no development platforms whatsoever (besides VMware for emulation/virtualisation). Likely usable as well for [nl-BE] but who can tell.. Consider it my €0,02 to this project :) with best regards, Bernd Blaauw (license stuff: whatever the original had, or public domain, at your convenience, giving up all rights to copyright, do as you please).

2 1

[Patch] Added SST25LF080A Flash Chip
by Zeus Castro 17 Aug '11

17 Aug '11

Added support for SST25LF080A flash chip, based on public datasheet available here: http://www.sst.com/dotAsset/40316.pdf

2 5

[commit] r1415 - trunk
by repository service 17 Aug '11

17 Aug '11

Author: stefanct Date: Wed Aug 17 11:50:11 2011 New Revision: 1415 URL: http://flashrom.org/trac/flashrom/changeset/1415 Log: Add support for the SST25LF080A flash chip Based on the definition of SST25LF040A and the public datasheet available here: http://www.sst.com/dotAsset/40316.pdf Also, move the SST25LF040A up to keep the list ordered alphabetically (while removing the ".RES" suffix). Signed-off-by: Zeus Castro <thezeusjuice(a)gmail.com> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/flashchips.c Modified: trunk/flashchips.c ============================================================================== --- trunk/flashchips.c Tue Aug 16 14:08:22 2011 (r1414) +++ trunk/flashchips.c Wed Aug 17 11:50:11 2011 (r1415) @@ -5547,6 +5547,66 @@ { .vendor = "SST", + .name = "SST25LF040A", + .bustype = BUS_SPI, + .manufacture_id = SST_ID, + .model_id = SST_SST25VF040_REMS, + .total_size = 512, + .page_size = 256, + .tested = TEST_OK_PROBE, + .probe = probe_spi_res2, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 128} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 16} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {512 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, + }, + .unlock = spi_disable_blockprotect, + .write = spi_chip_write_1, /* AAI supported, but opcode is 0xAF */ + .read = spi_chip_read, + .voltage = {3000, 3600}, + }, + + { + .vendor = "SST", + .name = "SST25LF080A", + .bustype = BUS_SPI, + .manufacture_id = SST_ID, + .model_id = SST_SST25VF080_REMS, + .total_size = 1024, + .page_size = 256, + .tested = TEST_UNTESTED, + .probe = probe_spi_res2, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 256} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 32} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, + }, + .unlock = spi_disable_blockprotect, + .write = spi_chip_write_1, /* AAI supported, but opcode is 0xAF */ + .read = spi_chip_read, + .voltage = {3000, 3600}, + }, + + { + .vendor = "SST", .name = "SST25VF010.REMS", .bustype = BUS_SPI, .manufacture_id = SST_ID, @@ -5750,36 +5810,6 @@ }, { - .vendor = "SST", - .name = "SST25LF040A.RES", - .bustype = BUS_SPI, - .manufacture_id = SST_ID, - .model_id = SST_SST25VF040_REMS, - .total_size = 512, - .page_size = 256, - .tested = TEST_OK_PROBE, - .probe = probe_spi_res2, - .probe_timing = TIMING_ZERO, - .block_erasers = - { - { - .eraseblocks = { {4 * 1024, 128} }, - .block_erase = spi_block_erase_20, - }, { - .eraseblocks = { {32 * 1024, 16} }, - .block_erase = spi_block_erase_52, - }, { - .eraseblocks = { {512 * 1024, 1} }, - .block_erase = spi_block_erase_60, - }, - }, - .unlock = spi_disable_blockprotect, - .write = spi_chip_write_1, /* AAI supported, but opcode is 0xAF */ - .read = spi_chip_read, - .voltage = {3000, 3600}, - }, - - { .vendor = "SST", .name = "SST25VF040B.REMS", .bustype = BUS_SPI,

1 0

Re: [flashrom] report for Intel QM67 | Winbond W25Q64
by Stefan Tauner 17 Aug '11

17 Aug '11

On Wed, 17 Aug 2011 09:16:05 +0200 "Frei, Thomas (GE Germany)" <Thomas.Frei(a)ge.com> wrote: > Hi Stefan, > > First of all: thank you for the quick response. > Yes I work on a prototype from GE :-) > > OK - now to your questions: > - the flashchip is connected as follows: SPI_CLK + SPI_MOSI are connected via a FET_busswitch, and SPI_MISI is connected directly to the chipset. > - I can use FPT.EXE from intel, and it successfully reads the content of the flashchip - but only 4MB!!! > - the file, I got from the hardware development, that should be used here, also has 4MB!!!??? moin! very interesting. this endorses my theory somewhat that the chipset prohibits writes outside the address ranges of the regions defined by the FREGs completely. this is rather bad because it does not work well with the current concept of flashrom, which basically is founded on the idea that we can access the whole under normal circumstances - or at least that the programmer (in your case the chipset) does not get in our way by unexpected means. this would be a very good use case for a layout file... if it would work for reading :/ or a parameter that would tell flashrom to not throw away the data read, if there is an error later... which does not exist either. that said, writing could work quite normally with a layout file. you would need to make the image match the size of the chip though, so that flashrom accepts it in the first place. i think cp image.bin test.bin ; cat image.bin >> test.bin would work. even without a layout file this would probably write correctly... but flashrom would scream when accessing the second half of the chip. please see the manpage for details about the layout file option. i will work on this in one way or another, but please don't expect it to be committed or even working soon. i guess that you know helge wagner at GE? he may be able to help you (in hacking something together) too. if you test the method outlined above i would really like to hear if it works. please note though that it may also brick your setup... dont blame me then please :) if you want to help us and have a method to recover bricked boards (i.e. if you have an external programmer that works with your boards), you could also try to play with the FREG1 values in the descriptor with fit.exe (or fitw.exe). that said, i just read an interesting paragraph in the ibex peak SPI programming guide: "Flash Space Allocation FIT/Ftoolc allocates SPI flash space allocation for each region as follows: 1. 2. If after allocation for all regions there is still space left in flash, then the ME region expands to fill the remaining space. 3. If there is leftover space and the ME region is not implemented, then the BIOS region is expands to use the remaining space. 4. If there is leftover space and the BIOS region is not implemented, then the GbE region is expands to contain the remaining space." not sure if that still applies to cougar point, but i would guess so. in this case i am wondering if your hardware engineering team has created the image correctly (or if they have set up the total size incorrectly to 4MB instead of 8). > P.S.: Bist Du etwa ein Student an der TU Wien - sprichst Du also Deutsch? yes i am, but since this is public and some of us do not speak german, we use english exclusively on the mailing list. you can mail me directly though, if it is important. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom