flashrom February 2015

flashrom@flashrom.org

30 participants
77 discussions

Start a nNew thread

FAILED
by roberto.russo＠x-akseli.fi 12 Feb '15

12 Feb '15

Hi, I've just tried using flashrom on my mb Intel HM65.

1 0

ANNOUNCE: flashrom 0.9.8-rc1 is out - please test!
by Stefan Tauner 12 Feb '15

12 Feb '15

Hello everyone, we have published a release candidate for flashrom 0.9.8 yesterday and plan to do the final release of 0.9.8 at the end of February. You can find a (currently) preliminary summary of changes since 0.9.7 here: http://flashrom.org/Flashrom/0.9.8 The respective status of hardware support is listed here: http://flashrom.org/Flashrom/0.9.8/Supported_Hardware Thanks to everybody contributing to the development of flashrom! Please consider testing your previously and newly supported hardware with the release candidate to find regressions and newly introduced bugs before the stable release, thank you. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[commit] r1884 - tags/0.9.8-rc1
by repository service 11 Feb '15

11 Feb '15

Author: stefanct Date: Wed Feb 11 23:30:30 2015 New Revision: 1884 URL: http://flashrom.org/trac/flashrom/changeset/1884 Log: Tag flashrom 0.9.8-rc1. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Added: tags/0.9.8-rc1/ - copied from r1883, trunk/

1 0

[commit] r1883 - trunk
by repository service 11 Feb '15

11 Feb '15

Author: stefanct Date: Wed Feb 11 23:21:03 2015 New Revision: 1883 URL: http://flashrom.org/trac/flashrom/changeset/1883 Log: Increase flashrom version number to 0.9.8-rc1. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Tue Feb 10 09:03:10 2015 (r1882) +++ trunk/Makefile Wed Feb 11 23:21:03 2015 (r1883) @@ -386,7 +386,7 @@ # will not require subversion. The downloadable snapshots are already exported. SVNVERSION := $(shell ./util/getrevision.sh -u 2>/dev/null ) -RELEASE := 0.9.7 +RELEASE := 0.9.8-rc1 VERSION := $(RELEASE)-$(SVNVERSION) RELEASENAME ?= $(VERSION)

1 0

Re: [flashrom] Flashrom Bug for MX25L6405(D) parts
by Stefan Tauner 11 Feb '15

11 Feb '15

On Wed, 11 Feb 2015 17:38:52 +0000 "McMurtrey, Reggie (GE Intelligent Platforms, US)" <reggie.mcmurtrey(a)ge.com> wrote: > Looks like a bug in flashchips.c relating to the MX25L6405(D) chip. The first entry in the .block_erasers array seems to be wrong. > > Currently it is: > > .block_erasers = > { > { > .eraseblocks = { {64 * 1024, 128} }, > .block_erase = spi_block_erase_20, > }, { > […] Thanks for noticing. The block partitioning shown is correct for the 6405 w/o the D suffix. That is what was added originally to flashrom. Later someone (probably myself) has changed the name to include (D) because they share the same RDID, but as you correctly state... the 6405D is erased in (the usual) 4kB-sized blocks with the 0x20 opcode. I have corrected the situation by splitting the definition into two with correct details. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Flashrom Bug for MX25L6405(D) parts
by McMurtrey, Reggie (GE Intelligent Platforms, US) 11 Feb '15

11 Feb '15

Looks like a bug in flashchips.c relating to the MX25L6405(D) chip. The first entry in the .block_erasers array seems to be wrong. Currently it is: .block_erasers = { { .eraseblocks = { {64 * 1024, 128} }, .block_erase = spi_block_erase_20, }, { .eraseblocks = { {64 * 1024, 128} }, .block_erase = spi_block_erase_d8, }, { .eraseblocks = { {8 * 1024 * 1024, 1} }, .block_erase = spi_block_erase_60, }, { .eraseblocks = { {8 * 1024 * 1024, 1} }, .block_erase = spi_block_erase_c7, } }, I believe it should be: .block_erasers = { { .eraseblocks = { {4 * 1024, 2048} }, .block_erase = spi_block_erase_20, }, { .eraseblocks = { {64 * 1024, 128} }, .block_erase = spi_block_erase_d8, }, { .eraseblocks = { {8 * 1024 * 1024, 1} }, .block_erase = spi_block_erase_60, }, { .eraseblocks = { {8 * 1024 * 1024, 1} }, .block_erase = spi_block_erase_c7, } }, --Reggie

1 0

[PATCH 2/2] serprog: fix bad serbuf and opbuf usage checks
by Urja Rannikko 11 Feb '15

11 Feb '15

I wasnt sure of the write-n opbuf checks, but atleast now it should be always checked. Signed-off-by: Urja Rannikko <urjaman(a)gmail.com> --- -- Urja Rannikko

1 0

[PATCH 1/2] serprog: Fix FWH/LPC by implementing serprog_map
by Urja Rannikko 11 Feb '15

11 Feb '15

also make serprog_map report if mapping doesnt fit in the 24-bit address space of serprog. Signed-off-by: Urja Rannikko <urjaman(a)gmail.com> ---

1 0

[PATCH 0/2] serprog bugfixes
by Urja Rannikko 11 Feb '15

11 Feb '15

Hi, I'll be following with two patches; one to implement a serprog_map that just returns the phys_addr for all valid cases and reports a warning if a mapping is attempted that is not in the 24-bit address space of serprog* and does what the current code would do - return NULL. * effectively being the upper 16MB of the 4GB address space of x86. The other one is to fix two stupid serial buffer usage checks that used to check if we havent already gone over by the amount the next message would be (ugh...), also has some opbuf check robusting. Given the closeness of 0.9.8 i thought it'd be nice to suggest these in for that, although i'm not holding my breath. The effect of these two should be localized to serprog parallel/lpc/fwh - which doesnt seem to be getting much use given that lpc/fwh is currently broken - also note that current SPI in-tree effectively doesn't use opbuf much - only for delays, and does all operations synchronously - thus serbuf checks dont affect it either... Thus i think these are safe to include in that nobody should be worse off _even if this somehow broke something_, which i think it doesn't. (Note: I'm trying to thread these, but ... gmail, so i dunno what how this will go.) -- Urja Rannikko

1 0

Re: [flashrom] Unknown state report
by Stefan Tauner 10 Feb '15

10 Feb '15

On Mon, 9 Feb 2015 19:52:06 +0200 Kaloyan Mihaylov <kaloyan.mihaylov(a)gmail.com> wrote: > flashrom.exe -p ft2232_spi:type=arm-usb-tiny-h - > E > flashrom v0.9.6.1-r1704 on Windows 6.1 (x86) > flashrom is free software, get the source code at http://www.flashrom.org > > Calibrating delay loop... OK. > Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ft2232_spi. > Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, > Found=0xe > 5, failed byte count from 0x00000000-0x00000fff: 0x9ca > ERASE FAILED! > Reading current flash chip contents... done. FAILED at 0x00008000! > Expected=0xff > , Found=0x85, failed byte count from 0x00008000-0x0000ffff: 0x4bb9 > ERASE FAILED! > Reading current flash chip contents... done. FAILED at 0x00008000! > Expected=0xff > , Found=0x85, failed byte count from 0x00000000-0x0000ffff: 0x4cb2 > ERASE FAILED! > Reading current flash chip contents... done. FAILED at 0x00050200! > Expected=0xff > , Found=0x00, failed byte count from 0x00000000-0x007fffff: 0x30e > ERASE FAILED! > Reading current flash chip contents... done. FAILED at 0x002e9800! > Expected=0xff > , Found=0x00, failed byte count from 0x00000000-0x007fffff: 0x700 > ERASE FAILED! > FAILED! > 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! Hi, that looks like erasing worked only sometimes... well, most of the times, but not always. Have you connected all pins of the flash chip? Is it still connected to a board? In the latter case please see http://flashrom.org/ISP for possible culprits. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom February 2015