September 2015 - flashrom - mail.coreboot.org

Re: [flashrom] CH341 patch request
by Stefan Tauner Sept. 30, 2015

Sept. 30, 2015

On Wed, 23 Sep 2015 17:24:01 +0200 Ádám Attila Nagy <osiixy(a)gmail.com> wrote: > Hi, > just to avoid oblivion I send this mail as you have asked. > Thanks Hi Ádám, sorry that it took me so long... I have pushed my current patch set for the CH341A to my github repo: https://github.com/stefanct/flashrom/tree/ch341a I have forgotten what does not work yet, and the code itself is definitely not in good shape yet either but feel free to hack away on it :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

SST39VF040 on 3COM 3C905C:
by Xavier Bourgeois Sept. 29, 2015

Sept. 29, 2015

The SST39VF040 is listed as untested on the flashrom supported hardware page. I tried it on a 3Com 3C905C (which limits to 128kbytes). All operations (probe, read, erase and write were done successfully for the first 128kbytes) [0]. I attached the NIC's bootrom [1], which was resized from 64kbytes to 512kbytes in order to be flashed. I also attached the same image which has been read after the flash. All the first 128kbytes are identical, and the data repeats until the end of the file. The network card is also able to boot from this eeprom. Thanks, [0]: http://monorailc.at/tmp/3c905c.tar.gz [1]: http://monorailc.at/tmp/3c905c_dump.tar.gz -- Xavier Bourgeois

2 1

Supported flash chips: AT45DB321D tested Probe, Read, Erase, Write successfully
by Igor Kubinski Sept. 29, 2015

Sept. 29, 2015

2 1

Issue Inquiry
by Jingfu Ju Sept. 28, 2015

Sept. 28, 2015

Hi, There, I failed to update BIOS with commandflashrom -w -p internal xxx.bin and uploaded flashrom -v message for your reference. Please help me take a look. Thanks. Best Regards,Jingfu

1 0

CH341 patch request
by Ádám Attila Nagy Sept. 23, 2015

Sept. 23, 2015

Hi, just to avoid oblivion I send this mail as you have asked. Thanks -- Nagy, Ádám Attila

1 0

Re: [flashrom] MX25L25635E / 4 byte addressing
by Stefan Tauner Sept. 21, 2015

Sept. 21, 2015

On Tue, 15 Sep 2015 02:26:39 -0400 Peter Martini <petercmartini(a)gmail.com> wrote: > Hello, > > I've checked out master from the flashrom svn repo, compiled, and was able > to see my chip (MX25L25635E). The id wasn't recognized, but after a quick > patch to copy a MX25L128... to ..L256.., I got it to successfully read the > first 16MB of the chip - however, I can't get any further than that, > because changing the values in the table to the right values moves me from > 3 byte addressing to 4 byte addressing territory (if I understand this > correctly), and it looks like there aren't any patches merged for that yet. > > Is there a patch set actively in the works? Nope, there isn't, at least nothing that I know about or that will hit vanilla flashrom soon. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

sending my verbose log as requested...
by Matthew D. Frederes Sept. 18, 2015

Sept. 18, 2015

[root@localhost ~]# flashrom -r current.bios -V flashrom v0.9.5.2-r1530 on Linux 2.6.32-573.el6.x86_64 (x86_64), built with libpci 3.1.4, GCC 4.4.6 20110731 (Red Hat 4.4.6-3), little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 2496M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1009 us, 10000 myus = 10006 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: " " DMI string system-product-name: " " DMI string system-version: " " DMI string baseboard-manufacturer: "Intel Corporation" DMI string baseboard-product-name: "DP35DP" DMI string baseboard-version: "AAD81073-209" DMI string chassis-type: "Desktop" Found chipset "Intel ICH9R" with PCI ID 8086:2916. Enabling flash write... 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode disabled 0xff600000/0xff200000 FWH decode disabled 0xff500000/0xff100000 FWH decode disabled 0xff400000/0xff000000 FWH decode disabled Maximum FWH chip size: 0x100000 bytes BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0xa WARNING: Setting 0xdc from 0xa to 0xb on ICH9R failed. New value is 0xa. Root Complex Register Block address = 0xfed1c000 GCS = 0x1464: BIOS Interface Lock-Down: disabled, Boot BIOS Straps: 0x1 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3800 0x04: 0xe008 (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: 0x2f00 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=47, SME=0 0x08: 0x00000000 (FADDR) 0x50: 0x00000a0b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x0a, BRRA 0x0b 0x54: 0x00000000 FREG0: WARNING: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x00ff0035 FREG1: BIOS region (0x00035000-0x000fffff) is read-write. 0x5C: 0x00340003 FREG2: WARNING: Management Engine region (0x00003000-0x00034fff) is locked. 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. Please send a verbose log to flashrom(a)flashrom.org if this board is not listed on http://flashrom.org/Supported_hardware#Supported_mainboards yet. Writes have been disabled. You can enforce write support with the ich_spi_force programmer option, but it will most likely harm your hardware! If you force flashrom you will get no support if something breaks. 0x90: 0x00 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0x004200 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=2, SME=0, SCF=0 0x94: 0x0006 (PREOP) 0x96: 0x0008 (OPTYPE) 0x98: 0x0000ab9f (OPMENU) 0x9C: 0x00000000 (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x00002009 (LVSCC) LVSCC: BES=0x1, WG=0, WSR=1, WEWS=0, EO=0x20, VCL=0 0xC8: 0x00002009 (UVSCC) UVSCC: BES=0x1, WG=0, WSR=1, WEWS=0, EO=0x20, VCL=0 0xD0: 0x00000000 (FPB) Enabling hardware sequencing because some important opcode is locked. SPI Read Configuration: prefetching enabled, caching enabled, PROBLEMS, continuing anyway 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 1024 kB. There is only one partition containing the whole address space (0x000000 - 0x0fffff). There are 256 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (1024 kB, Programmer-specific) at physical address 0x0. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x67, id2 0x21, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x1a, id2 0x9e, 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 0x67, id2 0x21, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x1a, id2 0x9e, 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 0x67, id2 0x21, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x38, id2 0x85, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x1a, id2 0x9e, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x1a, id2 0x9e, 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 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 0x1a, id2 0x9e, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x1a, id2 0x9e, 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 0x67, id2 0x21, 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 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 0x1a, id2 0x9e, 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 0x1a, id2 0x9e, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x1a, id2 0x9e, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x1a, id2 0x9e, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0x67, id2 0x21, 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 0x1a, id2 0x9e, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (1024 kB, Programmer-specific). Reading flash... Reading 1048576 bytes starting at 0x000000. Transaction error between offset 0x00003000 and 0x0000303f (= 0x00003000 + 63)! HSFS: FDONE=1, FCERR=1, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0 Read operation failed! FAILED. Restoring MMIO space at 0x7fb2d7a0e8a0 Restoring PCI config space for 00:1f:0 reg 0xdc [root@localhost ~]#

2 1

FS Esprimo E5730: reading rom does not seem to work if BIOS write protection is enabled
by Elmar Stellnberger Sept. 15, 2015

Sept. 15, 2015

Today I have tried to read the BIOS image of my Fujitsu Siemens Esprimo E5730. flashrom has complained about the write protection as being set in force manually by the BIOS settings although I have just tried to read an image: > flashrom -p internal:ich_spi_mode=auto --read test.rom flashrom v0.9.7-r1711 on Linux 3.14.50-std460-amd64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "Intel ICH10D". Enabling flash write... FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only. FREG2: Warning: Management Engine region (0x00003000-0x002f7fff) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see http://flashrom.org/ME for details. Writes have been disabled for safety reasons. You can enforce write support with the ich_spi_force programmer option, but you will most likely harm your hardware! If you force flashrom you will get no support if something breaks. On a few mainboards it is possible to enable write access by setting a jumper (see its documentation or the board itself). OK. Found Winbond flash chip "W25X32" (4096 kB, SPI) at physical address 0xffc00000. === This flash part has status UNTESTED for operations: READ 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! Reading flash... Transaction error! Read operation failed! FAILED. More information can be found in the attachements.

2 2

MX25L25635E / 4 byte addressing
by Peter Martini Sept. 15, 2015

Sept. 15, 2015

Hello, I've checked out master from the flashrom svn repo, compiled, and was able to see my chip (MX25L25635E). The id wasn't recognized, but after a quick patch to copy a MX25L128... to ..L256.., I got it to successfully read the first 16MB of the chip - however, I can't get any further than that, because changing the values in the table to the right values moves me from 3 byte addressing to 4 byte addressing territory (if I understand this correctly), and it looks like there aren't any patches merged for that yet. Is there a patch set actively in the works? (I saw some activity around this from January, from this link http://patchwork.coreboot.org/patch/4272/, but I'm not sure where that ended up). Thanks! Peter

1 0

Re: [flashrom] Contribution: option to disable read_all_first
by Willy Tarreau Sept. 14, 2015

Sept. 14, 2015

Hi David, On Mon, Sep 14, 2015 at 11:10:31AM -0700, David Hendricks wrote: > Hi Willy, > You might be interested in another approach that is used in the chromium > branch <https://chromium.googlesource.com/chromiumos/third_party/flashrom>. > The "--diff" longopt allows the user to supply a file to diff against the > -w argument. This is useful in cases where the user wishes to skip the > initial read step, and flashrom will figure out which blocks need to be > erased and written thereby eliminating unnecessary erase/write operations > as well. > > There is some documentation for it here: > https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flash… Thank you I'll take a look at it, it can indeed be another solution. The only thing is that it requires the creation of an extra file and I tend to find that it's not always convenient to have to create files for known patterns. However I think that it would be possible based on your approach to provide an option to replace the file with a known pattern for some cases (eg: full of 0xff or full of 0x00, which could be called "assume-clean" or "assume-dirty"), which would achieve the same result and at the same time not change the spirit of your latest work. Best regards, Willy

2 1