- flashrom - mail.coreboot.org

BIOS. Read failed. Transaction error.
by thirumalai kumar 09 Jun '16

09 Jun '16

Hi, I am trying to update BIOS using flashrom in linux. This is Intel haswell board. i am trying to read the chipset name and download the existing BIOS image to verify whether flashrom is supported on this board or not. After this i am planning to use flashrom to upgrade BIOS on this. But the read operation itself is failing. Attached the log. *./flashrom -p internal* *Calibrating delay loop... OK.* *Found chipset "Intel C610/X99 (Wellsburg)".* *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 <flashrom(a)flashrom.org> including a verbose (-V) log.* *Thank you!* *Enabling flash write... Warning: BIOS region SMM protection is enabled!* *Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed.* *New value is 0x2b.* *Warning: SPI Configuration Lockdown activated.* *FREG2: Warning: Management Engine region (0x00011000-0x007fffff) is locked.* *Not all flash regions are freely accessible by flashrom. This is most likely* *due to an active ME. Please see https://flashrom.org/ME <https://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 "W25Q128.V" (16384 kB, SPI) mapped at physical address 0xff000000.* *No operations were specified.* The log for BIOS f/w download operation. *./flashrom -p internal -r bios_backup.bin* *flashrom v0.9.9-r1955 on Linux 2.6.32-573.el6.x86_64 (x86_64)* *flashrom is free software, get the source code at https://flashrom.org <https://flashrom.org>* *Calibrating delay loop... OK.* *Found chipset "Intel C610/X99 (Wellsburg)".* *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 <flashrom(a)flashrom.org> including a verbose (-V) log.* *Thank you!* *Enabling flash write... Warning: BIOS region SMM protection is enabled!* *Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed.* *New value is 0x2b.* *Warning: SPI Configuration Lockdown activated.* *FREG2: Warning: Management Engine region (0x00011000-0x007fffff) is locked.* *Not all flash regions are freely accessible by flashrom. This is most likely* *due to an active ME. Please see https://flashrom.org/ME <https://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 "W25Q128.V" (16384 kB, SPI) mapped at physical address 0xff000000.* *Reading flash... Transaction error!* *Read operation failed!* *FAILED.* Is the read operation failing due to the presence of ME region? Do i need to use vendor provided flasher utility to upgrade BIOS? Thanks in advance. -Thiru

1 0

asus P4P800MX error flash
by E 09 Jun '16

09 Jun '16

root@fe:~/flash# ./flashrom --programmer internal flashrom v0.9.9-r1955 on Linux 3.13.0-38-generic (i686) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... delay loop is unreliable, trying to continue OK. Found chipset "Intel ICH5/ICH5R". Enabling flash write... OK. Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) mapped at physical address 0xfff80000. No operations were specified. root@fe:~/flash# ./flashrom --programmer internal -c "Pm49FL004" -w 1003MXAS.rom flashrom v0.9.9-r1955 on Linux 3.13.0-38-generic (i686) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... delay loop is unreliable, trying to continue OK. Found chipset "Intel ICH5/ICH5R". Enabling flash write... OK. Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) mapped at physical address 0xfff80000. Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x0006c000! Expected=0xff, Found=0x07, failed byte count from 0x0006c000-0x0006cfff: 0xff2 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00060000! Expected=0xff, Found=0xf5, failed byte count from 0x00060000-0x0006ffff: 0x8fc6 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x0000a768! Expected=0xff, Found=0x44, failed byte count from 0x00000000-0x0007ffff: 0x6dda0 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Good, 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 chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! ------------------------------------------------------------------------------- You may now reboot or simply leave the machine running. root@fe:~/flash#

1 0

help with flashrom
by Nikos Mixailidis 07 Jun '16

07 Jun '16

hello everybody i need your help i try to flash my bios from my tablet onda v919 i try to backup my current bios with this command: sudo flashrom -p ch341a_spi --read backup.bin and i get this error Calibrating delay loop... OK. Couldn't open device 1a86:5512. Error: Programmer initialization failed. what am i doing wrong? i find this guide to help me https://peejseej.nl/2016/05/flash-an-bricked-onda-v919-air-ch-bios/comment-…

1 0

[PATCH] Add support for Fudan SPI flash chips
by Stefan Tauner 01 Jun '16

01 Jun '16

