flashrom June 2013

flashrom@flashrom.org

29 participants
125 discussions

[PATCH] Remove exit call from sys_physmap_*
by Niklas Söderlund 13 Sep '13

13 Sep '13

All callers are prepared to handle error if ERROR_PTR is returned. Signed-off-by: Niklas Söderlund <niso(a)kth.se> --- physmap.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/physmap.c b/physmap.c index 5aa9874..adce315 100644 --- a/physmap.c +++ b/physmap.c @@ -173,12 +173,11 @@ static void *sys_physmap_rw_uncached(unsigned long phys_addr, size_t len) /* Open the memory device UNCACHED. Important for MMIO. */ if (-1 == (fd_mem = open(MEM_DEV, O_RDWR | O_SYNC))) { perror("Critical error: open(" MEM_DEV ")"); - exit(2); + return ERROR_PTR; } } - virt_addr = mmap(NULL, len, PROT_WRITE | PROT_READ, MAP_SHARED, - fd_mem, (off_t)phys_addr); + virt_addr = mmap(NULL, len, PROT_WRITE | PROT_READ, MAP_SHARED, fd_mem, (off_t)phys_addr); return MAP_FAILED == virt_addr ? ERROR_PTR : virt_addr; } @@ -192,14 +191,12 @@ static void *sys_physmap_ro_cached(unsigned long phys_addr, size_t len) if (-1 == fd_mem_cached) { /* Open the memory device CACHED. */ if (-1 == (fd_mem_cached = open(MEM_DEV, O_RDWR))) { - msg_perr("Critical error: open(" MEM_DEV "): %s", - strerror(errno)); - exit(2); + msg_perr("Critical error: open(" MEM_DEV "): %s", strerror(errno)); + return ERROR_PTR; } } - virt_addr = mmap(NULL, len, PROT_READ, MAP_SHARED, - fd_mem_cached, (off_t)phys_addr); + virt_addr = mmap(NULL, len, PROT_READ, MAP_SHARED, fd_mem_cached, (off_t)phys_addr); return MAP_FAILED == virt_addr ? ERROR_PTR : virt_addr; } @@ -209,7 +206,7 @@ void physunmap(void *virt_addr, size_t len) msg_pspew("Not unmapping zero size at %p\n", virt_addr); return; } - + munmap(virt_addr, len); } #endif -- 1.7.12.3

2 1

[PATCH 1/5] rayer_spi: Create list of programmer types
by Kyösti Mälkki 28 Aug '13

28 Aug '13

Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> --- rayer_spi.c | 106 ++++++++++++++++++++++++++++++++++-------------------------- 1 file changed, 61 insertions(+), 45 deletions(-) diff --git a/rayer_spi.c b/rayer_spi.c index b312610..b4ef205 100644 --- a/rayer_spi.c +++ b/rayer_spi.c @@ -37,21 +37,48 @@ #include "programmer.h" #include "hwaccess.h" -enum rayer_type { - TYPE_RAYER, - TYPE_XILINX_DLC5, -}; - /* We have two sets of pins, out and in. The numbers for both sets are * independent and are bitshift values, not real pin numbers. * Default settings are for the RayeR hardware. */ -/* Pins for master->slave direction */ -static int rayer_cs_bit = 5; -static int rayer_sck_bit = 6; -static int rayer_mosi_bit = 7; -/* Pins for slave->master direction */ -static int rayer_miso_bit = 6; + +struct rayer_programmer { + const char * type; + const enum test_state status; + const char * description; + const void * private; +}; + +struct rayer_pinout { + int cs_bit; + int sck_bit; + int mosi_bit; + int miso_bit; + void (*preinit)(void *); + int (*shutdown)(void *); +}; + +static struct rayer_pinout rayer_spipgm = { + .cs_bit = 5, + .sck_bit = 6, + .mosi_bit = 7, + .miso_bit = 6, +}; + +static struct rayer_pinout xilinx_dlc5 = { + .cs_bit = 2, + .sck_bit = 1, + .mosi_bit = 0, + .miso_bit = 4, +}; + +struct rayer_programmer rayer_spi_types[] = { + {"rayer", NT, "RayeR SPIPGM", &rayer_spipgm}, + {"xilinx", NT, "Xilinx Parallel Cable III (DLC 5)", &xilinx_dlc5}, + {0}, +}; + +struct rayer_pinout *pinout = NULL; static uint16_t lpt_iobase; @@ -60,22 +87,22 @@ static uint8_t lpt_outbyte; static void rayer_bitbang_set_cs(int val) { - lpt_outbyte &= ~(1 << rayer_cs_bit); - lpt_outbyte |= (val << rayer_cs_bit); + lpt_outbyte &= ~(1 << pinout->cs_bit); + lpt_outbyte |= (val << pinout->cs_bit); OUTB(lpt_outbyte, lpt_iobase); } static void rayer_bitbang_set_sck(int val) { - lpt_outbyte &= ~(1 << rayer_sck_bit); - lpt_outbyte |= (val << rayer_sck_bit); + lpt_outbyte &= ~(1 << pinout->sck_bit); + lpt_outbyte |= (val << pinout->sck_bit); OUTB(lpt_outbyte, lpt_iobase); } static void rayer_bitbang_set_mosi(int val) { - lpt_outbyte &= ~(1 << rayer_mosi_bit); - lpt_outbyte |= (val << rayer_mosi_bit); + lpt_outbyte &= ~(1 << pinout->mosi_bit); + lpt_outbyte |= (val << pinout->mosi_bit); OUTB(lpt_outbyte, lpt_iobase); } @@ -83,8 +110,8 @@ static int rayer_bitbang_get_miso(void) { uint8_t tmp; - tmp = INB(lpt_iobase + 1); - tmp = (tmp >> rayer_miso_bit) & 0x1; + tmp = INB(lpt_iobase + 1) ^ 0x80; // bit.7 inverted + tmp = (tmp >> pinout->miso_bit) & 0x1; return tmp; } @@ -99,8 +126,8 @@ static const struct bitbang_spi_master bitbang_spi_master_rayer = { int rayer_spi_init(void) { + struct rayer_programmer *prog = rayer_spi_types; char *arg = NULL; - enum rayer_type rayer_type = TYPE_RAYER; /* Non-default port requested? */ arg = extract_programmer_param("iobase"); @@ -138,36 +165,20 @@ int rayer_spi_init(void) arg = extract_programmer_param("type"); if (arg) { - if (!strcasecmp(arg, "rayer")) { - rayer_type = TYPE_RAYER; - } else if (!strcasecmp(arg, "xilinx")) { - rayer_type = TYPE_XILINX_DLC5; - } else { + for (; prog->type; ++prog) { + if (! strcasecmp (arg, prog->type)) { + break; + } + } + if(! prog->type) { msg_perr("Error: Invalid device type specified.\n"); free(arg); return 1; } + free(arg); } - free(arg); - switch (rayer_type) { - case TYPE_RAYER: - msg_pdbg("Using RayeR SPIPGM pinout.\n"); - /* Bits for master->slave direction */ - rayer_cs_bit = 5; - rayer_sck_bit = 6; - rayer_mosi_bit = 7; - /* Bits for slave->master direction */ - rayer_miso_bit = 6; - break; - case TYPE_XILINX_DLC5: - msg_pdbg("Using Xilinx Parallel Cable III (DLC 5) pinout.\n"); - /* Bits for master->slave direction */ - rayer_cs_bit = 2; - rayer_sck_bit = 1; - rayer_mosi_bit = 0; - /* Bits for slave->master direction */ - rayer_miso_bit = 4; - } + msg_pinfo("Using %s pinout.\n", prog->description); + pinout = (struct rayer_pinout *) prog->private; if (rget_io_perms()) return 1; @@ -175,6 +186,11 @@ int rayer_spi_init(void) /* Get the initial value before writing to any line. */ lpt_outbyte = INB(lpt_iobase); + if (pinout->shutdown) + register_shutdown(pinout->shutdown, (void*)pinout); + if (pinout->preinit) + pinout->preinit(pinout); + if (bitbang_spi_init(&bitbang_spi_master_rayer)) return 1; -- 1.8.1.1

4 11

Re: [flashrom] MX25U1635E (on OLPC XO-4 B1) with flashrom r1657
by Stefan Tauner 25 Aug '13

