flashrom March 2012

flashrom@flashrom.org

46 participants
131 discussions

[PATCH] Add Documentation regarding unlocking the ME region on Intel chipsets.
by Stefan Tauner 12 Mar '12

12 Mar '12

Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- Documentation/mysteries_intel.txt | 81 ++++++++++++++++++++++++++++++++++++- 1 files changed, 80 insertions(+), 1 deletions(-) diff --git a/Documentation/mysteries_intel.txt b/Documentation/mysteries_intel.txt index d6d3dfb..8a9a113 100644 --- a/Documentation/mysteries_intel.txt +++ b/Documentation/mysteries_intel.txt @@ -15,4 +15,83 @@ See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html = Unlocking the ME region = -TODO + If the ME region is locked by the FRAP register in descriptor mode, the host + software is not allowed to read or write any address inside that region. There + are different ways to unlock access: + + - a pin strap: Flash Descriptor Security Override Strap (as indicated by the + Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is + probably not accessible to end users on consumer boards (every Intel doc i + have seen stresses that this is for debugging in manufacturing only and + should not be available for end users). + The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of + the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL]. + + - Intel Management Engine BIOS Extension (MEBx) Disable This option may be + available to end users on some boards usually accessible by hitting + ctrl+p after BIOS POST. Quote: "“Disabling” the Intel ME does not really + disable it: it causes the Intel ME code to be halted at an early stage of + the Intel ME’s booting so that the system has no traffic originating from + the Intel ME on any of the buses." [MEBX] + The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of + the HECI/MEI PCI device by setting them to 3 (Soft Temporary Disable) + [MODE_CTRL]. + + - Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or + channel?) #0 disables the ME completely, which may give the host access to + the ME region. + + - HMRFPO (Host ME Region Flash Protection Override) Enable MEI command + This is the most interesting one because it allows to temporarily disable + the ME region protection by software. The ME indicates this in bits [19:16] + (Operation Mode) in the HFS register of the HECI/MEI PCI device by setting + them to 5 (SECOVER_MEI_MSG) [MODE_CTRL]. + +== MEI/HECI == + Communication between the host software and the different services provided by + the ME is done via a packet-based protocol that uses MMIO transfers to one or + more virtual PCI devices. Upon this layer there exist various services that can + be used to read out hardware management values (e.g. temperatures, fan speeds + etc.). The lower levels of that protocol are well documented: + The locations/offsets of the PCI MMIO registers are noted in the chipset + datasheets. The actually communication is documented in a whitepaper [DCMI] and + an outdated as well as a current Linux kernel implementation (currently in + staging/ exist [KERNEL]. There exists a patch that re-implements this in user + space (as part of flashrom). + +== Problems == + The problem is that only very few higher level protocols are documented publicly, + especially the bunch of messages that contain the HMRFPO commands is probably + well protected and only documented in ME-specific docs and the BIOS writer's + guides. We are aware of a few leaked documents though that give us a few hints + about it, but nothing substantial regarding its implementation. + + The documents are somewhat contradicting each other in various points which + might be due to factual changes in process of time or due to the different + capabilities of the ME firmwares, example: + + Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI + ME Region, to prevent both writing at the same time, causing data corruption." [ME8] + + "FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if + used to update the ME Region." [SPS] + + When looking at the various ME firmware editions (and different chipsets), things + get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST + (EOP), others say that the ME region can be updated in the field or that some + vendor tools use it for updates. This needs to be investigated further before + drawing any conclusion. + +[MODE_CTRL] Client Platform Enabling Tour: Platform Software + Document Number: 439167, Revision 1.2, page 52 +[MEBX] Intel® Management Engine BIOS Extension (MEBX) User’s Guide + Revision 1.2, Section 3.1 and 3.5 +[DCMI] DCMI Host Interface Specification + Revision 1.0 +[KERNEL] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=d… +[SPI_PROG] Ibex Peak SPI Programming Guide + Document Number: 403598, Revision 1.3, page 79 +[ME8] Manufacturing with Intel® Management Engine (ME) Firmware 8.X on Intel 7 Series + Revision 2.0, page 59 +[SPS] Manufacturing with Intel® Management Engine (ME) on Intel® C600 Series Chipset 1 for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware + Revision 2.2, page 51 -- 1.7.1

1 0

Help sourcing flash chip W25Q25BV in PDIP8 package.
by Svetoslav Trochev 11 Mar '12

11 Mar '12

