flashrom July 2013

flashrom@flashrom.org

31 participants
142 discussions

[PATCH] Remove exit call from sys_physmap_*

by Niklas Söderlund

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

6 years, 11 months

[PATCH 1/5] rayer_spi: Create list of programmer types

by Kyösti Mälkki

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

6 years, 11 months

Re: [flashrom] MX25U1635E (on OLPC XO-4 B1) with flashrom r1657

by Stefan Tauner

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

6 years, 11 months

[PATCH] Add git support to the Makefile

by Carl-Daniel Hailfinger

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/

6 years, 11 months

Re: [flashrom] [coreboot] Dualbios on GA-MA770-UD3

by Carl-Daniel Hailfinger

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/

7 years

Re: [flashrom] Invalid OPCODE 0x9f

by Stefan Tauner

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

7 years

P4R8L - Asus Pundit R - READ OK (looks like) ERASE FAILED

by Gianluigi Tiesi

I've got a barebone pc from asus: http://www.asus.com/Barebone_PCs/PunditR/ read flash looks ok perhaps dumps are a bit different I've attached both from flashrom, original from asus in roms.tar.xz other files: info.tar.xz => lspci/lsusb/dmesg/dmidecode read.log.xz => flashrom -r write.log.xz => flashrom -w Hope it helps Regards -- Gianluigi Tiesi <sherpya(a)netfarm.it> EDP Project Leade Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/ Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? A non-text attachment roms.tar.xz has been stripped. It is available at http://paste.flashrom.org/view.php?id=1709

7 years

Re: [flashrom] A quick hack to support AMD Family 16h SOC

by Carl-Daniel Hailfinger

Am 30.07.2013 23:22 schrieb Wei Hu: > On Tue, Jul 30, 2013 at 1:59 PM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >> This patch should work at normal speed and use the correct FIFO pointer >> registers on Kabini. >> The code is not exactly pretty, but functional and should (in theory) >> need no functional changes before commit. >> >> Please check if read/write works at the expected speed. -VV is >> sufficient this time. > > Reading the 4MB flash took 18 seconds, whereas writing took almost 3 > minutes. Is it normal? On another system with Intel PCH writes were > way faster. There's another FIFO register at offset 0x80 in the new > Kabini interface, which can hopefully speed up things, but the > description is quite dense. > > I'm attaching two -VV logs, one from reading and the other from writing. Thanks! This means my code works well. The following timings are straight from the W25Q32BV datasheet. They may be completely unrealistic. Typical erase time for that chip is around 30 seconds for a sectorwise chip erase (without overhead). The typical write time for that chip (using 5-byte chunks due to the short FIFO for SB600) would be around 600 seconds. Typical write time for that chip with the long Kabini FIFO would be 45 seconds. Add initial read time, sectorwise chip erase time, erase-verify time (full chip read), write time, write-verify time (full chip read) and the write time suddenly looks pretty reasonable. Most important for me was to get the FIFO pointers right for Kabini. Speed issues can be dealt with after the flashrom 0.9.7 release (right now I'm just trying to fix things). That said, the datasheet is rather unclear about the effect of UseSpi100=1, and I'd like to set it to 0. By the way, the data which enabled me to fix the FIFO stuff for Kabini (because the datasheets have room for improvement) is here: http://paste.flashrom.org/view.php?id=1718 Regards, Carl-Daniel -- http://www.hailfinger.org/

7 years

Re: [flashrom] A quick hack to support AMD Family 16h SOC

by Carl-Daniel Hailfinger

Am 30.07.2013 20:55 schrieb Wei Hu: > Attached is a log from flashrom -VVV -p internal -o /tmp/flashrom.log. > Please let me know what else you want to collect. Thanks! > On Sun, Jul 28, 2013 at 3:38 PM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >> Am 26.07.2013 23:31 schrieb Stefan Tauner: >>> On Fri, 26 Jul 2013 12:28:48 -0700 >>> Wei Hu <wei(a)aristanetworks.com> wrote: >>>> On Fri, Jul 26, 2013 at 12:18 AM, Carl-Daniel Hailfinger >>>> <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >>>>>> I'll give you modified patch a test tomorrow. >>>>> Please note that I expect problems with my patch. Not all of the FIFO >>>>> management has been changed, and this might be the cause of error >>>>> messages. Updated patch with more debugging at the end of this mail. >>>> After changing the device ID to match 0x780e, your patch works for >>>> both reading and writing. Writing is extremely slow though. I feel >>>> like on this new FCH we should ditch the SB600 interface and >>>> investigate the new programming interface. My current patch is more >>>> like a band aid workaround. >>> I plan to do that but for now it would be better than nothing, *but* >>> this will break Hudson-2... I talked to Martin Roth from sage and he >>> confirmed that although AMD changed PCI IDs with Hudson-1 the >>> interface did only really change with Kabini/Temash. >>> >>> That explains also why Hudson-2 worked fine previously: >>> http://marc.info/?l=flashrom&m=131853263731000 >>> Wang Qing Pei has tested his Hudson patch too probably before sending >>> it to us but I don't know which system he used exactly. >>> >>> I'll try to get the Hudson-2 datasheets, but ATM I don't have them. >>> We need a way to distinguish Kabini from the rest... since it is a SoC, >>> we could match the pci ids of the root complex >>> (00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 16h >>> Processor Root Complex [1022:1536] in my case), but we would need to >>> maintain that for future models... Martin told me that they just read >>> if the new registers are (non-)0xff and infer from that if they need to >>> use the new interface. >> New patch. Better heuristic (Martin's variant) for Kabini, more debug >> prints. >> The big challenge is to check whether this breaks Hudson variants before >> Kabini. >> >> Please get some -VVV logs for a simple probe. Thanks! >> # flashrom -o logfile.txt -VVV >> >> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> This patch should work at normal speed and use the correct FIFO pointer registers on Kabini. The code is not exactly pretty, but functional and should (in theory) need no functional changes before commit. Please check if read/write works at the expected speed. -VV is sufficient this time. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-kabini/sb600spi.c =================================================================== --- flashrom-kabini/sb600spi.c (Revision 1704) +++ flashrom-kabini/sb600spi.c (Arbeitskopie) @@ -4,7 +4,7 @@ * Copyright (C) 2008 Wang Qingpei <Qingpei.Wang(a)amd.com> * Copyright (C) 2008 Joe Bao <Zheng.Bao(a)amd.com> * Copyright (C) 2008 Advanced Micro Devices, Inc. - * Copyright (C) 2009, 2010 Carl-Daniel Hailfinger + * Copyright (C) 2009, 2010, 2013 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -45,6 +45,8 @@ static uint8_t *sb600_spibar = NULL; +static int kabini_method = 0; + static void reset_internal_fifo_pointer(void) { mmio_writeb(mmio_readb(sb600_spibar + 2) | 0x10, sb600_spibar + 2); @@ -54,33 +56,67 @@ msg_pspew("reset\n"); } -static int compare_internal_fifo_pointer(uint8_t want) +static int check_internal_fifo_pointer(uint8_t have, uint8_t want) { + if (have != want) { + msg_perr("AMD SPI FIFO pointer corruption! Pointer is %d, wanted %d\n", have, want); + msg_perr("Something else is accessing the flash chip and causes random corruption.\n" + "Please stop all applications and drivers and IPMI which access the flash chip.\n"); + return 1; + } + msg_pspew("AMD SPI FIFO pointer is %d, wanted %d\n", have, want); + return 0; +} + +static int compare_internal_kabini_fifo_write_pointer(uint8_t want) +{ uint8_t tmp; + tmp = mmio_readb(sb600_spibar + 0x4d) & 0x7f; + return check_internal_fifo_pointer(tmp, want); +} + +static int compare_internal_kabini_fifo_read_pointer(uint8_t want) +{ + uint8_t tmp; + + tmp = mmio_readb(sb600_spibar + 0x4e) & 0x7f; + return check_internal_fifo_pointer(tmp, want); +} + +static int compare_internal_sb600_fifo_pointer(uint8_t want) +{ + uint8_t tmp; + tmp = mmio_readb(sb600_spibar + 0xd) & 0x07; want &= 0x7; - if (want != tmp) { - msg_perr("FIFO pointer corruption! Pointer is %d, wanted %d\n", tmp, want); - msg_perr("Something else is accessing the flash chip and " - "causes random corruption.\nPlease stop all " - "applications and drivers and IPMI which access the " - "flash chip.\n"); - return 1; - } else { - msg_pspew("SB600 FIFO pointer is %d, wanted %d\n", tmp, want); - return 0; - } + return check_internal_fifo_pointer(tmp, want); } +#if 0 static int reset_compare_internal_fifo_pointer(uint8_t want) { int ret; +#if 0 + if (kabini_method) { + uint8_t tmp1; + mmio_writeb(7, sb600_spibar + 0x1e); + tmp = mmio_readb(sb600_spibar + 0x1f); + msg_pspew("Kabini SPIDataFifoPtr %d/%d, ", tmp, want); + tmp = mmio_readb(sb600_spibar + 0xd) & 0x07; + msg_pspew("FifoPtr %d/%d, ", tmp, want & 0x07); + tmp = mmio_readb(sb600_spibar + 0x4d) & 0x7f; + tmp1 = mmio_readb(sb600_spibar + 0x4e) & 0x7f; + msg_pspew("FifoWrPtr/FifoRdPtr %d/%d\n", tmp, tmp1); + } +#endif + ret = compare_internal_fifo_pointer(want); reset_internal_fifo_pointer(); return ret; } +#endif static void execute_command(void) { @@ -99,7 +135,7 @@ /* First byte is cmd which can not being sent through FIFO. */ unsigned char cmd = *writearr++; unsigned int readoffby1; - unsigned char readwrite; + unsigned char readwrite = 0; writecnt--; @@ -118,15 +154,21 @@ return SPI_INVALID_LENGTH; } - /* This is a workaround for a bug in SB600 and SB700. If we only send - * an opcode and no additional data/address, the SPI controller will - * read one byte too few from the chip. Basically, the last byte of - * the chip response is discarded and will not end up in the FIFO. - * It is unclear if the CS# line is set high too early as well. - */ - readoffby1 = (writecnt) ? 0 : 1; - readwrite = (readcnt + readoffby1) << 4 | (writecnt); - mmio_writeb(readwrite, sb600_spibar + 1); + if (kabini_method) { + /* Use the extended TxByteCount and RxByteCount register. */ + mmio_writeb(writecnt, sb600_spibar + 0x48); + mmio_writeb(readcnt, sb600_spibar + 0x4b); + } else { + /* This is a workaround for a bug in SB600 and SB700. If we only send + * an opcode and no additional data/address, the SPI controller will + * read one byte too few from the chip. Basically, the last byte of + * the chip response is discarded and will not end up in the FIFO. + * It is unclear if the CS# line is set high too early as well. + */ + readoffby1 = (writecnt) ? 0 : 1; + readwrite = (readcnt + readoffby1) << 4 | (writecnt); + mmio_writeb(readwrite, sb600_spibar + 1); + } mmio_writeb(cmd, sb600_spibar + 0); /* Before we use the FIFO, reset it first. */ @@ -139,16 +181,29 @@ mmio_writeb(*writearr, sb600_spibar + 0xC); } msg_pspew("\n"); + if (kabini_method) { + if (compare_internal_kabini_fifo_write_pointer(writecnt)) + return SPI_PROGRAMMER_ERROR; + } else { + if (compare_internal_sb600_fifo_pointer(writecnt)) + return SPI_PROGRAMMER_ERROR; + } /* * We should send the data by sequence, which means we need to reset * the FIFO pointer to the first byte we want to send. */ - if (reset_compare_internal_fifo_pointer(writecnt)) - return SPI_PROGRAMMER_ERROR; + reset_internal_fifo_pointer(); msg_pspew("Executing: \n"); execute_command(); + if (kabini_method) { + if (compare_internal_kabini_fifo_write_pointer(writecnt + readcnt)) + return SPI_PROGRAMMER_ERROR; + } else { + if (compare_internal_sb600_fifo_pointer(writecnt + readcnt)) + return SPI_PROGRAMMER_ERROR; + } /* * After the command executed, we should find out the index of the @@ -161,8 +216,7 @@ * the opcode, the FIFO already stores the response from the chip. * Usually, the chip will respond with 0x00 or 0xff. */ - if (reset_compare_internal_fifo_pointer(writecnt + readcnt)) - return SPI_PROGRAMMER_ERROR; + reset_internal_fifo_pointer(); /* Skip the bytes we sent. */ msg_pspew("Skipping: "); @@ -171,27 +225,53 @@ msg_pspew("[%02x]", cmd); } msg_pspew("\n"); - if (compare_internal_fifo_pointer(writecnt)) - return SPI_PROGRAMMER_ERROR; + if (kabini_method) { + if (compare_internal_kabini_fifo_read_pointer(writecnt)) + return SPI_PROGRAMMER_ERROR; + } else { + if (compare_internal_sb600_fifo_pointer(writecnt)) + return SPI_PROGRAMMER_ERROR; + } + msg_pspew("Reading: "); for (count = 0; count < readcnt; count++, readarr++) { *readarr = mmio_readb(sb600_spibar + 0xC); msg_pspew("[%02x]", *readarr); } msg_pspew("\n"); - if (reset_compare_internal_fifo_pointer(readcnt + writecnt)) - return SPI_PROGRAMMER_ERROR; - if (mmio_readb(sb600_spibar + 1) != readwrite) { - msg_perr("Unexpected change in SB600 read/write count!\n"); - msg_perr("Something else is accessing the flash chip and " - "causes random corruption.\nPlease stop all " - "applications and drivers and IPMI which access the " - "flash chip.\n"); - return SPI_PROGRAMMER_ERROR; + if (kabini_method) { + if (compare_internal_kabini_fifo_read_pointer(writecnt + readcnt)) + return SPI_PROGRAMMER_ERROR; + } else { + if (compare_internal_sb600_fifo_pointer(writecnt + readcnt)) + return SPI_PROGRAMMER_ERROR; } + reset_internal_fifo_pointer(); + if (kabini_method) { + uint8_t tmp_wc = mmio_readb(sb600_spibar + 0x48); + uint8_t tmp_rc = mmio_readb(sb600_spibar + 0x4b); + if ((tmp_rc != readcnt) || (tmp_wc != writecnt)) { + msg_perr("Unexpected change in Kabini read/write count: %i/%i instead of %i/%i!\n", + tmp_rc, tmp_wc, readcnt, writecnt); + msg_perr("Something else is accessing the flash chip and causes random corruption.\n" + "Please stop all applications and drivers and IPMI which access the flash " + "chip.\n"); + return SPI_PROGRAMMER_ERROR; + } + } else { + uint8_t tmp_rw = mmio_readb(sb600_spibar + 1); + if (tmp_rw != readwrite) { + msg_perr("Unexpected change in SB600 read/write count: %i instead of %i!\n", tmp_rw, + readwrite); + msg_perr("Something else is accessing the flash chip and causes random corruption.\n" + "Please stop all applications and drivers and IPMI which access the flash " + "chip.\n"); + return SPI_PROGRAMMER_ERROR; + } + } return 0; } @@ -245,8 +325,8 @@ uint32_t tmp; uint8_t reg; bool amd_imc_force = false; - static const char *const speed_names[4] = { - "66/reserved", "33", "22", "16.5" + static const char *const speed_names[8] = { + "66 MHz", "33 MHz", "22 MHz", "16.6 MHz", "100 MHz", "Reserved", "Reserved", "800 kHz" }; char *arg = extract_programmer_param("amd_imc_force"); @@ -281,6 +361,30 @@ */ sb600_spibar += tmp & 0xfff; + /* AMD Kabini has a different SPI interface. */ + kabini_method = 0; + if (dev->device_id == 0x780e) { + /* The PCI ID of the LPC bridge doesn't change between Hudson-2 and Kabini (Hudson-3) although + * they use different SPI interfaces. ID 0x780e is common for all Hudson variants. This + * heuristic accesses the SPI interface MMIO BAR at locations beyond those supported by + * Hudson-2 and earlier in the hope of getting 0xff readback on older chipsets and non-0xff + * readback on Kabini and newer chipsets. + */ + int i; + msg_pdbg("Checking for AMD Kabini or later... "); + for (i = 0x20; i <= 0x4f; i++) { + if (mmio_readb(sb600_spibar + i) != 0xff) { + kabini_method = 1; + break; + } + } + if (kabini_method) + msg_pdbg("using AMD Kabini SPI access method.\n"); + else + msg_pdbg("not found.\n"); + } + + /* FIXME: Check all accesses below for Kabini incompatibilities. */ tmp = pci_read_long(dev, 0xa0); msg_pdbg("AltSpiCSEnable=%i, SpiRomEnable=%i, " "AbortEnable=%i\n", tmp & 0x1, (tmp & 0x2) >> 1, @@ -300,15 +404,28 @@ * SB700 or later, reads and writes will be corrupted. Abort in this * case. Make sure to avoid this check on SB600. */ - msg_pdbg("(0x%08" PRIx32 ") fastReadEnable=%u, SpiArbEnable=%i, SpiAccessMacRomEn=%i, " + msg_pdbg("(0x%08" PRIx32 ") SpiReadMode/FastReadEnable=%i, SpiArbEnable=%i, SpiAccessMacRomEn=%i, " "SpiHostAccessRomEn=%i, ArbWaitCount=%i, " - "SpiBridgeDisable=%i, DropOneClkOnRd=%i\n", - tmp, (tmp >> 18) & 0x1, + "SpiBridgeDisable=%i, SpiClkGate/DropOneClkOnRd=%i\n", + tmp, ((tmp >> 28) & 0x6) | ((tmp >> 18) & 0x1), (tmp >> 19) & 0x1, (tmp >> 22) & 0x1, (tmp >> 23) & 0x1, (tmp >> 24) & 0x7, (tmp >> 27) & 0x1, (tmp >> 28) & 0x1); - tmp = (mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3; - msg_pdbg("NormSpeed is %s MHz\n", speed_names[tmp]); + if (kabini_method) { + tmp = mmio_readb(sb600_spibar + 0x20) & 0x1; + msg_pdbg("UseSpi100 is %i (%s)\n", tmp, tmp ? "unsupported" : "OK"); + tmp = mmio_readw(sb600_spibar + 0x22); + msg_pdbg("TpmSpeedNew is %s\n", speed_names[tmp & 0xf]); + tmp >>= 4; + msg_pdbg("AltSpeedNew is %s\n", speed_names[tmp & 0xf]); + tmp >>= 4; + msg_pdbg("FastSpeedNew is %s\n", speed_names[tmp & 0xf]); + tmp >>= 4; + msg_pdbg("NormSpeedNew is %s\n", speed_names[tmp & 0xf]); + } else { + tmp = (mmio_readb(sb600_spibar + 0xd) >> 4) & 0x3; + msg_pdbg("NormSpeed is %s MHz\n", speed_names[tmp]); + } /* Look for the SMBus device. */ smbus_dev = pci_dev_find(0x1002, 0x4385); -- http://www.hailfinger.org/

7 years

MSI H87-G43 flash success :)

by Marek Zakrzewski

flashrom v0.9.6.1-r1564 on Linux 2.6.18-348.12.1.el5 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "Intel Lynx Point". This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... enable_flash_ich_dc_spi: unknown ICH generation. Please report! WARNING: SPI Configuration Lockdown activated. Enabling hardware sequencing because some important opcode is locked. OK. Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) at physical address 0x0. Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. flashrom v0.9.6.1-r1564 on Linux 2.6.18-348.12.1.el5 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.7, GCC 4.1.2 20080704 (Red Hat 4.1.2-54), little endian Command line (2 args): flashrom -V --programmer=internal Calibrating delay loop... OS timer resolution is 1 usecs, 3365M loops per second, 10 myus = 10 us, 100 myus = 106 us, 1000 myus = 1014 us, 10000 myus = 10006 us, 4 myus = 6 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "MSI" DMI string system-product-name: "MS-7816" DMI string system-version: "1.0" DMI string baseboard-manufacturer: "MSI" DMI string baseboard-product-name: "H87-G43 (MS-7816)" DMI string baseboard-version: "1.0" DMI string chassis-type: "Desktop" Found chipset "Intel Lynx Point" with PCI ID 8086:8c4a. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... enable_flash_ich_dc_spi: unknown ICH generation. Please report! 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled Maximum FWH chip size: 0x100000 bytes BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x8 Root Complex Register Block address = 0xfed1c000 GCS = 0xc65: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (unknown) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3800 0x04: 0xf008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 WARNING: SPI Configuration Lockdown activated. Reading OPCODES... done 0x06: 0x3f00 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0 0x08: 0x00ffffc0 (FADDR) 0x50: 0x0000ffff (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. 0x58: 0x0fff0a00 FREG1: BIOS region (0x00a00000-0x00ffffff) is read-write. 0x5C: 0x09ff0001 FREG2: Management Engine region (0x00001000-0x009fffff) is read-write. 0x90: 0xc0 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xfc4010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=4 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05203b02 (OPMENU) 0x9C: 0x0000019f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x80802025 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x00002025 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0 0xD0: 0x50444653 (FPB) Enabling hardware sequencing because some important opcode is locked. SPI Read Configuration: prefetching enabled, caching enabled, OK. The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Found 1 attached SPI flash chip with a density of 16384 kB. The flash address space (0x000000 - 0x9acfff) is divided at address 0x653000 in two partitions. The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0x9acfff. In that range are 2477 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) at physical address 0x0. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x00, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: Chip size 2048 kB is bigger than supported size 1024 kB of chipset/board/programmer for FWH interface, probe/read/erase/write may fail. probe_82802ab: id1 0x2d, id2 0xbd, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: Chip size 2048 kB is bigger than supported size 1024 kB of chipset/board/programmer for FWH interface, probe/read/erase/write may fail. probe_82802ab: id1 0x2d, id2 0xbd, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xed, id2 0x88, id1 parity violation, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific). No operations were specified. Restoring MMIO space at 0x2b92ee7ee8a0 Restoring PCI config space for 00:1f:0 reg 0xdc

7 years

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom July 2013