flashrom January 2018

flashrom@flashrom.org

26 participants
45 discussions

ERASE FAILED on Macronix Bios Chip x220 (Expected 0xff, Found=0x5a)

by The_Raven Raven

I had similar problems. See here: https://www.mail-archive.com/flashrom@flashrom.org/msg13042.html To keep a long story short: As i can remember, i had 4 chips, 2 working and 2 not working. Dont know why. Option 1: Parts of the chip is write protected Option 2: Chip is broken. BTW: Strange "spispeed". Try with "30000"

2 years, 10 months

ERASE FAILED on Macronix Bios Chip x220 (Expected 0xff, Found=0x5a)

by realraw＠tuta.io

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!

2 years, 10 months

AT45DB081D Chip tested -> OK

by The_Raven Raven

Hi I have tested Chip "AT45DB081D" (found on a NIC). Chip works fine. Test Steps: - Read - Erase - Written Data1 - Written Data2 (overwritten) Data1 and Data2 generated with "dd" from "/dev/urandom". Greets

2 years, 10 months

Re: [flashrom] Flashing a Winbond W25Q64FV using a RaspberrPI still fails

by Nico Huber

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 > parameter. 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. Nico

2 years, 10 months

Flashing a Winbond W25Q64FV using a RaspberrPI still fails

by The_Raven Raven

I think this is a bug with debian 9, with debian 8 it works without this parameter. Searched a long time for this solution, finally i found this report which helps me: https://github.com/flashrom/flashrom/issues/29 Now i see that Nico changed it in the wiki. -> https://flashrom.org/RaspberryPi Thanks! Too bad he changed it not a week ago, that would have me much time saved. ;-) Think you can change it from 1000 to 30000 because it is much much faster and works stable. Greets

2 years, 10 months

Flashing a Winbond W25Q64FV using a RaspberrPI still fails

by Mamoru Inugami

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 !

2 years, 10 months

Flashing a Winbond W25Q64FV using a RaspberrPI still fails

by The_Raven Raven

This is a problem (Bug) of raspi. Try this command: flashrom -V -p linux_spi:dev=/dev/spidev0.0,spispeed=30000

2 years, 10 months

Flashing a Winbond W25Q64FV using a RaspberrPI still fails

by Mamoru Inugami

Hi, I try to flash Winbond W25Q64FV via Raspberry Pi 3. Datasheet : http://www.alldatasheet.com/datasheet-pdf/pdf/555558/WINBOND/W25Q64FV.html It fails the same as 2016 post, "Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI)." https://mail.coreboot.org/pipermail/flashrom/2016-March/014548.html The attached file is output of flashrom 1.0 with -o option. If you have any help, please inform me.

2 years, 10 months

Flashing MX 25L12873F on MSI board via Raspberry Pi SPI

by Fabian Köster

Hello list, I recently tried to update the BIOS of my MSI H87-G43 [1] 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 anymore. 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 [2]. 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 [3], but it is not listed as supported on [4], 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 [5] 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! Regards Fabian [1] https://de.msi.com/Motherboard/H87-G43.html [2] https://forum-en.msi.com/index.php?topic=289550.0 [3] http://www.bios-chip24.com/MXIC-MX-25L12873F-M2I-10G-128MBit-SPI-Flash-SOIC… [4] https://www.flashrom.org/Supported_hardware [5] https://www.flashrom.org/MSI_JSPI1

2 years, 10 months

CrOS flashrom compatibility and upstreaming of CrOS features

by Nico Huber

Hey folks, during review of commits that port per-region file arguments [1] 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 script. 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 C program. 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 ;) Nico [1] 23021, 23022 and related 23353 in https://review.coreboot.org/

2 years, 10 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom January 2018