flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Thinkpad T410s failed to erase (corrupted?)
by Sea Wright 29 Dec '18

29 Dec '18

Hi all, While trying to get coreboot working on a T410s, in the most recent flash (after multiple working successful flashes) the clip detached in the middle of the write process. I saw some error message briefly (I think it mentioned corrupted) before my ssh session terminated before I could finish reading it. Now, with a new clip, I can read the chip perfectly, but trying to write/erase leads to these errors: https://paste.flashrom.org/view.php?id=3156 Failed at 0x0000000010! Expected=0xff, Found=0x5a, failed byte count from 0x00000000-0x007fffff: 0x3dc7fe It is possible to write what is read from the chip (eh cock doesn't match what I tried to write to it) back onto it without failure. Any suggestions? menaechmi

2 1

Report of flashrom failure (Intel DQ67OW motherboard)
by Tom Crane 28 Dec '18

28 Dec '18

Dear Flashrom developers, Please find attached my failure report as suggested in flashrom O/P. The PC has been updated with the latest BIOS (file SWQ6710H.86A.0070.BI.zip from Intel) and I am running a built-today git version of flashrom. Thanks Tom Crane

2 1

Testing new mailing list
by Carl-Daniel Hailfinger 25 Dec '18

25 Dec '18

Test

1 0

Re: [flashrom] 80/100/132 column line width policy
by Nico Huber 23 Dec '18

23 Dec '18

On 19.12.18 20:34, David Hendricks wrote: > Regarding exceptions, I was taught that function signatures in header >> files are an exception too. I don't mind either way, but if the rules >> disagree with the current practice, we should make that explicit. >> > > This makes sense, but can linters be taught the difference between source > and header files? It would be nice to enforce the hard limit via commit > hook. I wouldn't mind a commit hook as long as a human has the last word. If linters can be taught? I'm sure they can if they are open-source. Maybe I don't get the question. Nico

1 0

Re: [flashrom] Please Help
by Nico Huber 23 Dec '18

23 Dec '18

Hello Ben, I've been looking at your mail again and what looked like a hardware failure first, obviously isn't: > Some block protection in effect, disabling... Block protection could not be > disabled! (Alas, error messages can somehow be missed in verbose logs...) This is likely caused by a wrong state on a /WP pin. It should be high, deasser- ted. Hope that helps, Nico

1 0

Cleanup patches for flashrom
by Richard Hughes 20 Dec '18

20 Dec '18

Hi all, We're slowly moving towards using libflashrom in fwupd, rather than exec'ing the flashrom binary and screen scraping. So that it can be consumed by users easily, I'm tempted to use flashrom as a subproject to the fwupd project rather than waiting for distros to ship any new bleeding edge version of flashrom to users. To make some of that possible, I've fixed up a few of the CI failures we would see in fwupd, which I've filed as a PR here: https://github.com/flashrom/flashrom/pull/67 If a GitHub PR isn't how you want these kind of general patches please let me know. One person already told me that I needed to use Gerrit, but I'm not overly keen on learning a new process if I can avoid it. Feedback welcome, thanks. Richard

1 0

Re: [flashrom] 80/100/132 column line width policy
by Nico Huber 19 Dec '18

19 Dec '18

Hi, Am 15.12.18 um 02:49 schrieb David Hendricks: > This topic came up in a patch submission, and it occurred to me that we > never actually wrote down canonical limits in the wiki. So I went ahead and > added the proposed limits here: > https://www.flashrom.org/Development_Guidelines#Coding_style thanks, this was bugging me for long, but I didn't know when it was discussed. > > It seems that we never really decided on 112-characters vs. 120-characters, > so I wrote down 112-characters for now. I guess time decided. 112 chars feels more than enough, IMHO. > At least most were satisfied with > an 80-column "soft" limit and an exception to the limits for tables... Regarding exceptions, I was taught that function signatures in header files are an exception too. I don't mind either way, but if the rules disagree with the current practice, we should make that explicit. Actually, I can't recall ever hearing about a soft limit. Though, I like the idea. I tried to formalize something like that once with the notion of a "visible width" during a [coreboot] discussion. Quoting myself here in case somebody is interested: > [...] I see three > major cases that people care about: > > 1. Function signatures, > 2. Code lines and > 3. Code lines containing string literals[1]. > > Let's assume 72 chars of visible width (line length minus the inden- > tation) is enough for code lines. If we say two additional indentation > levels are always reasonable (a third might be too, here and there) we > would be at 96 chars. > > So I would compromise as follows: > > o Set a hard limit around 100 chars (96 would be a nice number). > o If a line doesn't contain a string literal, recommend a > visible width <= 72 chars. > > Nico > > [1] I think we should treat the latter two separately because you can > easily argue that lines with a string literal might get too long but > if you apply the same rules to regular code, you'll get all the > crappy stuff (too many levels of indentation, unnecessary long, less > distinctive identifiers etc.). Full message here[2]. That would only apply to the bulk of the code and comments. For me, carefully hand-formatted passages (like tables) are always an exception. Nico [2] https://mail.coreboot.org/pipermail/coreboot/2018-May/086834.html

2 1

80/100/132 column line width policy
by Carl-Daniel Hailfinger 15 Dec '18

15 Dec '18

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

reporting a failed verify
by Joy 08 Dec '18

08 Dec '18

