May 2016 - flashrom - mail.coreboot.org

Re: [flashrom] New SPI NOR Flash product Support
by Stefan Tauner Aug. 15, 2019

Aug. 15, 2019

On Mon, 9 May 2016 20:46:18 -0700 David Hendricks <dhendrix(a)google.com> wrote: > Hi Victor, > From Flashrom's software perspective all chips with the same ID are > indistinguishable. > > Part number often includes characteristics such as package and thermal > tolerance which do not affect software compatibility. However, we will add the new names to the in-program (and hence wiki) database so that this new information becomes public. Thanks for the heads up, Victor. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 4

80/100/132 column line width policy
by Carl-Daniel Hailfinger Dec. 14, 2018

Dec. 14, 2018

Hi, we're hitting the 80 column limit in our code in ways which actually reduce readability for the code. Examples are various multiline messages and complicated nested code where refactoring to a separate function doesn't make sense. Keeping the old 80 column limit is not really an option anymore. Standard terminal sizes have one of 80, 100 or 132 columns. Given the monitor resolutions many people have nowadays, I think it is safe to say that you can fit two xterms with 100 columns horizonally next to each other. 100 columns should also be sufficient for a msg_p* of roughly 80 columns of text. 132 columns provide more leeway, but IMHO that would be too wide for good readability (and my screen can't fit two xterms side-by-side anymore). Of course some files have sections where any column limit is not acceptable (board lists etc.), but the column limit violations should be limited to the affected file sections, not whole files. Comments? I'd like to get this decided today or tomorrow so we know where we need line breaks in Stefan Tauner's new struct flashchip patch. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 9

Spansion S25FL128P......X
by The Raven April 24, 2017

April 24, 2017

I have a spansion S25FL128P......X chip and can do some tests. The "problem" is that i don't know if its an 0 or an 1. On the chip i see only "FL128PIF" and one line lower i see "00299012 C". Probing works (id1 0x01, id2 0x2018): Calibrating delay loop... OK. serprog: Programmer name is "serprog-duino" Found Spansion flash chip "S25FL128P......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128P......1" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128S......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128S......1" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL129P......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL129P......1" (16384 kB, SPI) on serprog. Multiple flash chip definitions match the detected chip(s): "S25FL128P......0", "S25FL128P......1", "S25FL128S......0", "S25FL128S......1", "S25FL129P......0", "S25FL129P......1" Please specify which chip definition to use with the -c <chipname> option. BTW: Chip was fund on a Dell-Systemboard.

3 6

Re: [flashrom] Ideas for implementing support for 2nd status register
by Hatim Kanchwala June 12, 2016

June 12, 2016

On Sunday 29 May 2016 02:40 PM, David Hendricks wrote: > Hi Hatim, > Interesting approach. It seems to work well for pretty printing, though > I am curious how this will translate into ranges. Do you have an example > for translating status_register_layout structs to a range of bytes > protected, for example 0x000000-0x1fffff? Hi, I have been researching and developing ideas on how to go about block protection. A lot of this is based on Chromium OS' implementation. Here are the two models I have. Before diving into the models themselves, here's idea that both models share. We define a struct range (just like Chromium OS) and then define an array struct range range[32]. We use the BP bitfield as indexes into the array - so a combination of BP4=0, BP3=0, BP2=1, BP1=0, BP0=1 gives a bitfield 0x05 and corresponding range is given by range[0x05]={start, len}. (32 because we have seen a maximum of 5 block protect bits so that is 2^5 = 32 combinations.) The obvious advantage is that status_to_range operations will happen in O(1) time. IMO, the use cases of reading the status register and translating BP bitfields into range are more than vice-versa. So IMHO having an array of ranges indexed by bitfield will certainly be more helpful. You will see that the two approaches differ in the implementation of this idea. 1. Block Protection Table The driving idea behind this model is to have a representation of block protection table in flashrom very similar to what is given in datasheets (just like Chromium OS currently has). But if we are to use array of ranges indexed by bitfield as per above idea, then we need to process this representation first. I came up with the following algorithm for translating the table into the range array - translate_table_to_range(table): proc = [] done = [] for row in table proc.append(row) while proc is not empty tmp = proc.pop(0) for i = 0:5 if tmp.bp[i] is X new = tmp new.bp.replace(i, 0) proc.append(new) new.bp.replace(i, 1) proc.append(new) break if i is 5 done.append(tmp) for row in done index = row.bp4 << 4 | row.bp3 << 3 | row.bp1 << 1 |row.bp0 range[index] = row.range These were the few questions came up immediately - - When do we call such a function in the code? Flashrom will always probe before performing any operation. So once the chip is found, we fetch the BP table from the struct flashchip, call this function, store the array of ranges, and then perform all future operations for that run using the array. - Do we call it for all the chips? IMO, calling this for all chips is a bad idea and the above answer makes this redundant. - How to handle corner cases? This needs to be dealt with still. 2. Array of Range This model is very simple compared to #1 - instead of any such processing, we simply represent the BP table in the form of an array of ranges in the first place. This might make representing the table in flashrom more cumbersome. Attached is a prototype of the two models (both implementations are combined in the same file). I have extensively annotated the code to better convey the models defined above. The output is available here http://paste.flashrom.org/view.php?id=2921. Chromium implementation defines two separate structs from CMP=0 and CMP=1. This case can be handled automatically. IMO, #2 is better than #1 and we should go forward with #2. The additional processing step that needs to be taken in #1 before array of ranges is available is what made me favour #2. I would like to hear your take on all this, particularly use cases (I could come up with only one or two, so please tell me more). There's a lot of comments in the code, so please go through those as well. I am also wondering if it is possible to get the best of both #1 and #2 - is there a way to pre-process the BP Table into the array of ranges representation at the time of compilation itself for all chips? This would eliminate the additional step at runtime, and would make representation in the code easier. Personally, I had a lot of fun implementing #1 mainly because it was a direct materialization of the algorithm and data structures theory I had in my course. I had started out developing my own data structures but then stopped mid-way and realized I should be looking for standard solutions. Then I found sys/queue.h. So, that was a nice learning experience! Looking forward to your comments and feedback. Thanks for your time and patience. Bye, Hatim

2 1

ASRock X99 WS-E BIOS backup fail
by Luis Tirado May 30, 2016

May 30, 2016

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 May 29, 2016

May 29, 2016

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 May 27, 2016

May 27, 2016

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 May 25, 2016

May 25, 2016

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 李晓伟 May 25, 2016

May 25, 2016

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 May 24, 2016

May 24, 2016

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