25 Aug '13

On Tue, 19 Mar 2013 16:12:43 +1100 James Cameron <quozl(a)laptop.org> wrote: > G'day, > > I'm an Open Firmware developer working for One Laptop per Child. > > We have used the MX25U3235E chip in revision B1 of our XO-4 design, > and I am trying to use flashrom (r1657) with a Bus Pirate to read from > a chip. > > I see you pushed a patch for this chip in the past few days. A happy > coincidence perhaps. > > Is there anything I can do to help you change TEST_UNTESTED to > something else? > > (Sorry if this is an obvious question, but I have very little > knowledge of flashrom, having used for the first time yesterday with a > different chip. Mostly we program the chip from within Open > Firmware.) > > I changed TEST_UNTESTED to TEST_OK_PR on my system, and captured the > attached logs. > > While the identify worked, the read gave errors, and the output file > contained 0xff only. We have never intentionally enabled any block > protection on this chip. > Hello James, the .tested field is only used for QA and telling the user about it. Changing it does not influence functionality. If you are in a hurry skip this paragraph. :) I am a bit puzzled at the moment regarding the (read) log. If you look at the detailed output of the contents of the status register at line 132 ff. you see that flashrom (mistakenly) reads 0xFF, which leads to the assumption that a block protection is enabled (see bottom of page 26 in the datasheet of the chip; that's quite a standard layout of a SPI flash status register...). It then tries to disable the "protection" and fails because another bit in the status register - the WIP bit - remains at 1. I have no idea why it (always) reads 0xFF from the status register... I have checked the opcode and it is correct, and there is nothing fancy about... apart from one thing I just noticed which you could test: in spi_read_status_register() in spi25_statusreg.c replace 2 with 1 in the array declaration readarr[2] so that this line becomes unsigned char readarr[1]; /* JEDEC_RDSR_INSIZE=1 but wbsio needs 2 */ wbsio is our driver for a very annoying winbond SPI master and as the fixme in the function says, this hack should not be in the generic code. If the macronix chip does not repeat the status register contents when one reads more than one byte after sending the RDSR (read status register) opcode (which chips usually do) but 0xFF then we have found the culprit. PS: please send further mails to flashrom(a)flashrom.org - our mailing list, thanks. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

[PATCH] Add git support to the Makefile
by Carl-Daniel Hailfinger 21 Aug '13

21 Aug '13

flashrom relies on svn to export tarballs and only prints the last svn revision in the version message even if flashrom is in a git tree. Print extended version information (version, svn revision, git hash, repository URL). Allow exporting from git trees. This should make git users first-class citizens like svn users. Side note: If anyone has an idea how to make the export target more beautiful (80 column limit etc.), please tell me. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-gitfriendly/Makefile =================================================================== --- flashrom-gitfriendly/Makefile (Revision 1145) +++ flashrom-gitfriendly/Makefile (Arbeitskopie) @@ -97,13 +97,15 @@ # of the checked out flashrom files. # Note to packagers: Any tree exported with "make export" or "make tarball" # will not require subversion. The downloadable snapshots are already exported. -SVNVERSION := $(shell LC_ALL=C svnversion -cn . 2>/dev/null | sed -e "s/.*://" -e "s/$[0-9]*$.*/\1/" | grep "[0-9]" || LC_ALL=C svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || LC_ALL=C git svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || echo unknown) +SCMVERSION := $(shell LC_ALL=C svnversion -cn . 2>/dev/null | sed -e "s/.*://" -e "s/$[0-9]*$.*/\1/" | grep "[0-9]" || LC_ALL=C svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || LC_ALL=C git svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || echo unknown) +SCMEXTVERSION := $(shell LC_ALL=C git rev-parse HEAD 2>/dev/null | sed 's/^./-\0/') +SCMURL := $(shell LC_ALL=C svn info 2>/dev/null | grep URL: | sed 's/.*URL:[[:blank:]]*//' | grep ^. || LC_ALL=C git remote show origin 2>/dev/null |grep URL: | sed 's/.*URL:[[:blank:]]*//' | grep ^. || echo unknown ) RELEASE := 0.9.2 -VERSION := $(RELEASE)-r$(SVNVERSION) +VERSION := $(RELEASE)-r$(SCMVERSION)$(SCMEXTVERSION) RELEASENAME ?= $(VERSION) -SVNDEF := -D'FLASHROM_VERSION="$(VERSION)"' +SCMDEF := -D'FLASHROM_VERSION="$(VERSION)"' -D'FLASHROM_SCMURL="$(SCMURL)"' # Always enable internal/onboard support for now. CONFIG_INTERNAL ?= yes @@ -310,7 +312,7 @@ TAROPTIONS = $(shell LC_ALL=C tar --version|grep -q GNU && echo "--owner=root --group=root") %.o: %.c .features - $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< + $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SCMDEF) -o $@ -c $< # Make sure to add all names of generated binaries here. # This includes all frontends and libflashrom. @@ -420,9 +422,12 @@ export: @rm -rf $(EXPORTDIR)/flashrom-$(RELEASENAME) - @svn export -r BASE . $(EXPORTDIR)/flashrom-$(RELEASENAME) - @sed "s/^SVNVERSION.*/SVNVERSION := $(SVNVERSION)/" Makefile >$(EXPORTDIR)/flashrom-$(RELEASENAME)/Makefile - @LC_ALL=C svn log >$(EXPORTDIR)/flashrom-$(RELEASENAME)/ChangeLog + @svn export -r BASE . $(EXPORTDIR)/flashrom-$(RELEASENAME) 2>/dev/null || git checkout-index -a -f --prefix=$(EXPORTDIR)/flashrom-$(RELEASENAME)/ + @# If SCMVERSION or SCMEXTVERSION contain a slash or SCMURL contains a hash, this will explode + @sed "s/^SCMVERSION.*/SCMVERSION := $(SCMVERSION)/;s/^SCMEXTVERSION.*/SCMEXTVERSION := $(SCMEXTVERSION)/;s#^SCMURL.*#SCMURL := $(SCMURL)#" Makefile >$(EXPORTDIR)/flashrom-$(RELEASENAME)/Makefile + @# ChangeLog should be in English, but we want UTF-8 for names. + @( LC_ALL=en_US.UTF-8 svn log 2>/dev/null || LC_ALL=en_US.UTF-8 git log 2>/dev/null || echo "Unable to extract log from SCM" ) >$(EXPORTDIR)/flashrom-$(RELEASENAME)/ChangeLog + @rm -f $(EXPORTDIR)/flashrom-$(RELEASENAME)/.gitignore $(EXPORTDIR)/flashrom-$(RELEASENAME)/.gitattributes $(EXPORTDIR)/flashrom-$(RELEASENAME)/.gitmodules @echo Exported $(EXPORTDIR)/flashrom-$(RELEASENAME)/ tarball: export Index: flashrom-gitfriendly/flashrom.c =================================================================== --- flashrom-gitfriendly/flashrom.c (Revision 1145) +++ flashrom-gitfriendly/flashrom.c (Arbeitskopie) @@ -1355,6 +1355,7 @@ void print_version(void) { msg_ginfo("flashrom v%s", flashrom_version); + msg_ginfo(" from " FLASHROM_SCMURL ","); print_sysinfo(); } @@ -1362,7 +1363,6 @@ { msg_ginfo("flashrom is free software, get the source code at " "http://www.flashrom.org\n"); - msg_ginfo("\n"); } int selfcheck(void) -- http://www.hailfinger.org/

5 11

Re: [flashrom] [coreboot] Dualbios on GA-MA770-UD3
by Carl-Daniel Hailfinger 10 Aug '13

10 Aug '13

Hi Vadim, thanks for your mail. I have added the flashrom mailing list in CC: because we should develop a generic way to handle DualBIOS and similar techniques. On 09.04.2010 08:12, Vadim Girlin wrote: > I'm going to try coreboot on Gigabyte GA-MA770-UD3. > It's AMD 770 (RX780 / SB700). > > My motherboard supports hardware dual bios - with two chips on it. > I'm going to try flashing backup chip and boot from it. It seems to be > possible - I've tested it (flashing at least). Chips on this board could > be switched by changing bit 0 at undocumented register EF on LDN 7 of > IT8720. I can use slightly patched flashrom for accessing any chip I > want without any problems. And this is tested many times. > > My idea is to use backup chip for debugging - that always keeps my > chance to reboot from main bios chip. And removes the need for > desoldering etc. > > And second problem is that original bios is checking second chip - and > trying to recover it by flashing the bios from main chip on reboot? > rewriting coreboot. AFAICS this could be solved by including some > signatures etc. It seems to be easy to find out. May be someone is > working on this? > > BTW I can send the patch for flashrom - but I think that with > information I mentioned above somebody could make it much better than my > ugly hack. I hope the regs should be the same for all latest Gigabyte > MBs using IT8720/18 > It would be great if you could send that patch. It will help us make a flashrom design decision that works for all boards with multiple flash chips. By the way, some of us have good contacts at ITE, so we can ask ITE for details about the undocumented registers. Regards, Carl-Daniel -- http://www.hailfinger.org/

5 12

Re: [flashrom] Invalid OPCODE 0x9f
by Stefan Tauner 07 Aug '13

07 Aug '13

The restricted opcode is not so unusual. We have encountered the same with some thinkpads. Vendors don't need proper RDID because they usually know which chip is installed so they don't have to support 300+ chips like flashrom does. On Mon, 29 Apr 2013 14:47:35 +0400 Vasiliy Vylegzhanin <6vasia(a)gmail.com> wrote: > 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. > 0x58: 0x07ff0580 FREG1: BIOS region (0x00580000-0x007fffff) is read-write. > 0x5C: 0x057f0003 FREG2: Management Engine region (0x00003000-0x0057ffff) is read-write. > 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. > 0x64: 0x00000fff FREG4: Platform Data region is unused. > 0x74: 0x00000000 (PR0 is unused) > 0x78: 0x00000000 (PR1 is unused) > 0x7C: 0x00000000 (PR2 is unused) > 0x80: 0x87ff0770 PR3: WARNING: 0x00770000-0x007fffff is read-only. > 0x84: 0x875f0580 PR4: WARNING: 0x00580000-0x0075ffff is read-only. The protected regions are a bigger problem. This configuration protects almost the complete BIOS region and this can not be disabled at runtime. Does the vendor offer updates for the BIOS? Did you look into the BIOS configuration menu if there is a switch to allow BIOS modifications? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[RFC] Layout handling...
by Carl-Daniel Hailfinger 12 Jul '13

12 Jul '13

Hi, before we change flashrom to work with current layout requirements, we should summarize the features we need/want, and then decide how to handle the individual layout regions internally. Terms: "write strategy" describes a combination of erase+write commands with a given block size, touching some blocks. "read protected" describes a region which can not be read. "write protected" describes a region which can not be written. "write once" describes a region which can be written exactly once in the chip lifetime. If you add a feature to the list, please give it a nickname so we know which feature people are referring to. Some of the features below might not be desirable, but I want to list them anyway so we can explicitly declare them as unsupported if needed. fullwrite-unrestricted: Write a chip-sized image, no special read/write restrictions of the chip, no layout file needs to be specified. Default write case right now. fullwrite-noread: Write a chip-sized image, reading anything from the chip is not possible. Many DVD writers fall in that category. No verification, violates our reliability guarantees. fullwrite-postread: Write a chip-sized image, reading anything from the chip is only possible after write. Chips which are read-locked until a full erase/write fall in that category. Do those exist as standalone flash chips or only integrated into processors? fullwrite-partialread: Write a chip-sized image, reading is only possible in some chip regions. Only partial verification, violates our reliability guarantees. fullwrite-partialwrite: Write a chip-sized image, but writing is only possible in some regions. This is obviously a conflict unless the image has the same contents as the chip in the write-protected regions and there is a possible write strategy for the whole image which does not touch the write-protected regions. Should flashrom always refuse this scenario, or only refuse it in case of conflicts? partialwrite-unrestricted: Write only parts of an image, the rest of the chip contents is kept, no special read/write restrictions. partialwrite-partialread: Write only parts of an image, the rest of the chip contents is kept, reading is only possible in some chip regions. If no read-protected regions are written and a suitable write strategy exists, should flashrom warn? If a read-protected region is written, should flashrom warn/refuse due to reliability requirements? partialwrite-partialwrite: Write only parts of an image, the rest of the chip contents is kept, writing is only possible in some chip regions. If no write-protected regions are written and a suitable write strategy exists, should flashrom warn? flashrom will refuse to write a write-protected region. fullread-unrestricted: Read the full chip, no special read restrictions of the chip. partialread-unrestricted: Read only parts of a chip, no special read restrictions of the chip. partialread-partialread: Read only parts of a chip, some regions are read-protected. flashrom should refuse to read any read-protected regions. partialread-imagefiller: If only parts of a chip are read and the read image has full chip size, what should be used as filler for unread regions? 0x00 or 0xff? partialread-layout-imagesize: If only parts of a chip are read, should the read image still have full chip size with all read regions filled in at the respective locations? partialread-layout-split: If only parts of a chip are read, should it be possible to write each region (or a combination thereof) to a separate image file, and would that mapping be specified in the layout file? partialwrite-layout-split: If only parts of a chip are written, should it be possible to collect each part of the new image from a separate image file, and would that mapping be specified in the layout file? readwrite-protection-time: Which read protection and write protection times exist? Temporary lock until unlock, temporary lock until chip soft reset, temporary lock until chip/programmer hard reset (powerdown or reset line), permanent eternal lock. readwrite-protection-type: Which read protection and write protection types exist? Programmer lock (e.g. Intel SPI), hardware chip lock (WP pin), software chip lock (chip command). readwrite-protection-interaction: How should we express this situation: A region is write-locked with a software chip lock, but to remove that software chip lock, a hardware chip lock has to be disabled first, then the software chip lock can be disabled. partialaccess-crash: Some regions in the chip are really off-limits and will cause an unrecoverable error (system crash) when accessed (read or write). That seems to be the case for some EC/flash interactions. Comments? Any forks of flashrom (e.g. chromium) which need infrastructure features not mentioned above? Regards, Carl-Daniel -- http://www.hailfinger.org/

5 12

Re: [flashrom] [PATCH] Add support for Nantronics N25 series.
by Carl-Daniel Hailfinger 06 Jul '13

06 Jul '13

Am 04.05.2013 03:46 schrieb Stefan Tauner: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> With the corrections mentioned on IRC (erase commands, wrong unlock function), this is Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> The timeout handling needs to be done in another patch. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

Re: [flashrom] Asrock E350M1 - flashrom erase failed
by Reiner Luett 06 Jul '13

06 Jul '13

Hello, I've pasted the output to: http://paste.flashrom.org/view.php?id=1675 I tried a reboot after I've change the image and sometimes it worked as before, but in a few cases it fails. This also could be due to a faulty flashrom image. Regards, Reiner -- On 30.06.2013 18:12, Steven Zakulec wrote: > You'll need to provide more information than that- preferably logs. Add > -o e350m1.log to your command, and paste the result on > paste.flashrom.org <http://paste.flashrom.org>. > Also, how do you know flashing seemed to work? > > > > On Sun, Jun 30, 2013 at 10:41 AM, Reiner Luett <diffusae(a)yahoo.se > <mailto:diffusae@yahoo.se>> wrote: > > Hi, > > does anybody have a working flashrom version or could supply patches. > I always get the Erase failed message, but flashing seems to work. > > Best regards, > Reiner > > -- > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> > http://www.flashrom.org/mailman/listinfo/flashrom > > > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

3 10

Enabling Dediprog by default in flashrom
by Stefan Tauner 01 Jul '13

01 Jul '13

Hi, the release of flashrom 0.9.7 is imminent and I would really like to enable the Dediprog programmer by default. Carl-Daniel informed me that the only problem is that we do not know which opcode is actually used for reading on the SPI bus. It could be that we initiate a fast read (0x0b) instead of a normal read (0x03). This would work with the majority of flash chips but would not with others where flashrom should normally work. Since we are not sure we don't want to enable it without further consideration/testing/warning messages. Furthermore not all chips supporting fast read have this fact noted in their datashets. So testing any apparently non-fast read chip does not suffice. We would rather be able to check the opcode on the SPI bus with a logic analyzer directly. Are there any Dediprog users who can help us with that please? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom June 2013