Hi Everyone, I am working on testing flashrom on Zotac ZBOX-AD02-PLUS-U. It uses Winbond W25Q25BV. I tried to get one from Digi-Key and Mouser Electronics, but they don't have it. I scavenge all my surplus boards and laptops, but none of them is using it. Any ideas how to get one? Thanks, Svetoslav Trochev

1 0

Re: [flashrom] Support for ASRock 890GX Extreme3 mainboard
by Stefan Tauner 11 Mar '12

11 Mar '12

On Wed, 29 Feb 2012 11:53:40 -0800 Svetoslav Trochev <svetoslav.trochev(a)gmail.com> wrote: > Hi Everybody, > > I am new here, so my apology if I am doing something wrong. > I have ASRock 890GX Extreme3 mainboard. This board has ability to be > flashed using standard BIOS, but never the less I decided to test > Flashrom. > I read the "Board Testing HOWTO" [1]. First signs are that this board > will work out of the box with "flashrom v0.9.4-r1394 on Linux > 3.0.4-pmagic (i686), built with libpci 3.1.7, GCC 4.6.1, little > endian" > What I have done so far: > 1. Ran 'flashrom' command and it detected the chip: Winbond W25Q80. > 2. Ran 'flashrom -R xxxx.rom' and it completed with no errors. I > examine the file and it looks like normal ROM file. > 3. Ran 'flashrom -V' I am attaching the output. > 4. I try comparing the backup copy of the EEPROM with the original > file provided by ASRock. It is different. They have exact same header, > but quite different. > 5. Because I am not 100% sure that I have good backup I decided to > order spare chip and continue with the test later. ( I have external > EEPROM programmer ) I will continue this weekend. > > Thank you and any comments are welcome and highly appreciated, > Svetoslav Trochev > > [1] http://www.flashrom.org/Board_Testing_HOWTO the board works in general (not 100% sure about 0.9.4, but pretty confident it will do): http://flashrom.org/Supported_hardware#Supported_mainboards the differences in the files could come from runtime data that the bios stores in the flash (e.g. logging) or some board-specific settings (like mac addresses) which are not part of the vendor image. partly correct reads are possible but quite uncommon. if you really wanna be prepared to use the external programmer, make sure that it supports SPI chips. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] ASRock H67M: Board Testing
by Stefan Tauner 11 Mar '12

11 Mar '12

On Sat, 3 Mar 2012 14:14:22 -0800 Svetoslav Trochev <svetoslav.trochev(a)gmail.com> wrote: > Hi Everyone, > > I just run test on ASRock H67M mainboard. I am attaching the output > files from "flashrom -V" and "lspci -nnvvxxx". After a quick search I > could not find how to run "superiotool -deV" on Ubuntu, but once I > figure it out I will attach the output as well. I hope the current > info is useful for now. > the flashrom -V output alone was enough in this case already, thanks. i have added the board to our list and will commit that later. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

linux_spi compilation fails due to too old linux headers (was: FlashRom and Intel C204 chipset.)
by Stefan Tauner 10 Mar '12

10 Mar '12

On Fri, 9 Mar 2012 23:13:24 +0400 "Andrey V. Bondarenko" <avbondarenko(a)gmail.com> wrote: > Hello, > > I downloaded flashrom-0.9.5.2.tar.bz2. The flashrom does not compile. I > think the problem is in SPI of kernel CentOS 5, the log of compilation is > below. The kernel is 2.6.18-274.18.1.el5. I didn't find the file > linux/spi/spidev.h. How can I compile flashrom without SPI? > > Log: > > Checking for a C compiler... found. > Target arch is x86 > Target OS is Linux > Checking for libpci headers... found. > Checking if libpci is present and sufficient... yes. > Checking for FTDI support... not found. > Checking for utsname support... found. > cc -MMD -Os -Wall -Wshadow -Werror -D'CONFIG_INTERNAL=1' > -D'CONFIG_SERPROG=1' -D'CONFIG_RAYER_SPI=1' -D'CONFIG_BITBANG_SPI=1' > -D'CONFIG_NIC3COM=1' -D'CONFIG_GFXNVIDIA=1' -D'CONFIG_SATASII=1' > -D'CONFIG_DUMMY=1' -D'CONFIG_DRKAISER=1' -D'CONFIG_NICREALTEK=1' > -D'CONFIG_NICINTEL=1' -D'CONFIG_NICINTEL_SPI=1' -D'CONFIG_OGP_SPI=1' > -D'CONFIG_BUSPIRATE_SPI=1' -D'CONFIG_SATAMV=1' -D'CONFIG_LINUX_SPI=1' > -D'NEED_PCI=1' -D'HAVE_UTSNAME=1' -D'FLASHROM_VERSION="0.9.5.2-r1515"' -o > linux_spi.o -c linux_spi.c > linux_spi.c:27:30: error: linux/spi/spidev.h: No such file or directory > linux_spi.c: In function 'linux_spi_init': > linux_spi.c:62: error: 'SPI_MODE_0' undeclared (first use in this function) > linux_spi.c:62: error: (Each undeclared identifier is reported only once > linux_spi.c:62: error: for each function it appears in.) > linux_spi.c:93: error: 'SPI_IOC_WR_MAX_SPEED_HZ' undeclared (first use in > this function) > linux_spi.c:102: error: 'SPI_IOC_WR_MODE' undeclared (first use in this > function) > linux_spi.c:108: error: 'SPI_IOC_WR_BITS_PER_WORD' undeclared (first use in > this function) > linux_spi.c: In function 'linux_spi_send_command': > linux_spi.c:134: error: array type has incomplete element type > linux_spi.c:136: error: field name not in record or union initializer > linux_spi.c:136: error: (near initialization for 'msg') > linux_spi.c:137: error: field name not in record or union initializer > linux_spi.c:137: error: (near initialization for 'msg') > linux_spi.c:140: error: field name not in record or union initializer > linux_spi.c:140: error: (near initialization for 'msg') > linux_spi.c:141: error: field name not in record or union initializer > linux_spi.c:141: error: (near initialization for 'msg') > cc1: warnings being treated as errors > linux_spi.c:155: warning: implicit declaration of function 'SPI_IOC_MESSAGE' > linux_spi.c:134: warning: unused variable 'msg' > make: *** [linux_spi.o] Error 1 > > P.S. Was the problem solved with Asus P8B-E/4 (see email in end)? hello, sorry! we did merge the linux_spi support without adding a proper check for the linux headers. we will fix that soonish until then you can compile flashrom with the following command without linux_spi support but with all other programmers that are enabled by default: make CONFIG_INTERNAL=yes CONFIG_SERPROG=yes CONFIG_RAYER_SPI=yes CONFIG_BITBANG_SPI=yes CONFIG_NIC3COM=yes CONFIG_GFXNVIDIA=yes CONFIG_SATASII=yes CONFIG_FT2232_SPI=yes CONFIG_DUMMY=yes CONFIG_DRKAISER=yes CONFIG_NICREALTEK=yes CONFIG_NICINTEL=yes CONFIG_NICINTEL_SPI=yes CONFIG_OGP_SPI=yes CONFIG_BUSPIRATE_SPI=yes CONFIG_SATAMV=yes CONFIG_LINUX_SPI=no the problem with the locked ME is not solved yet, sorry. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 3

Re: [flashrom] [PATCH] Add (untested) board enable for ASUS TUSL2-C
by Stefan Tauner 10 Mar '12

10 Mar '12

On Sat, 10 Mar 2012 17:55:54 +0100 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote: > Primary IDs SMBus controller, secondary IDs MCH. > The reverse engineering was done by Michael Karcher. > Андрей Тимираев <dark_prof(a)mail.ru> reported the problem, but did not > reply (yet) to our propsed fix. committed in r1516 -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[commit] r1516 - trunk
by repository service 10 Mar '12

10 Mar '12