This includes the following chips: - FM25F005 - FM25F01 - FM25F02 and FM25F02A - FM25F04 and FM25F04A - FM25Q08 - FM25Q16 - FM25Q32 Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- flashchips.c | 272 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ flashchips.h | 10 +++ 2 files changed, 282 insertions(+) diff --git a/flashchips.c b/flashchips.c index 40b6b8e..e532168 100644 --- a/flashchips.c +++ b/flashchips.c @@ -5446,6 +5446,278 @@ const struct flashchip flashchips[] = { }, { + .vendor = "Fudan", + .name = "FM25F005", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25F005, + .total_size = 64, + .page_size = 256, + /* OTP: 256B total; enter 0x3A */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 16} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 2} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 1} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {64 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {64 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B), dual I/O (0x3B) supported */ + .voltage = {2700, 3600}, /* 2.3-2.7V acceptable results in lower performance */ + }, + + { + .vendor = "Fudan", + .name = "FM25F01", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25F01, + .total_size = 128, + .page_size = 256, + /* OTP: 256B total; enter 0x3A */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 32} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 4} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 2} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {128 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {128 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B), dual I/O (0x3B) supported */ + .voltage = {2700, 3600}, /* 2.3-2.7V acceptable results in lower performance */ + }, + + { + .vendor = "Fudan", + .name = "FM25F02(A)", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25F02, + .total_size = 256, + .page_size = 256, + /* OTP: 256B total; enter 0x3A, (A version only:) read ID 0x4B */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 64} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 8} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 4} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {1024 * 256, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {1024 * 256, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B), dual I/O (0x3B) supported */ + .voltage = {2700, 3600}, /* 2.3-2.7V acceptable results in lower performance */ + }, + + { + .vendor = "Fudan", + .name = "FM25F04(A)", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25F04, + .total_size = 512, + .page_size = 256, + /* OTP: 256B total; enter 0x3A, (A version only:) read ID 0x4B */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 128} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 16} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 8} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {1024 * 512, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {1024 * 512, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B), dual I/O (0x3B) supported */ + .voltage = {2700, 3600}, + }, + + { + .vendor = "Fudan", + .name = "FM25Q08", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25Q08, + .total_size = 1024, + .page_size = 256, + /* supports SFDP */ + /* OTP: 1024B total; read 0x48; write 0x42, erase 0x44, read ID 0x4B */ + /* QPI enable 0x38, disable 0xFF */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 256} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 32} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 16} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, /* bit6 selects size of protected blocks; TODO: SR2 */ + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ + .voltage = {2700, 3600}, + }, + + { + .vendor = "Fudan", + .name = "FM25Q16", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25Q16, + .total_size = 2048, + .page_size = 256, + /* supports SFDP */ + /* OTP: 1024B total; read 0x48; write 0x42, erase 0x44, read ID 0x4B */ + /* QPI enable 0x38, disable 0xFF */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 512} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 64} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 32} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {2 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {2 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, /* bit6 selects size of protected blocks; TODO: SR2 */ + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ + .voltage = {2700, 3600}, + }, + + { + .vendor = "Fudan", + .name = "FM25Q32", + .bustype = BUS_SPI, + .manufacture_id = FUDAN_ID_NOPREFIX, + .model_id = FUDAN_FM25Q32, + .total_size = 4096, + .page_size = 256, + /* supports SFDP */ + /* OTP: 1024B total; read 0x48; write 0x42, erase 0x44, read ID 0x4B */ + /* QPI enable 0x38, disable 0xFF */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = { + { + .eraseblocks = { {4 * 1024, 1024} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 128} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 64} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {4 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {4 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_bp2_tb_bpl, /* bit6 selects size of protected blocks; TODO: SR2 */ + .unlock = spi_disable_blockprotect_bp2_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ + .voltage = {2700, 3600}, + }, + + { .vendor = "Fujitsu", .name = "MBM29F004BC", .bustype = BUS_PARALLEL, diff --git a/flashchips.h b/flashchips.h index 9ffb30f..0a65444 100644 --- a/flashchips.h +++ b/flashchips.h @@ -328,6 +328,16 @@ #define FIDELIX_FM25Q32 0x3216 #define FIDELIX_FM25Q64 0x3217 +#define FUDAN_ID 0x7F7F7F7F7F7F7F4A /* Shanghai Fudan Microelectronics resides in bank 8 */ +#define FUDAN_ID_NOPREFIX 0x04 /* Fudan, missing 0x7F prefix */ +#define FUDAN_FM25F005 0x3110 +#define FUDAN_FM25F01 0x3111 +#define FUDAN_FM25F02 0x3112 /* Same as FM25F02A */ +#define FUDAN_FM25F04 0x3113 /* Same as FM25F04A */ +#define FUDAN_FM25Q08 0x4014 +#define FUDAN_FM25Q16 0x4015 +#define FUDAN_FM25Q32 0x4016 + #define FUJITSU_ID 0x04 /* Fujitsu */ #define FUJITSU_MBM29DL400BC 0x0F #define FUJITSU_MBM29DL400TC 0x0C -- Kind regards, Stefan Tauner

1 0

ASRock X99 WS-E BIOS backup fail
by Luis Tirado 30 May '16

30 May '16

Hello, Detection of the flash chip on this board succeeds, however reading flash contents to backup file fails as: Reading flash... Transaction error! SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=63, SME=0, SCF=0 Running OPCODE 0x03 failed at address 0x001000 (payload length was 64). Read operation failed! FAILED. Also, superiotool returns: No Super I/O found Perhaps that's the reason. See attached dumps for any additional details.

1 0

Re: [flashrom] Ideas for implementing support for 2nd status register
by Hatim Kanchwala 29 May '16

29 May '16

On Wednesday 25 May 2016 02:26 AM, David Hendricks wrote: > As Stefan points out, some decisions were made in ChromiumOS to avoid > modifying generic code and (in theory) make upstreaming easier. The > writeprotect stuff is the main example. We can re-visit some of those > decisions and put some code in generic locations if it makes sense to do so. > Thanks for the explanation. Highlighting use cases was helpful in understanding. I shall try to formulate future models based on clear use cases to convey more effectively. > I don't like the idea of using a FEATURE_SR2 bit - It doesn't describe > the functionality it represents in a useful manner IMO. As you point > out, reading SR2 needlessly can slow things down, especially for the > common use case where we only really care about reading the busy bit. Agreed. This was what I had in mind when I mentioned it. > For the write protection use case, the exact layout of the status > registers needs to be taken into account, not just whether SR2 is > present or not since SR2 is not as well standardized. To make matters > more complicated, Gigadevice GD25Q128 even has a 3rd status register > which has a bit that defines the entire write-protection scheme. Also, > some chips such as Spansion S25FS and S25FL series don't use status > registers in the same manner as other chips and instead define a set of > control registers with special opcodes to read/write them. > > Also, as Stefan points out, the status register bits are relevant to 4B > addressing and quad I/O in addition to write protection. The > implementation details are non-uniform. > I looked at the datasheets of the 28 SPI chips supported in flashrom that have multiple status registers. 24 of them have 35h opcode for RDSR2. Atmel(1) and Spansion(2) are complicated. And so is GD25Q128C. > Consequently, I think we need a combination of #2 and #3. For #2, we'll > have functions which read the status registers (but must be careful > since reading SR2 and SR3 aren't standardized AFAIK). For #3 we can > describe the functionality we desire in a reasonably generic way and add > chip-specific helper functions to carry out the task regardless of where > the bits we are interested in reside. I started going in this direction > for ChromiumOS's writeprotect.c, but it's still a work in progress: > https://chromium-review.googlesource.com/#/c/208271/ > https://chromium-review.googlesource.com/#/c/259440/ > https://chromium-review.googlesource.com/#/c/335822/ > https://chromium-review.googlesource.com/#/c/335823/ > So, based on the Chromium OS implementation (along with these patches, 2 of which I had to merge locally), this is the revised model. I agree that a combination of #2 and #3 will offer flexibility and can definitely convey more information. - enum status_register_bits enumerates all possible bits that we have - array of struct status_register_layout as part of struct flashchip - each array represents a status register and each element of array represents the bit (using the enum) - (*read_status)() within struct flashchip taking as argument which status register to read (SR1 or SR2 or SR3) - (*write_status)() within struct flashchip In addition to the above basic elements, we can have - const char *status_register_bit_name[] that has string-ified representation of corresponding bit from enum - array of int status_bit indexed by enum status_register_bits which is populated when corresponding read_status() is called To better convey the model, I have implemented some prototype code. Please have a look at the attached file. And have a look here (http://paste.flashrom.org/view.php?id=2918) for the output. Please ignore the violation of 112-character limit in the attached file. Please let me know your feedback on the model and on the proof-of-concept implementation. I would also love to hear suggestions/advice on the code style and quality. > tl;dr version: Overall I think we should just do the work of > representing the status register bits in a generic way, as you describe > in #3. It will be tedious at first, but many chips will be able to share > the same accessor functions. It's very important to be flexible so that > we don't end up with "square peg in a round hole" over-generalizing and > relying too heavily on if-statements/switch statements (a mistake I made > in the chromiumos sources). > I think a solution to making it less tedious would be to write a script to do as much of the modification as possible, and then manually deal with outliers. Based on comments in flashchips.c, we have 28 chips with more than one status register out of a total of 293 SPI chips (revisions that share definition are not considered different). Intuitively I think it best to roll out this feature in phases such that until the final phase, current (vanilla) flashrom behaviour exists in parallel. > On Tue, May 24, 2016 at 2:07 AM, Stefan Tauner > <stefan.tauner(a)alumni.tuwien.ac.at > <mailto:stefan.tauner@alumni.tuwien.ac.at>> wrote: > > On Tue, 24 May 2016 12:49:51 +0530 > Hatim Kanchwala <hatim(a)hatimak.me <mailto:hatim@hatimak.me>> wrote: > > > Hi, > > > > The GSoC coding period has started and I have been working on my > first > > sub-project, adding support for 2nd status register. Most supported > > chips that have multiple registers (around 80%) have opcode 0x35 for > > reading SR2 and, opcode 0x01 for writing SR2. I have developed 3 > models > > and would like to have some feedback on them. > > > > 1. Integrate read/write SR2 with existing functions > > PROPOSAL - > > - Define a feature bit FEATURE_SR2 > > - spi_read_status_register(), defined in spi25_statusreg.c, > additionally > > reads second status register depending on FEATURE_SR2 bit for > that flash > > - Change return to uint16_t for spi_read_status_register() > > - spi_write_status_register_flag(), defined in spi25_statusreg.c, > > considers higher byte of status to write to SR2, depending on > > FEATURE_SR2 bit for that flash. > > MERITS - > > - Fits in elegantly with existing implementation (IMO). Most code in > > flashrom stores status reads/writes in int, which can easily > accommodate > > the 16 bits > > - Very little hassle when editing struct flashchip in flashchips.c > > > > DEMERITS - > > - RDSR will take more time - will read SR2 even if not needed > > > > 2. Define separate functions to read/write SR2 > > PROPOSAL - > > - Define spi_read_status_register2() to read only SR2 > > - Define spi_write_status_register2_flag() and > > spi_write_status_register2() to write to SR2. This will read SR1 > first, > > then (SR2 << 8 | SR1) will be written using WRSR > > > > MERITS - > > - Flexibility (as compared to 1.) > > > > DEMERITS - > > - Need to write more lines (compared to 1.) when dealing with struct > > flashchip > > > > 3. struct status_register_layout > > The ChromiumOS fork defines a struct status_register_layout in > > writeprotect.c, which contains only BP and SRP bits' information. > > PROPOSAL - > > Do a similar flashrom-wide definition, which contains all status > > register bits' information. > > > > MERITS - > > - Very detailed representation of information > > > > DEMERITS - > > - Too much work when adding support for new chips > > - Overhaul of existing infrastructure > > > > IMHO, the first model is the best among these 3. I would like to know > > what you guys think about these, whether you have some new idea. > Looking > > forward to your feedback. Thanks for your time. > > Hi, > > thanks Hatim for this summary. It may make sense if David could sum up > the rationales behind the chromiumos implementation. AFAIK much of that > is driven by the desire to not touch flashchips.c to ease later > upstreaming. A more detailed explanation might help Hatim. > > What I miss from Hatim's proposals is how use cases affect the various > implementations. The main question that needs to be addressed before > implementing any kind of infrastructure like this is: what do we want > to do with it once it is there. > > Till now (vanilla) flashrom did only access the status registers for > gathering (and printing) the status, especially the write protection > bits, and for unlocking said bits. > In the future we want to at least be able to set various protections > additionally. What else do we need? Some bits are relevant to 4B > addressing and Quad I/O too for example... > > -- > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> > https://www.flashrom.org/mailman/listinfo/flashrom > > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. Thanks for your time. Bye, Hatim

3 4

Hi I'm Johnny can the usb jtag nt or usb jtag work with flashrom
by LONGJON CREATIONS 27 May '16

27 May '16

Hiya there I would like to know if the usb jtag nt can work with flashrom if so how or what device name would I use or can use give me an examplecommand I also have the first usb jtag not nt as well I'm using debian stretchthese are my hardware info per device below thank you in advance ☺ usb jtag nt ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit usb jtag ID 0547:2131 Anchor Chips, Inc. AN2131 EZUSB Microcontroller

1 0

i350 support in flashrom test results
by Olliver Schinagl 25 May '16

25 May '16

I just applied Stefan's patch [0] to the march master of flashrom and tested it on a Winyao WYI350T dual intel NIC: 04:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521] (rev 01) and successfully found a flash chip: Found Micron/Numonyx/ST flash chip "M25P40" (512 kB, SPI) on nicintel_spi. After dumping the firmware, writing a new iPXE rom everything seems to work: Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. /tmp/bootutil64e -nic 1 1 2C534A012460 4:00.0 Gigabit YES PXE Enabled 15.9.253 Just gotta figure out how to append pxe and uefi images now :) Olliver [0] http://patchwork.coreboot.org/patch/4394/

1 0

I do nothing in hardward, but appear a problem, hope you can do it , thanks!
by 李晓伟 25 May '16

25 May '16

flashrom v0.9.9-unknown on MS-DOS 7 (i686) flashrom was built with libpci 3.1.5, GCC 4.9.2, little endian Command line (7 args): c:/flashrom/bin/flashrom.exe -p internal -V -w intel.bin -o li6.txt Calibrating delay loop... OS timer resolution is 60000 usecs, 398M loops per second, 10 myus = 0 us, 100 myus = 0 us, 1000 myus = 0 us, 10000 myus = 0 us, 240000 myus = 270000 us, OK. Initializing internal programmer Error accessing low megabyte, 0x100000 bytes at 0x00000000 dpmi mmap failed: No such file or directory (ENOENT) Failed getting access to coreboot low tables. Using Internal DMI decoder. Error accessing DMI, 0x10000 bytes at 0x000f0000 dpmi mmap failed: No such file or directory (ENOENT) Found chipset "VIA VT8237(R)" with PCI ID 1106:3227. Enabling flash write... OK. The following protocols are supported: Non-SPI. Probing for AMD Am29F010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for AMD Am29F010A/B, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BB, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BT, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F016D, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for AMD Am29F040B, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F080, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F080B, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV001BB, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV001BT, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV002BB, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV002BT, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV004BB, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV004BT, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV008BB, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV008BT, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV040B, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV081B, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002B, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002T, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29040B, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A49LF040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT29C512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT29C010A, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT29C020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT29C040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49BV512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49F002(N), 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49F002(N)T, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49(H)F010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49F020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49F040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Atmel AT49F080, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49F080T, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Catalyst CAT28F512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Bright BM29F040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for ESMT F49B002UA, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Eon EN29F010, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)B, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)T, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29LV040(A), 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Eon EN29LV640B, 8192 kB: probe_en29lv640b: id1 0xffff, id2 0x00ff Probing for Eon EN29GL064(A)B, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Eon EN29GL064(A)T, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Eon EN29GL064H/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Eon EN29GL128, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Fujitsu MBM29F004BC, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F004TC, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F400BC, 512 kB: probe_jedec_common: id1 0x4e, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F400TC, 512 kB: probe_jedec_common: id1 0x4e, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29LV160BE, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29LV160TE, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Hyundai HY29F002T, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Hyundai HY29F002B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Hyundai HY29F040A, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F001BN/BX-B, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Intel 28F001BN/BX-T, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Intel 28F002BC/BL/BV/BX-T, 256 kB: probe_82802ab: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F008S3/S5/SC, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004B5/BE/BV/BX-B, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004B5/BE/BV/BX-T, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/BX/CE/CV-B, 512 kB: probe_82802ab: id1 0x4e, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/BX/CE/CV-T, 512 kB: probe_82802ab: id1 0x4e, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, 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 ISSI IS29GL064B, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for ISSI IS29GL064T, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for ISSI IS29GL064H/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for ISSI IS29GL128H/L, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29F001B, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F001T, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002(N)B, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002(N)T, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F022(N)B, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F022(N)T, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F040, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29GL320EB, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL320ET, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL320EH/L, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL640EB, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL640ET, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL640EH/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL128F, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29LV040, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51000B, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for MoselVitelic V29C51000T, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for MoselVitelic V29C51400B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for MoselVitelic V29C51400T, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for MoselVitelic V29LC51000, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for MoselVitelic V29LC51001, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for MoselVitelic V29LC51002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for PMC Pm29F002T, 256 kB: Chip lacks correct probe timing information, using default 10ms/40us. probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm29F002B, 256 kB: Chip lacks correct probe timing information, using default 10ms/40us. probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV010, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV020, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV040, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV512, 64 kB: probe_jedec_common: id1 0xbb, id2 0xb3, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Sharp LH28F008BJT-BTLZ1, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, 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 SST28SF040A, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST29EE010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST29LE010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST29EE020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST29LE020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39SF512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39SF010A, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39SF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39SF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39VF512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39VF010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39VF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39VF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST39VF080, 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 SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Found SST flash chip "SST49LF004A/B" (512 kB, FWH) mapped at physical address 0xfff80000. Lock status for 0x000000 (size 0x010000) is 01, write locked Lock status for 0x010000 (size 0x010000) is 01, write locked Lock status for 0x020000 (size 0x010000) is 01, write locked Lock status for 0x030000 (size 0x010000) is 01, write locked Lock status for 0x040000 (size 0x010000) is 01, write locked Lock status for 0x050000 (size 0x010000) is 01, write locked Lock status for 0x060000 (size 0x010000) is 01, write locked Lock status for 0x070000 (size 0x010000) is 01, write locked Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, 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: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST49LF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST49LF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST49LF040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SST SST49LF080A, 1024 kB: Chip lacks correct probe timing information, using default 10ms/40us. probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF160C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002B, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002T/NT, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F040B, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F400BB, 512 kB: probe_jedec_common: id1 0x4e, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F400BT, 512 kB: probe_jedec_common: id1 0x4e, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29W010B, 128 kB: probe_jedec_common: id1 0xe2, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29W040B, 512 kB: probe_jedec_common: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29W512B, 64 kB: probe_jedec_common: id1 0xbb, id2 0xb3, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x4e, id2 0x41, 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 0x88, id2 0xfe, id1 parity violation, 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 0x4e, id2 0x41, 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 ST M50LPW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50LPW116, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51001B, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {F,S,V}29C51001T, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {F,S,V}29C51002B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {F,S,V}29C51002T, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {F,S,V}29C51004B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {F,S,V}29C51004T, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {S,V}29C31004B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for SyncMOS/MoselVitelic {S,V}29C31004T, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for TI TMS29F002RB, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for TI TMS29F002RT, 256 kB: probe_jedec_common: id1 0x88, id2 0xfe, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C512A/W29EE512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W29C010(M)/W29C011A/W29EE011/W29EE012-old, 128 kB: Old Winbond W29* probe method disabled because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29C010(M)/W29C011A/W29EE011/W29EE012-old' if you have a board with such a chip. Probing for Winbond W29C010(M)/W29C011A/W29EE011/W29EE012, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W29C020(C)/W29C022, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W29C040/P, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W29GL032CB, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL032CT, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL032CH/L, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL064CB, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL064CT, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL064CH/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL128C, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W39F010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39L010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39L020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39L040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V040C, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W39V080A, 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 W49F002U/N, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W49F020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W49V002A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xbf, id2 0x60 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 0xbf, id2 0x60 Found SST flash chip "SST49LF004A/B" (512 kB, FWH). Lock status for 0x000000 (size 0x010000) is 01, write locked Trying to clear lock for 0x000000... Lock status for 0x000000 (size 0x010000) is 00, full access OK Lock status for 0x010000 (size 0x010000) is 01, write locked Trying to clear lock for 0x010000... Lock status for 0x010000 (size 0x010000) is 00, full access OK Lock status for 0x020000 (size 0x010000) is 01, write locked Trying to clear lock for 0x020000... Lock status for 0x020000 (size 0x010000) is 00, full access OK Lock status for 0x030000 (size 0x010000) is 01, write locked Trying to clear lock for 0x030000... Lock status for 0x030000 (size 0x010000) is 00, full access OK Lock status for 0x040000 (size 0x010000) is 01, write locked Trying to clear lock for 0x040000... Lock status for 0x040000 (size 0x010000) is 00, full access OK Lock status for 0x050000 (size 0x010000) is 01, write locked Trying to clear lock for 0x050000... Lock status for 0x050000 (size 0x010000) is 00, full access OK Lock status for 0x060000 (size 0x010000) is 01, write locked Trying to clear lock for 0x060000... Lock status for 0x060000 (size 0x010000) is 00, full access OK Lock status for 0x070000 (size 0x010000) is 01, write locked Trying to clear lock for 0x070000... Lock status for 0x070000 (size 0x010000) is 00, full access OK 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-0x000fff:EFAILED at 0x00000000! Expected=0xff, Found=0x4e, failed byte count from 0x00000000-0x00000fff: 0xafd ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x00ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x4e, failed byte count from 0x00000000-0x0000ffff: 0x15fa ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Good, 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 chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! ------------------------------------------------------------------------------- You may now reboot or simply leave the machine running. Restoring PCI config space for 00:11:0 reg 0x59 Restoring PCI config space for 00:11:0 reg 0x40 Restoring PCI config space for 00:11:0 reg 0x41

1 0

Ideas for implementing support for 2nd status register
by Hatim Kanchwala 24 May '16

24 May '16

Hi, The GSoC coding period has started and I have been working on my first sub-project, adding support for 2nd status register. Most supported chips that have multiple registers (around 80%) have opcode 0x35 for reading SR2 and, opcode 0x01 for writing SR2. I have developed 3 models and would like to have some feedback on them. 1. Integrate read/write SR2 with existing functions PROPOSAL - - Define a feature bit FEATURE_SR2 - spi_read_status_register(), defined in spi25_statusreg.c, additionally reads second status register depending on FEATURE_SR2 bit for that flash - Change return to uint16_t for spi_read_status_register() - spi_write_status_register_flag(), defined in spi25_statusreg.c, considers higher byte of status to write to SR2, depending on FEATURE_SR2 bit for that flash. MERITS - - Fits in elegantly with existing implementation (IMO). Most code in flashrom stores status reads/writes in int, which can easily accommodate the 16 bits - Very little hassle when editing struct flashchip in flashchips.c DEMERITS - - RDSR will take more time - will read SR2 even if not needed 2. Define separate functions to read/write SR2 PROPOSAL - - Define spi_read_status_register2() to read only SR2 - Define spi_write_status_register2_flag() and spi_write_status_register2() to write to SR2. This will read SR1 first, then (SR2 << 8 | SR1) will be written using WRSR MERITS - - Flexibility (as compared to 1.) DEMERITS - - Need to write more lines (compared to 1.) when dealing with struct flashchip 3. struct status_register_layout The ChromiumOS fork defines a struct status_register_layout in writeprotect.c, which contains only BP and SRP bits' information. PROPOSAL - Do a similar flashrom-wide definition, which contains all status register bits' information. MERITS - - Very detailed representation of information DEMERITS - - Too much work when adding support for new chips - Overhaul of existing infrastructure IMHO, the first model is the best among these 3. I would like to know what you guys think about these, whether you have some new idea. Looking forward to your feedback. Thanks for your time. Bye, Hatim

3 2

Failed coreboot flash on pixel2
by Richard Weerasinghe 24 May '16

24 May '16

Here is the output: chronos@localhost /tmp $ sudo flashrom -w coreboot-seabios-samus-20160324-coolstar.rom flashrom v0.9.4 : df00e76 : Mar 22 2016 19:53:33 UTC on Linux 3.14.0 (x86_64), built with libpci 3.1.10, GCC 4.9.x-google 20150123 (prerelease), little endian Erasing and writing flash chip... Transaction error! spi_block_erase_20 failed during command execution at address 0x3e0000 ERASE FAILED! Reading current flash chip contents... spi_block_erase_52 failed during command execution at address 0x3e0000 ERASE FAILED! Reading current flash chip contents... Transaction error! spi_block_erase_d8 failed during command execution at address 0x3e0000 ERASE FAILED! Reading current flash chip contents... spi_chip_erase_60 failed during command execution ERASE FAILED! Reading current flash chip contents... spi_chip_erase_c7 failed during command execution 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. FAILED If you need more info, please let me know. cheers Richard ᐧ

1 0

ft2232_spi JTAGkey OE disabled for CS high
by Ulrich Holeschak 20 May '16

20 May '16

Hello, when using the ft2232_spi driver with Amontec JTAGkey, the OE signal (bit 4) is disabled when de-asserting CS: msg_pspew("De-assert CS#\n"); buf[i++] = SET_BITS_LOW; buf[i++] = cs_bits; buf[i++] = pindir; This means that the CS high signal is floating and the voltage level is unstable. Filtering the OE bit fixes this issue: msg_pspew("De-assert CS#\n"); buf[i++] = SET_BITS_LOW; buf[i++] = cs_bits & 0x0F; // keep OE active buf[i++] = pindir; Regards, Ulrich

1 0

T420 internal flashing: Transactions Error
by Arian Sanusi 18 May '16

18 May '16

Hi All, I'm trying to re-flash coreboot on a T420 that already runs coreboot - the same image that's currently flashed actually. According to coreboot wiki, that should be possible. [1] I think I enabled write-lock of the ME region in coreboot, but I can't find the option, nor the .config line anymore. flashrom: flashrom v0.9.9-r1954 on Linux 4.3.0-1-amd64 (x86_64) coreboot: * master 831d65d intel/apollolake: Fix logic error Can anyone help? Thank you Arian Attached: flashrom output, coreboot .config

1 0

Results for board: MSI MS-7528 G31M3(-F)
by callmeclean 16 May '16

16 May '16

I've successfully read from & written updated BIOS to this motherboard, both verified. The modelling is a bit confusing, there are a few revisions of the board. I can't say for certain, but it seems G31M3 and G31M3-F are the same board. BIOS images from G31M3-F product page work on my board missing the -F (which I can't find any official mention of). Attached are the output of flashrom -p internal -V, lspci -nnvvxxx and superiotool -deV in results1.txt, results2.txt and results3.txt respectively. Please tell me if attachments are not acceptable and I will reply with the full text (the outputs are very long!).

1 0

Re: [flashrom] ENE KB9012 Programming with flashrom
by Joerg Albert 16 May '16

16 May '16

On 01.05.2016 10:37, Paul Kocialkowski wrote: > Hi, > > could you CC the flashrom mailing list in your future responses? This will > probably interest others! I wasn't aware of this mailing lists, thanks! > Le dimanche 24 avril 2016 à 23:15 +0200, Joerg Albert a écrit : >> I'll try to program the internal SPI of a KB9012 (inside a Thinkpad S531) - as >> soon as I've found the correct image and soldered the necessary wires. > The KB9012 chips has an internal flash memory that is distinct from the BIOS' > SPI flash, so beware not to confuse both! I'm aware of this. The S531 manual says, that the system indicator LED shall flash three times when the power supply gets connected (without switching the notebook on). As I don't see this and the voltage at the KB9012 is correct I guess that the EC is not working properly. Flashing the BIOS SPI may be the second step ;-) >> Found your patch here: >> >> http://patchwork.coreboot.org/patch/4325/ >> >> Why couldn't I use FlashDirectAccess? Is this meant to program external SPI >> flash only? > Yes, that's my understanding of it too. It just makes a bridge between the BIOS' > SPI flash and the KB9012 pads. This is because it's often easier to reflash it > using the keyboard connector, that is often available without fully opening the > device. > > What you want if you need to reflash the EC is not FlashDirectAccess, but EDI. > Note that some firmwares explicitly disable it, so you have to ground pin 42 to > enter "test mode", where the 8051 is not running. > > Note that the EDI pins are often exported on the keyboard connector, which makes > soldering more doable. > The keyboard connector of the S531 has a pitch of 0.5mm, too close for my soldering experience. I couldn't find a flex cable matching the connector either, so I went for soldering wires to some vias/testpoints instead. Connected a RaspberryPi and had some problems with the detection of the KB9012. It seemed to detect the KB9012 on every second trial only: -------------- pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c "KB9012 (EDI)" -V flashrom v0.9.9-r1954 on Linux 3.18.11+ (armv6l) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.1.9, GCC 4.6.3, little endian Command line (5 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c KB9012 (EDI) -V Calibrating delay loop... OS timer resolution is 5 usecs, 229M loops per second, 10 myus = 11 us, 100 myus = 103 us, 1000 myus = 994 us, 10000 myus = 10064 us, 20 myus = 26 us, OK. Initializing linux_spi programmer Using device /dev/spidev0.0 Using 1024 kHz clock The following protocols are supported: SPI. Probing for ENE KB9012 (EDI), 128 kB: probing for EDI EDI: found hw version 195 EDI id 4 Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on linux_spi. No operations were specified. pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c "KB9012 (EDI)" -V flashrom v0.9.9-r1954 on Linux 3.18.11+ (armv6l) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.1.9, GCC 4.6.3, little endian Command line (5 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c KB9012 (EDI) -V Calibrating delay loop... OS timer resolution is 4 usecs, 226M loops per second, 10 myus = 11 us, 100 myus = 102 us, 1000 myus = 1839 us, 10000 myus = 10424 us, 16 myus = 21 us, OK. Initializing linux_spi programmer Using device /dev/spidev0.0 Using 1024 kHz clock The following protocols are supported: SPI. Probing for ENE KB9012 (EDI), 128 kB: probing for EDI EDI: failed to read hw version (-1) No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c "KB9012 (EDI)" -V flashrom v0.9.9-r1954 on Linux 3.18.11+ (armv6l) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.1.9, GCC 4.6.3, little endian Command line (5 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c KB9012 (EDI) -V Calibrating delay loop... OS timer resolution is 5 usecs, 229M loops per second, 10 myus = 11 us, 100 myus = 102 us, 1000 myus = 994 us, 10000 myus = 10061 us, 20 myus = 22 us, OK. Initializing linux_spi programmer Using device /dev/spidev0.0 Using 1024 kHz clock The following protocols are supported: SPI. Probing for ENE KB9012 (EDI), 128 kB: probing for EDI EDI: found hw version 195 EDI id 4 Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on linux_spi. No operations were specified. -------- I've also tried with "speed=2048" (as the KB9012 manual states a minimum clock of 1MHz) - same problem. / /I've added some error/debug printouts and it seems like the KB9012 answers with all-zeros on each second start of the probe. If the buffer content is correct everything else afterwards works fine. So I've added a quick workaround in edi_read_byte() and edi_read() to re-do any read if the buffer contains zero at the first byte. See the patches attached. No idea why it behaves that way, maybe the SPI detection on these pins is a bit shaky? Pin 42 was grounded and the KB9012 remained powered during the whole session. Cheers, Joerg

2 1

BIOS image write and safety
by Nicolas Clerc 13 May '16

13 May '16

Hi guys, I need for a specific project to change BIOS Settings on many computers. So far, I used flashrom to read out the flash memory of my BIOS. Flashrom successfully detects the Winbond W25Q32.V flash, and I can dump the whole 32Mbits. With your experience, do you know if it is *generally* quite safe to write an image that has been dumped (both using flashrom ofc) ? I have been doing several memory dumps of this BIOS flash, each one separated by a reboot, and can see a modification between each dump. I suspect there's a kind of event log or journal that is kept by the BIOS, but I can't find a way to read it (neither BIOS menu nor external software). The BIOS is from AMI. Any advice is welcome, Cheers Nicolas

1 0

SST26VF032B support
by Peter Hall 10 May '16

10 May '16

Hi, I got the flashrom working on a BeagleBone programming a SST26VF032B with some modifications to 0.9.9. Do you want me to upload the modifications? I mostly copied the changes from another post, but I can't remember where that was from and I made some tweaks myself. These changes definitely work, I've test this multiple times on multiple boards. Let me know if you want the source Regards Peter Hall Software Development Manager Raster Vision Ltd. Tel: 01892 722228 / +44 1892 722228. www.rvl.co.uk <http://www.rvl.co.uk/> Raster Vision Ltd is a company registered in England and Wales, number: 02753356. Registered office: Unit 1, Crundalls, Gedges Hill, Matfield, Tonbridge, Kent, TN12 7EA, UK. C2- Restricted

1 0

Re: [flashrom] New SPI NOR Flash product Support
by Victor Lim 10 May '16

10 May '16

Thanks, David, For Gigadevice part numbers, we do keep ID, read, erase, write opcodes, sector protection, and architecture the same. I am wondering if Flashrom program needs to call out the new part numbers so that users know which part number to choose from. Regards, Victor From: David Hendricks [mailto:dhendrix@google.com] Sent: Sunday, May 8, 2016 7:43 PM To: Victor Lim <vlim(a)gigadevice.com> Cc: Hatim Kanchwala <hatim(a)hatimak.me>; flashrom <flashrom(a)flashrom.org>; Katherine (GigaDevice//US) <ksong(a)gigadevice.com> Subject: Re: [flashrom] New SPI NOR Flash product Support Hello Victor, Chips with same ID and read, erase, and write opcodes are supported. For ChromeOS platforms it is also important that new revision chips have identical block protection capabilities as the older parts (I've had difficulties with other vendors regarding this...). On Fri, May 6, 2016 at 4:55 PM, Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > wrote: Hi, Hatim, We have new revision chips that share the same ID as the previous revision, will they be considered supported because they share the same basic Erase and program command. New part # GD25LQ64C: manufacturer ID: 0x6017 Currently supported part # GD25LQ64: manufacturer ID: 0x6017 New part # GD25LQ128C: manufacturer ID: 0x6018 Currently supported part # GD25LQ128: manufacturer ID: 0x6018 Do you need new samples for verification? We do keep the same ID for new revision release, so the SW should work for new revision parts. Regards, Victor -----Original Message----- From: Hatim Kanchwala [mailto:hatim@hatimak.me <mailto:hatim@hatimak.me> ] Sent: Friday, March 25, 2016 1:27 PM To: Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > Cc: flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> ; ksong(a)gigadevice.com <mailto:ksong@gigadevice.com> Subject: Re: [flashrom] New SPI NOR Flash product Support Hello Victor, I am doing fine, thanks :) The following chips have been tested successfully - GD25D05B/10B, GD25LQ10B/20B/40B/80B, GD25Q21B/41B and GD25VQ41B (reported by David Hendrix). Test logs for the first 8 of these chips can be found here - https://www.flashrom.org/pipermail/flashrom/2016-March/014537.html. The patches for all these chips and additionally GD25Q80C/16C have been sent and are waiting for further review. I have ordered some IC clips, so I will test the remaining chips as soon as those arrive. Unfortunately, one of the chips you explicitly requested support for, GD25Q128C was not included in the samples so was not tested. But support for it has already been added ;) Apologies for the late reply. :) On Tuesday 22 March 2016 01:20 AM, Victor Lim wrote: > Hi, Hatim, > > How are you doing? Hope all the sample test results are good. > Can you please update the status so that I can ask customer to try out. > > Regards, > > Victor > > > > -----Original Message----- > From: Hatim Kanchwala [mailto:hatim@hatimak.me <mailto:hatim@hatimak.me> ] > Sent: Wednesday, February 24, 2016 9:02 AM > To: Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > > Cc: flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> ; ksong(a)gigadevice.com <mailto:ksong@gigadevice.com> > Subject: Re: [flashrom] New SPI NOR Flash product Support > > Hello Victor, > > Support for two chips you requested was added some time ago in r1937 > (look here https://tracker.coreboot.org/trac/flashrom/changeset/1937). > I am waiting for samples to perform tests. FedEx was in touch > regarding documents for customs clearance, so delivery should be in a > day or two. In the meanwhile I am working on support for other > GigaDevice chips (http://www.gigadevice.com/product-series/12.html). > > On Wednesday 24 February 2016 04:47 AM, Victor Lim wrote: >> Hi, Hatim, >> >> How is the new program to include these two part #? >> I have sent the samples to you, but they are held up at the Fedex >> facility at New Delhi. >> Can you please give Fedex the instruction for delivery? >> The tracking # is 806824856677 >> >> Regards, >> >> Victor >> >> >> >> >> -----Original Message----- >> From: Victor Lim [mailto:vlim@gigadevice.com <mailto:vlim@gigadevice.com> ] >> Sent: Tuesday, February 9, 2016 3:02 PM >> To: 'Hatim Kanchwala' <hatim(a)hatimak.me <mailto:hatim@hatimak.me> > >> Cc: 'flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> ' <flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> > >> Subject: RE: [flashrom] New SPI NOR Flash product Support >> >> Thanks, Hatim, >> >> Please help me on these two part #s, datasheets are attached. >> 1) GD25VQ41B >> 2) GD25Q128C >> >> Can you provide the ship to address, I will send you same samples. >> What package type do you prefer? >> >> Regards, >> >> Victor >> >> >> >> -----Original Message----- >> From: Hatim Kanchwala [mailto:hatim@hatimak.me <mailto:hatim@hatimak.me> ] >> Sent: Tuesday, February 9, 2016 12:27 PM >> To: Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > >> Cc: flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> >> Subject: Re: [flashrom] New SPI NOR Flash product Support >> >> Hello Victor, >> >> I have recently started looking at flashrom and have contributed by >> adding a few SPI flashchip definitions. I would be glad to add >> support for the SPI chips. Usually datasheets are sufficient for >> adding flashchip support (as long as datasheets convey full >> information on functionality). However, the chips remain untested. I >> would be glad to test them as well if you are willing to provide >> samples (I am at a University, so I have access to a lab with equipment for testing). >> >> On Wednesday 10 February 2016 12:18 AM, Victor Lim wrote: >>> Hi, Flashrom team, >>> >>> >>> >>> I am the FAE manager for Gigadevice and would like to know how I can >>> work >> with you to add our part # to your support list. >>> >>> A customer of mine is looking to program our GD25VQ41B with your >>> tool and >> found that it is not supported by your tools. >>> >>> It would like grateful if you can support our entire SPI NOR portfolio. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Victor Lim(Gigadevice/MK IV/FAE Manager) >>> >>> >>> >>> Gigadevice Semiconductor Inc. >>> >>> Tel: 408-855-8336 <tel:408-855-8336> >>> Mobile: 408-883-3856 <tel:408-883-3856> >>> >>> Website: www.gigadevice.com <http://www.gigadevice.com> <http://www.gigadevice.com/> >>> >>> 2975 Bowers Ave,Suite 323 >>> >>> Santa Clara, CA 95051, USA >>> >>> >>> >>> This email was sent to you by GigaDevice, A Global Innovative Memory >> Architect >>> >>> >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> -- >>> >>> The information contained in this e-mail message (and any attachment >> transmitted herewith) is privileged and confidential and is intended >> for the exclusive use of the addressee(s). If you are not an intended >> addressee, any disclosure, reproduction, distribution or other >> dissemination or use of this communication is strictly prohibited. If >> you have received this communication in error, please delete this >> communication and contact us by replying to this e-mail immediately. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> flashrom mailing list >>> flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> >>> http://www.flashrom.org/mailman/listinfo/flashrom >>> >> > > -- > Kind Regards, > Hatim Kanchwala > http://hatimak.me > B. Tech. Electrical Engineering > Indian Institute of Technology Patna > > -- Kind Regards, Hatim Kanchwala http://hatimak.me B. Tech. Electrical Engineering Indian Institute of Technology Patna _______________________________________________ flashrom mailing list flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> https://www.flashrom.org/mailman/listinfo/flashrom -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

2 1

New SPI NOR Flash product Support
by Victor Lim 09 May '16

09 May '16

Hi, Flashrom team, I am the FAE manager for Gigadevice and would like to know how I can work with you to add our part # to your support list. A customer of mine is looking to program our GD25VQ41B with your tool and found that it is not supported by your tools. It would like grateful if you can support our entire SPI NOR portfolio. Regards, Victor Lim(Gigadevice/MK IV/FAE Manager) Gigadevice Semiconductor Inc. Tel: 408-855-8336 Mobile: 408-883-3856 Website: <http://www.gigadevice.com/> www.gigadevice.com 2975 Bowers Ave,Suite 323 Santa Clara, CA 95051, USA This email was sent to you by GigaDevice, A Global Innovative Memory Architect _____ The information contained in this e-mail message (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this communication in error, please delete this communication and contact us by replying to this e-mail immediately.

4 12

Support
by Pera Peric 08 May '16

08 May '16

As instructed, I'm sending an email with verbose parameter included. The chip in question is w25q64fvsig. Also, please advise if something can be done about flashing with the descriptor locked (other than using an external programmer). Best

1 0

[PATCH 1/2] dediprog: Reimplement target chip option
by Nico Huber 07 May '16

07 May '16

Signed-off-by: Nico Huber <nico.huber(a)secunet.com> --- dediprog.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/dediprog.c b/dediprog.c index 019de46..b7276e5 100644 --- a/dediprog.c +++ b/dediprog.c @@ -942,7 +942,7 @@ int dediprog_init(void) int spispeed_idx = 1; int millivolt = 3500; long usedevice = 0; - long target = 1; + long target = FLASH_TYPE_APPLICATION_FLASH_1; int i, ret; spispeed = extract_programmer_param("spispeed"); @@ -1014,7 +1014,18 @@ int dediprog_init(void) free(target_str); return 1; } - msg_pinfo("Using target %li.\n", target); + switch (target) { + case 1: + msg_pinfo("Using target %s.\n", "FLASH_TYPE_APPLICATION_FLASH_1"); + target = FLASH_TYPE_APPLICATION_FLASH_1; + break; + case 2: + msg_pinfo("Using target %s.\n", "FLASH_TYPE_APPLICATION_FLASH_2"); + target = FLASH_TYPE_APPLICATION_FLASH_2; + break; + default: + break; + } } free(target_str); @@ -1073,7 +1084,7 @@ int dediprog_init(void) dediprog_set_leds(LED_ALL); /* Select target/socket, frequency and VCC. */ - if (set_target_flash(FLASH_TYPE_APPLICATION_FLASH_1) || + if (set_target_flash(target) || dediprog_set_spi_speed(spispeed_idx) || dediprog_set_spi_voltage(millivolt)) { dediprog_set_leds(LED_ERROR); -- 2.7.0

2 3

My current libflashrom/layout branch
by Nico Huber 04 May '16

04 May '16

Hi all, this is my current work on layout support and libflashrom. I don't have the time currently to clean it more up / respond to a review, as I will be on vacation for about three weeks. Most things are pretty clean though. So I sent it in, in case anyone wants to look at it or just play with it. One note on layout semantics: It's clear from other patches that there are different concepts of a don't-read-all option. It's either read only the flash parts that are not included (shall be kept intact) or read only those parts that are included (will be changed). I implemented the latter. It's quite useful for systems with a locked ME region.

1 14

GUI for Flashrom in Kodi
by C. Butz 01 May '16

01 May '16

Dear team, Looking for a cheap and reliable flash-programmer, I came across Flashrom and its functionality on Raspberry. In the process of playing around with this combination I discovered Kodi and wrote a GUI for Kodi to use Flashrom there. Source code and additional information can be found @ http://forum.kodi.tv/showthread.php?tid=272150 Let me know if there is any issue with licenses or anything else that requires correction! Thanks & best regards Chris Butz

1 0

Re: [flashrom] Giving to -i option some real use
by Salvador Eduardo Tropea 25 Apr '16

25 Apr '16

Hi Michael: I see your point, and see it can be confusing if the interpretation is changed. What about reading the whole erase regions affected by each interval? (like David points out) I mean this: /** * Look for the starting address of the erase region that contains @addr. * The size of this region is returned in @sz */ int find_page_start(unsigned int addr, struct eraseblock *blocks, unsigned int *sz) { unsigned int page_start, i, size, count, group_size; /* Look for the beggining of the erase region containing start address */ page_start = 0; for (i = 0; i < NUM_ERASEREGIONS; i++) { size = blocks[i].size; count = blocks[i].count; group_size = size * count; if (page_start + group_size > addr) { /* The address is inside one of these erase regions */ *sz = size; return page_start + ((addr - page_start) / size) * size; } else {/* Not here */ page_start += group_size; } } msg_gerr("ERROR: address out of memory!?\n"); exit(1); return -1; } /** * Read all the erase regions containing the @start-@end interval. * Returns the last address fetched in @real_end_p */ int read_pages(struct flashctx *flash, uint8_t *oldcontents, unsigned int start, unsigned int end, unsigned int *real_end_p) { int k; unsigned int real_start, real_end, size; k = find_erase_function(flash); if (k == -1) { msg_gerr("ERROR: No erase function available.\n"); return -1; } real_start = find_page_start(start, flash->chip->block_erasers[k].eraseblocks, &size); msg_gdbg("Start of range 0x%X rounded to page boundary: 0x%X\n", start, real_start); real_end = find_page_start(end, flash->chip->block_erasers[k].eraseblocks, &size); real_end += size - 1; msg_gdbg("End of range 0x%X rounded to page boundary: 0x%X\n", end, real_end); *real_end_p = real_end; return flash->chip->read(flash, oldcontents + real_start, real_start, real_end - real_start + 1); } /** * Fill the @oldcontents buffer with data from the memory. The regions not included by the user are filled * with data from @newcontents instead of the actual memory content. It forces to skip them. * This function is used only when @oldcontents is empty. * Is also mandatory that at least one region was specified by the user. */ int read_cur_content(struct flashctx *flash, uint8_t *oldcontents, const uint8_t *newcontents) { unsigned int start = 0; romentry_t *entry; unsigned int size = flash->chip->total_size * 1024; unsigned int region_end; int ret = 0; /* We will read from memory only the regions indicated by the user. * The rest will contain the same as the newcontents */ memcpy(oldcontents, newcontents, size); /* Catch a missuse */ if (num_include_args == 0) { msg_perr("Internal error! build_old_image() invoked, but no regions specified.\n"); return 1; } /* Non-included romentries are ignored. * The union of all included romentries is fetched from memory. */ while (start < size) { entry = get_next_included_romentry(start); /* No more romentries for remaining region? */ if (!entry) break; /* For included regions, read memory content content. */ msg_gdbg("Read a chunk 0x%06x-0x%06x.\n", entry->start, entry->end); ret = read_pages(flash, oldcontents, entry->start, entry->end, &region_end); if (ret != 0) { msg_gerr("Failed to read chunk 0x%06x-0x%06x.\n", entry->start, entry->end); break; } start = region_end + 1; /* Catch overflow. */ if (!start) break; } return ret; } The find_erase_function() is in flashrom.c and is like this: /* Look for the first valid erase function. Returns -1 if none. */ int find_erase_function(struct flashctx *flash) { int k; msg_cdbg("\nLooking for an erase function.\n"); for (k = 0; k < NUM_ERASEFUNCTIONS; k++) { if (k != 0) msg_cdbg("Looking for another erase function.\n"); msg_cdbg("Trying erase function %i... ", k); if (!check_block_eraser(flash, k, 1)) { msg_cdbg("OK\n"); return k; } msg_cdbg("INVALID\n"); } msg_cdbg("No usable erase functions left.\n"); return -1; } In the case of the range I'm using I get: (with -VV) ... Reading old flash chip contents... Read a chunk 0x000000-0x007e2b. Looking for an erase function. Trying erase function 0... OK Start of range 0x0 rounded to page boundary: 0x0 End of range 0x7E2B rounded to page boundary: 0x7FFF ... In this way we know the content of the blocks that we'll erase. The values look ok, since the first eraser have 4k pages. Note: this code uses the first usable erase function, erase_and_write_flash will try the same eraser. If this eraser fails we will need more data, but in this case erase_and_write_flash reads all the memory again. Regards, SET El 20/04/16 a las 15:23, Michael Karcher escribió: > On 04/20/2016 12:07 PM, Salvador Eduardo Tropea wrote: >> /** >> * Fill the @oldcontents buffer with data from the memory. The regions >> not included by the user are filled >> * with data from @newcontents instead of the actual memory content. >> It forces to skip them. >> * This function is used only when @oldcontents is empty. >> * Is also mandatory that at least one region was specified by the user. >> */ >> >> My intention was to use the same (nasty) tricks that the code already >> uses. By forcing areas to match the rest of the code avoids touching it. > My concern is still valid. The claim "It forces to skip them" appears > wrong. If the area of the new and the old image match, the code tries to > optimize by not touching the area, but there is no guarantee that the > area is indeed untouched. If the old contents of the chip has been read, > flashrom "hides" the fact that it touched an area that did not need to > be touched by reflashing the old contents after erasing. This hiding > breaks down if flashrom doesn't know the real contents. > > Here is an example of what I mean: Assume a flash chip containing four > nibbles (used instead of bytes for presentation purposes; nibbles are > represented in hex digits); the chip contains two independently erasable > areas of two nibbles each, and I use a layout file like this (the erased > state is the nibble value F). > > 0:2 please_flash > 3:3 please_keep > > Assume the flash chip contains 0127, and the new image contains 1230. > Without -A, and selecting the image "please_flash" the following steps > are taken: > > 1) The file is loaded, newcontents is "1230". > 2) ROM contents are read. oldcontents is "0127" > 3) build_new_image/modify_new_image_from_old copies the last nibble from > oldcontents to newcontents, because it is in "please_keep", not in > "please_flash". newcontents is now "1237" > 4) The first two nibbles are erased, because the old value "01" does not > match "12". Now they are "FF" > 5) The first two nibbles are programmed to "12" > 6) The second *two* nibbles are erased because "27" does not match "37". > Now they are "FF" > 7) The second two nibbles are programmed to "37". > The flash chip now contains 1237. > > With -A, the following steps are taken: > > 1) The file is loaded, newcontents is "1230" > 2) read_cur_content loads the first three nibbles from the flash memory, > and takes the last one from newcontents. oldcontents is "0120". > 3) The first two nibbles are erased, because the old value "01" does not > match "12". Now they are "FF" > 4) The first two nibbles are programmed to "12" > 5) The second *two* nibbles are erased because "20" does not match "30". > Now they are "FF" > 6) The second two nibbles are programmed to "30". > The flash chip now contains 1230. > > As you see, the last nibble is modified to "0" instead of being kept at > "7". There might be situations in which it doesn't matter that a nibble > outside of the requested area is changed, but it definitely is different > from how we handled layout files and partial flashing up to now. Note > especially how copying the last nibble (the zero with -A, the 7 without > -A) from newcontents to oldcontents did not force the nibble to be > untouched in either case, but in the first case flashrom knew what to > write so the 7 appears to be unmodified while in fact it was erased and > rewritten. > > Regards, > Michael Karcher > -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

3 4

Results of "flashrom -V -p internal" on Dell Optiplex 9010
by Przemek Klosowski 25 Apr '16

25 Apr '16

flashrom v0.9.7-r1850 on Linux 4.3.5-300.fc23.x86_64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.3.1, GCC 5.1.1 20150612 (Red Hat 5.1.1-3), little endian Command line (3 args): flashrom -V -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 3871M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 997 us, 10000 myus = 9977 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. Using External DMI decoder. DMI string chassis-type: "Mini Tower" DMI string system-manufacturer: "Dell Inc." DMI string system-product-name: "OptiPlex 9010" DMI string system-version: "01" DMI string baseboard-manufacturer: "Dell Inc." DMI string baseboard-product-name: "0M9KCM" DMI string baseboard-version: "A00" Found chipset "Intel Q77" with PCI ID 8086:1e47. 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... Root Complex Register Block address = 0xfed1c000 GCS = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 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 enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x0a: BIOS Lock Enable: enabled, BIOS Write Enable: disabled Warning: Setting Bios Control at 0xdc from 0x0a to 0x09 failed. New value is 0x0a. SPIBAR = 0x00007f9404c22000 + 0x3800 0x04: 0xe009 (HSFS) HSFS: FDONE=1, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 Warning: SPI Configuration Lockdown activated. Reading OPCODES... done 0x06: 0x0004 (HSFC) HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0 0x50: 0x00000a0b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x0a, BRRA 0x0b 0x54: 0x00000000 FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x0bff0600 FREG1: BIOS region (0x00600000-0x00bfffff) is read-write. 0x5C: 0x05ff0005 FREG2: Warning: Management Engine region (0x00005000-0x005fffff) is locked. 0x60: 0x00040001 FREG3: Gigabit Ethernet region (0x00001000-0x00004fff) is read-write. 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). 0x90: 0xc0 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xf84010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=0 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05200302 (OPMENU) 0x9C: 0x0000019f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x00802005 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x00002005 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x00000800 (FPB) Enabling hardware sequencing due to multiple flash chips detected. PROBLEMS, continuing anyway The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Found 2 attached SPI flash chips with a combined density of 12288 kB. The flash address space (0x000000 - 0xbfffff) is divided at address 0x800000 in two partitions. The first partition ranges from 0x000000 to 0x7fffff. In that range are 2048 erase blocks with 4096 B each. The second partition ranges from 0x800000 to 0xbfffff. In that range are 1024 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000. 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 Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 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 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, 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 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, 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 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, 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 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, 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: 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 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, 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 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific). No operations were specified. Restoring MMIO space at 0x7f9404c258a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom