After having tried all 4 options of flashchips on my bios, they will all fail to erase and then finally write the new Coreboot ROM I've compiled.
I have changed power sources, methods of powering the Pi3, as well as all the different SPI speeds.
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) on linux_spi.Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on linux_spi.Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on linux_spi.Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E" (8192 kB, SPI) on linux_spi.Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E"
I noticed while Googling flashrom troubleshooting it said something about 'turning write-protection
off'. I have absolutely no issues reading the BIOS, and I have md5sum checked it multiple times and they all give the same reading. It seems as if something else is missing that's not allowing the chip to be erased.
Here is a log I've included from one of the many failed attempts:
flashrom v0.9.9-r1954 on Linux 4.9.77-v7+ (armv7l)flashrom was built with libpci 3.3.1, GCC 5.3.1 20160205, little endianCommand line (8 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w /home/pi/coreboot/coreboot.rom -c MX25L6406E/MX25L6408E -o logfile.txtCalibrating delay loop... OS timer resolution is 1 usecs, 595M loops per second, 10 myus = 11 us, 100 myus = 100 us, 1000 myus = 998 us, 10000 myus = 10035 us, 4 myus = 5 us, OK.Initializing linux_spi programmerUsing device /dev/spidev0.0Using 4096 kHz clockThe following protocols are supported: SPI.Probing for Macronix MX25L6406E/MX25L6408E, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on linux_spi.Chip status register is 0x00.Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not setChip status register: Bit 6 is not setChip status register: Block Protect 3 (BP3) is not setChip status register: Block Protect 2 (BP2) is not setChip status register: Block Protect 1 (BP1) is not setChip status register: Block Protect 0 (BP0) is not setChip status register: Write Enable Latch (WEL) is not setChip status register: Write In Progress (WIP/BUSY) is not setThis chip may contain one-time programmable memory. flashrom cannot readand may never be able to write it, hence it may not be able to completelyclone the contents of this chip (see man page for details).Block protection is disabled.Reading old flash chip contents... done.Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:EFAILED at 0x00000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x00000fff: 0xe8ERASE FAILED!Reading current flash chip contents... done. Looking for another erase function.Trying erase function 1... 0x000000-0x00ffff:EFAILED at 0x00000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x0000ffff: 0x299dERASE FAILED!Reading current flash chip contents... done. Looking for another erase function.Trying erase function 2... 0x000000-0x00ffff:EFAILED at 0x00000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x0000ffff: 0x299dERASE FAILED!Reading current flash chip contents... done. Looking for another erase function.Trying erase function 3... 0x000000-0x7fffff:EFAILED at 0x00000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x007fffff: 0x5d0197ERASE FAILED!Reading current flash chip contents... done. Looking for another erase function.Trying erase function 4... 0x000000-0x7fffff:EFAILED at 0x00000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x007fffff: 0x5d0197ERASE 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.Please check the connections (especially those to write protection pins) betweenthe programmer and the flash chip. If you think the error is caused by flashromplease report this on IRC at chat.freenode.net (channel #flashrom) ormail flashrom(a)flashrom.org, thanks!
I have tested Chip "AT45DB081D" (found on a NIC).
Chip works fine.
- Written Data1
- Written Data2 (overwritten)
Data1 and Data2 generated with "dd" from "/dev/urandom".
On 26.01.2018 08:41, The_Raven Raven wrote:
> I think this is a bug with debian 9, with debian 8 it works without this
The only bug here is that flashrom doesn't choose a default by itself
(or that we didn't tell people to set spispeed= from the very begin-
ning). Currently, flashrom just leaves whatever the hardware is con-
figured to, which may still work for different setups. You just don't
know, and it works less likely now.
So, patches are welcome.
I think this is a bug with debian 9, with debian 8 it works without this
Searched a long time for this solution, finally i found this report
which helps me:
Now i see that Nico changed it in the wiki. ->
Too bad he changed it not a week ago, that would have me much time
Think you can change it from 1000 to 30000 because it is much much
faster and works stable.
Thank you for your reply.
I tried your suggestion, I could ientify my chip !
Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1
0xef, id2 0x16
Found Winbond flash chip "W25Q64.W" (8192 kB, SPI).
Thank you for your kindly helps !
I recently tried to update the BIOS of my MSI H87-G43  from an usb
disk using the "M-Flash" method. The update seemed to have succeeded,
but now the board does not do anything at bootup anymore. No screen
output, no beeping. At first, one of the LEDs (i guess HDD activity)
blinked periodically, but after a few restarts it does not even do that
After doing some research I found some guides abouting flashing the bios
chip from outside. One article especially captured my interest, which
described how to access the flash chip via the JSPI1 header on the
mainboard from a Raspberry Pi .
I followed that guide, but I cannot manage to get a connection to the
chip. I found out the used chip is a MX 25L12873F , but it is not
listed as supported on , does this mean it will not work with Flashrom?
Or is maybe something wrong with my wiring? In contrast to the
description of the JSPI1 MSI connector on  the connector on my board
has 12 pins, so I was a little bit confused.
I am new to this topic and very thankful for any help!
during review of commits that port per-region file arguments  from
CrOS flashrom over here, we ran into a discussion about the command line
interface changes. The basic question that arose is
Do we want to maintain full CLI compatibility to CrOS flashrom?
This would have the upside, that it would ease remerging of the two
flashrom versions (in some unknown future). And anybody currently
using CrOS flashrom could transition more smoothly. OTOH, depending on
how the compatibility is achieved, it might increase the costs for
review and development heavily (for a project with 0 spare resources).
To not have to discuss this each and every time when some non-trivial
feature is ported over from CrOS, I'd like to have some opinions, how
valuable CLI compatibility is to you all and how we want to achieve it.
I have currently some alternative ideas in mind that I'll sketch below.
Feel free to add other ideas or just to comment them.
1) Integrate CLI changes from CrOS into flashrom proper's CLI.
This turned out to be much harder than one might initially think:
For the mentioned patches, it means that a lot of additional deve-
lopment has to happen:
* Restore internal behaviour in flashrom that became incompatible.
* Add appropriate sanity checks for the arguments passed (yes,
flashrom proper does such).
* Discuss and review the additional code, too.
It also restricts us to the design choices already made for CrOS
flashrom and makes our review process kind of mindless.
It does, however, get the job done, and everybody could just run
`make` and wouldn't have to care if he's using one version of
flashrom or the other.
2) Design our own interface for flashrom proper, but keep internal
compatibility for an alternate CLI.
It would allow us to make our own design choices at the interface
level. A steady implementation might be much easier to accomplish
if we keep things simple.
Somebody would have to maintain an additional, CrOS compatible CLI.
We could be more lax regarding to sanity checks in the alternate
CLI, to speed up development.
But, everybody already familiar with the CrOS flashrom CLI might
get confused until he finds the alternative CLI.
3) Design our own implementation; provide compatibility with a wrapper
The basic function of flashrom should be clear: read, write or
verify the contents of a flash chip. Everything else (like com-
bining multiple files in complex ways) shouldn't add unnecessary
complexity to flashrom, and can likely be done in cleaner ways
with other tools. In other words, we could try to keep flashrom
more like a UNIX tool.
IMHO, this would allow us to get new features in faster. If some-
body sees a better way to implement a feature, we can just do it.
Writing a wrapper script seems much easier too me than main-
taining compatibility and safety in an unnecessary complex
Same as 2), people used to the other interface would have to learn
a new one (or use the wrapper).
So please let me know what you think, folks ;)
 23021, 23022 and related 23353 in https://review.coreboot.org/