Author: stefanct Date: Sat Mar 10 20:22:13 2012 New Revision: 1516 URL: http://flashrom.org/trac/flashrom/changeset/1516 Log: Add (untested) board enable for ASUS TUSL2-C Primary IDs SMBus controller, secondary IDs MCH. The reverse engineering was done by Michael Karcher. Андрей Тимираев <dark_prof(a)mail.ru> reported the problem, but did not reply (yet) to our propsed fix. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Modified: trunk/board_enable.c trunk/print.c Modified: trunk/board_enable.c ============================================================================== --- trunk/board_enable.c Thu Mar 8 23:01:25 2012 (r1515) +++ trunk/board_enable.c Sat Mar 10 20:22:13 2012 (r1516) @@ -1529,6 +1529,7 @@ * - ASUS P5GD2 Premium: Intel LGA775 + 915G + ICH6R * - ASUS P5GDC Deluxe: Intel socket775 + 915P + ICH6R * - ASUS P5PE-VM: Intel LGA775 + 865G + ICH5 + * - ASUS TUSL2-C: Intel socket370 + 815 + ICH2 * - Samsung Polaris 32: socket478 + 865P + ICH5 */ static int intel_ich_gpio21_raise(void) @@ -2173,6 +2174,7 @@ {0x10DE, 0x0260, 0x1043, 0x81BC, 0x10DE, 0x026C, 0x1043, 0x829E, "^P5N-D$", NULL, NULL, P3, "ASUS", "P5N-D", 0, OK, it8718f_gpio63_raise}, {0x10DE, 0x0260, 0x1043, 0x81BC, 0x10DE, 0x026C, 0x1043, 0x8249, "^P5N-E SLI$",NULL, NULL, P3, "ASUS", "P5N-E SLI", 0, NT, it8718f_gpio63_raise}, {0x8086, 0x24dd, 0x1043, 0x80a6, 0x8086, 0x2570, 0x1043, 0x8157, NULL, NULL, NULL, P3, "ASUS", "P5PE-VM", 0, OK, intel_ich_gpio21_raise}, + {0x8086, 0x2443, 0x1043, 0x8027, 0x8086, 0x1130, 0x1043, 0x8027, NULL, NULL, NULL, P3, "ASUS", "TUSL2-C", 0, NT, intel_ich_gpio21_raise}, {0x10b7, 0x9055, 0x1028, 0x0082, 0x8086, 0x7190, 0, 0, NULL, NULL, NULL, P3, "Dell", "OptiPlex GX1", 0, OK, intel_piix4_gpo30_lower}, {0x8086, 0x3590, 0x1028, 0x016c, 0x1000, 0x0030, 0x1028, 0x016c, NULL, NULL, NULL, P3, "Dell", "PowerEdge 1850", 0, OK, intel_ich_gpio23_raise}, {0x10de, 0x03ea, 0x1019, 0x2602, 0x10de, 0x03e0, 0x1019, 0x2602, NULL, NULL, NULL, P3, "Elitegroup", "GeForce6100SM-M", 0, OK, board_ecs_geforce6100sm_m}, Modified: trunk/print.c ============================================================================== --- trunk/print.c Thu Mar 8 23:01:25 2012 (r1515) +++ trunk/print.c Sat Mar 10 20:22:13 2012 (r1516) @@ -706,6 +706,7 @@ B("ASUS", "P8H67-M PRO", 0, NULL, "Probing works (Macronix MX25L3205, 4096 kB, SPI), but parts of the flash are problematic: descriptor is r/o (conforming to ICH reqs), ME region is locked."), B("ASUS", "P8P67 (rev. 3.1)", 0, NULL, "Probing works (Macronix MX25L3205, 4096 kB, SPI), but parts of the flash are problematic: descriptor is r/o (conforming to ICH reqs), ME region is locked."), B("ASUS", "P8Z68-V PRO", 0, NULL, "Probing works (Winbond W25Q64, 8192 kB, SPI), but parts of the flash are problematic: descriptor is r/o (conforming to ICH reqs), ME region is locked."), + B("ASUS", "TUSL2-C", 0, "http://support.asus.com/download.aspx?SLanguage=en&p=1&s=4&m=TUSL2-C&os=&ha…", "Untested board enable."), B("ASUS", "Z8NA-D6C", 1, "http://www.asus.com/Server_Workstation/Server_Motherboards/Z8NAD6C/", NULL), B("ASUS", "Z8PE-D12", 1, "http://www.asus.com/Server_Workstation/Server_Motherboards/Z8PED12/", NULL), B("BCOM", "WinNET100", 1, "http://www.coreboot.org/BCOM_WINNET100", "Used in the IGEL-316 thin client."),

1 0

bug
by Андрей Тимираев 10 Mar '12

10 Mar '12

[darkprof@SUT tusl-2c]$ sudo flashrom -w 1014tc.001 Пароль: flashrom v0.9.5.1-r1509 on Linux 3.0-ARCH (i686), built with libpci 3.1.9, GCC 4.6.2 20120120 (prerelease), little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. sh: dmidecode: команда не найдена dmidecode execution unsuccessful - continuing without DMI info Found chipset "Intel ICH2". Enabling flash write... OK. Found Winbond flash chip "W49V002FA" (256 kB, FWH) at physical address 0xfffc0000. === This flash part has status UNTESTED for operations: ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -VE, -Vw), and mention which mainboard or programmer you tested. Please mention your board in the subject line. Thanks for your help! Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... ERASE FAILED at 0x00000000! Expected=0xff, Read=0x25, failed byte count from 0x00000000-0x0000ffff: 0xfee7 ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00000000! Expected=0xff, Read=0x25, failed byte count from 0x00000000-0x0003ffff: 0x36050 ERASE FAILED! FAILED! Uh oh. Erase/write failed. Checking if anything changed. Good. It seems nothing was changed. Writing to the flash chip apparently didn't do anything. This means we have to add special support for your board, programmer or flash chip. Please report this on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org! ------------------------------------------------------------------------------- You may now reboot or simply leave the machine running. [darkprof@SUT tusl-2c]$ sudo flashrom -Vw 1014tc.001 Пароль: flashrom v0.9.5.1-r1509 on Linux 3.0-ARCH (i686), built with libpci 3.1.9, GCC 4.6.2 20120120 (prerelease), little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 476M loops per second, delay more than 10% too short (got 84% of expected delay), recalculating... 380M loops per second, delay more than 10% too short (got 69% of expected delay), recalculating... 364M loops per second, delay more than 10% too short (got 65% of expected delay), recalculating... 525M loops per second, 10 myus = 10 us, 100 myus = 93 us, 1000 myus = 1022 us, 10000 myus = 15445 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. sh: dmidecode: команда не найдена dmidecode execution unsuccessful - continuing without DMI info Found chipset "Intel ICH2" with PCI ID 8086:2440. Enabling flash write... BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0 OK. The following protocols are supported: FWH. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x25, id2 0xdc, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x25, id2 0xdc, 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 0xda, id2 0x32 Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xda, id2 0x32 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 0xda, id2 0x32 Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xda, id2 0x32 Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xda, id2 0x32 Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x25, id2 0xdc, 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: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x25, id2 0xdc, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x25, id2 0xdc, 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 0x25, id2 0xdc, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x25, id2 0xdc, 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 0xda, id2 0x32 Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xda, id2 0x32 Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xda, id2 0x32 Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xda, id2 0x32 Found Winbond flash chip "W49V002FA" (256 kB, FWH) at physical address 0xfffc0000. 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 0xda, id2 0x32 Found Winbond flash chip "W49V002FA" (256 kB, FWH). === This flash part has status UNTESTED for operations: ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -VE, -Vw), and mention which mainboard or programmer you tested. Please mention your board in the subject line. Thanks for your help! Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... Trying erase function 0... 0x000000-0x00ffff:EERASE FAILED at 0x00000000! Expected=0xff, Read=0x25, failed byte count from 0x00000000-0x0000ffff: 0xfee7 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x03ffff:EERASE FAILED at 0x00000000! Expected=0xff, Read=0x25, failed byte count from 0x00000000-0x0003ffff: 0x36050 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything changed. Good. It seems nothing was changed. Writing to the flash chip apparently didn't do anything. This means we have to add special support for your board, programmer or flash chip. Please report this on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org! ------------------------------------------------------------------------------- You may now reboot or simply leave the machine running. Restoring PCI config space for 00:1f:0 reg 0x4e [darkprof@SUT tusl-2c]$

3 3

Re: [flashrom] Dediprog programming is slow
by Carl-Daniel Hailfinger 10 Mar '12

10 Mar '12

Hi Jeff, Am 10.03.2012 05:52 schrieb jeff(a)linuxwest.com: > Thank you for the impressive work in this app! Glad to hear it works for you. > This is only my first time using Flashrom to write the bios file so I don't know > what is considered normal. The software provided by Dediprog writes the same > file in much less time it takes Flashrom to do it. I wonder if that's because > Flashrom will first erase the chip and then "In the process the chip is also > read several times"? No, it's because your flashrom version does not have the dediprog write speedup. You need at least 0.9.4-r1477 for a reasonable write speed (it won't help for all flash chips, but a majority of them). > Is it possible to bypass the erasing and in-memory backup operations to save > time? The slowness is with the "--noverify" option enabled. --noverify will save maybe 10 seconds if you're lucky. The slow write speed is caused by an incomplete dediprog driver in v0.9.4-r1395. > If I flash with the same image, it is really fast. Perhaps that is expected. But > notice in my attachment, it's taking 20 mins to flash 8M. You should get almost native speed (like the Windows tool from Dediprog) with latest flashrom unless your flash chip uses the AAI or write_1 methods. We're working to provide native speed for all SPI flash chips, but it depends on testers. > Also, something important I really want to know is if it is possible to run more > than one instance of flashrom at the same time (two dediprogs)? Do you own multiple Dediprogs? If yes, it would be very interesting to know how the Windows Dediprog tool differentiates between the two, and what flashrom does if it sees two Dediprogs (it will probably just ignore the second one). I'm willing to add support for concurrent flashrom instances (one per programmer) to the Dediprog driver if you're willing to test. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

Dediprog programming is slow
by jeff＠linuxwest.com 10 Mar '12

10 Mar '12

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom March 2012