sudo flashrom --programmer ch341a_spi -w 2ndpad_NVRAM.rom flashrom v0.9.9-rc1-r1942 on Linux 4.4.0-62-lowlatency (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x000a01a1! Expected=0x8c, Found=0x8e, failed byte count from 0x00000000-0x007fffff: 0x7e Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks!

1 0

Please Help
by Benjamin Murdock 05 Dec '18

05 Dec '18

I am trying to duplicate the audio stored on a GPR25L040B chip. The datasheet ( https://www.dataman.com/media/datasheet/Generalplus/GPR25L040B.pdf) states that it is fully compatible with the MX25L4005A. I seem to be able to read the flash to a file just fine but when writing back to the file I am getting an error (see below). Even with the error, I seem to be able to at least partially write to the chip but the audio that comes back cuts out after a few seconds. This project's goal is to copy audio from a recorded book that my son's grandma recorded with him before she passed, to another book that we can give to my Sister-In-Law for Christmas. I would also like to back up the audio in case something happens to the book in the future. (Alternate backups will be made as well prior to touching that book.) . Any help that you can provide would be greatly appreciated. Thank you, Ben. The following protocols are supported: SPI. Probing for Macronix MX25L4005(A/C)/MX25L4006E, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2013 Found Macronix flash chip "MX25L4005(A/C)/MX25L4006E" (512 kB, SPI) on linux_spi. Chip status register is 0x86. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is set Chip status register: Bit 6 is not set Chip status register: Bit 5 is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is set Chip status register: Write In Progress (WIP/BUSY) is not set Some block protection in effect, disabling... Block protection could not be disabled! Chip status register is 0x86. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is set Chip status register: Bit 6 is not set Chip status register: Bit 5 is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is set Chip status register: Write In Progress (WIP/BUSY) is not set Reading old flash chip contents... done. Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:S, 0x001000-0x001fff:S, 0x002000-0x002fff:S, 0x003000-0x003fff:S, 0x004000-0x004fff:S, 0x005000-0x005fff:S, 0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S, 0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:S, 0x00c000-0x00cfff:S, 0x00d000-0x00dfff:S, 0x00e000-0x00efff:S, 0x00f000-0x00ffff:S, 0x010000-0x010fff:S, 0x011000-0x011fff:S, 0x012000-0x012fff:S, 0x013000-0x013fff:S, 0x014000-0x014fff:S, 0x015000-0x015fff:S, 0x016000-0x016fff:S, 0x017000-0x017fff:S, 0x018000-0x018fff:S, 0x019000-0x019fff:S, 0x01a000-0x01afff:S, 0x01b000-0x01bfff:S, 0x01c000-0x01cfff:S, 0x01d000-0x01dfff:S, 0x01e000-0x01efff:S, 0x01f000-0x01ffff:S, 0x020000-0x020fff:S, 0x021000-0x021fff:S, 0x022000-0x022fff:S, 0x023000-0x023fff:S, 0x024000-0x024fff:S, 0x025000-0x025fff:S, 0x026000-0x026fff:S, 0x027000-0x027fff:S, 0x028000-0x028fff:S, 0x029000-0x029fff:S, 0x02a000-0x02afff:S, 0x02b000-0x02bfff:S, 0x02c000-0x02cfff:S, 0x02d000-0x02dfff:S, 0x02e000-0x02efff:S, 0x02f000-0x02ffff:S, 0x030000-0x030fff:S, 0x031000-0x031fff:S, 0x032000-0x032fff:S, 0x033000-0x033fff:S, 0x034000-0x034fff:S, 0x035000-0x035fff:S, 0x036000-0x036fff:S, 0x037000-0x037fff:S, 0x038000-0x038fff:S, 0x039000-0x039fff:S, 0x03a000-0x03afff:S, 0x03b000-0x03bfff:S, 0x03c000-0x03cfff:S, 0x03d000-0x03dfff:S, 0x03e000-0x03efff:S, 0x03f000-0x03ffff:S, 0x040000-0x040fff:S, 0x041000-0x041fff:S, 0x042000-0x042fff:S, 0x043000-0x043fff:S, 0x044000-0x044fff:S, 0x045000-0x045fff:S, 0x046000-0x046fff:S, 0x047000-0x047fff:S, 0x048000-0x048fff:S, 0x049000-0x049fff:S, 0x04a000-0x04afff:S, 0x04b000-0x04bfff:S, 0x04c000-0x04cfff:S, 0x04d000-0x04dfff:S, 0x04e000-0x04efff:S, 0x04f000-0x04ffff:S, 0x050000-0x050fff:S, 0x051000-0x051fff:S, 0x052000-0x052fff:S, 0x053000-0x053fff:S, 0x054000-0x054fff:S, 0x055000-0x055fff:S, 0x056000-0x056fff:S, 0x057000-0x057fff:S, 0x058000-0x058fff:S, 0x059000-0x059fff:S, 0x05a000-0x05afff:S, 0x05b000-0x05bfff:S, 0x05c000-0x05cfff:S, 0x05d000-0x05dfff:S, 0x05e000-0x05efff:S, 0x05f000-0x05ffff:S, 0x060000-0x060fff:S, 0x061000-0x061fff:S, 0x062000-0x062fff:S, 0x063000-0x063fff:S, 0x064000-0x064fff:S, 0x065000-0x065fff:S, 0x066000-0x066fff:S, 0x067000-0x067fff:S, 0x068000-0x068fff:S, 0x069000-0x069fff:S, 0x06a000-0x06afff:S, 0x06b000-0x06bfff:S, 0x06c000-0x06cfff:S, 0x06d000-0x06dfff:S, 0x06e000-0x06efff:S, 0x06f000-0x06ffff:S, 0x070000-0x070fff:S, 0x071000-0x071fff:S, 0x072000-0x072fff:S, 0x073000-0x073fff:S, 0x074000-0x074fff:S, 0x075000-0x075fff:EFAILED at 0x00075000! Expected=0xff, Found=0x89, failed byte count from 0x00075000-0x00075fff: 0xf3f ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:EFAILED at 0x00070000! Expected=0xff, Found=0x40, failed byte count from 0x00070000-0x0007ffff: 0x79ab ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 2... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:EFAILED at 0x00070000! Expected=0xff, Found=0x00, failed byte count from 0x00070000-0x0007ffff: 0x79ab ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 3... 0x000000-0x07ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0007ffff: 0x3a0c2 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 4... 0x000000-0x07ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0007ffff: 0x3a0c2 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 5... not defined. Looking for another erase function. Trying erase function 6... not defined. Looking for another erase function. Trying erase function 7... not defined. 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) between the programmer and the flash chip. If you think the error is caused by flashrom please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks!

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom