flashrom October 2015

flashrom@flashrom.org

21 participants
49 discussions

Re: [flashrom] flashrom on PowerPC
by Stefan Tauner 20 Nov '15

20 Nov '15

On Wed, 27 Jul 2011 18:20:19 +0200 Mattias Mattsson <vitplister(a)gmail.com> wrote: > Hi all, > > I was able to run flashrom under Linux on PPC (big endian) hardware > with two small modifications in internal.c and processor_enable.c (see > attached patch). Not sure if this is the right way to do it but it > seems to work for me. > i am resending this patch (unchanged) because patchwork did not pick it up correctly. please do send one patch per mail only in the future until we have something really working. :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[PATCH 1/3] 128 bytes write granularity support
by Paul Kocialkowski 11 Nov '15

11 Nov '15

Some chips such as the ENE KB9012 internal flash require a write granularity of 128 bytes. Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- flash.h | 1 + flashrom.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/flash.h b/flash.h index 2c2839f..24861ba 100644 --- a/flash.h +++ b/flash.h @@ -85,6 +85,7 @@ enum write_granularity { write_gran_1bit, /* Each bit can be cleared individually. */ write_gran_1byte, /* A byte can be written once. Further writes to an already written byte cause * its contents to be either undefined or to stay unchanged. */ + write_gran_128bytes, /* If less than 128 bytes are written, the unwritten bytes are undefined. */ write_gran_264bytes, /* If less than 264 bytes are written, the unwritten bytes are undefined. */ write_gran_512bytes, /* If less than 512 bytes are written, the unwritten bytes are undefined. */ write_gran_528bytes, /* If less than 528 bytes are written, the unwritten bytes are undefined. */ diff --git a/flashrom.c b/flashrom.c index d51a44c..c9c7e31 100644 --- a/flashrom.c +++ b/flashrom.c @@ -781,6 +781,9 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; } break; + case write_gran_128bytes: + result = need_erase_gran_bytes(have, want, len, 128); + break; case write_gran_256bytes: result = need_erase_gran_bytes(have, want, len, 256); break; @@ -847,6 +850,9 @@ static unsigned int get_next_write(const uint8_t *have, const uint8_t *want, uns case write_gran_1byte_implicit_erase: stride = 1; break; + case write_gran_128bytes: + stride = 128; + break; case write_gran_256bytes: stride = 256; break; -- 1.9.1

4 16

[PATCH v2 1/2] Flag-driven erased bit value
by Paul Kocialkowski 11 Nov '15

11 Nov '15

Most flash chips are erased to ones and programmed to zeros. However, some other flash chips, such as the ENE KB9012 internal flash, work the opposite way. Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- flash.h | 5 ++++- flashrom.c | 39 +++++++++++++++++++++------------------ 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/flash.h b/flash.h index 24861ba..55d02de 100644 --- a/flash.h +++ b/flash.h @@ -123,6 +123,9 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_ERASED_ZERO (1 << 10) + +#define ERASED_VALUE(flash) ((flash->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff) enum test_state { OK = 0, @@ -275,7 +278,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f int read_flash_to_file(struct flashctx *flash, const char *filename); char *extract_param(const char *const *haystack, const char *needle, const char *delim); int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value); void print_version(void); void print_buildinfo(void); void print_banner(void); diff --git a/flashrom.c b/flashrom.c index c9c7e31..bd8ef3f 100644 --- a/flashrom.c +++ b/flashrom.c @@ -673,12 +673,13 @@ int check_erased_range(struct flashctx *flash, unsigned int start, { int ret; uint8_t *cmpbuf = malloc(len); + const uint8_t erased_value = ERASED_VALUE(flash); if (!cmpbuf) { msg_gerr("Could not allocate memory!\n"); exit(1); } - memset(cmpbuf, 0xff, len); + memset(cmpbuf, erased_value, len); ret = verify_range(flash, cmpbuf, start, len); free(cmpbuf); return ret; @@ -731,7 +732,7 @@ out_free: } /* Helper function for need_erase() that focuses on granularities of gran bytes. */ -static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran) +static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran, const uint8_t erased_value) { unsigned int i, j, limit; for (j = 0; j < len / gran; j++) { @@ -741,7 +742,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig continue; /* have needs to be in erased state. */ for (i = 0; i < limit; i++) - if (have[j * gran + i] != 0xff) + if (have[j * gran + i] != erased_value) return 1; } return 0; @@ -761,7 +762,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig * @gran write granularity (enum, not count) * @return 0 if no erase is needed, 1 otherwise */ -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran) +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value) { int result = 0; unsigned int i; @@ -776,31 +777,31 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; case write_gran_1byte: for (i = 0; i < len; i++) - if ((have[i] != want[i]) && (have[i] != 0xff)) { + if ((have[i] != want[i]) && (have[i] != erased_value)) { result = 1; break; } break; case write_gran_128bytes: - result = need_erase_gran_bytes(have, want, len, 128); + result = need_erase_gran_bytes(have, want, len, 128, erased_value); break; case write_gran_256bytes: - result = need_erase_gran_bytes(have, want, len, 256); + result = need_erase_gran_bytes(have, want, len, 256, erased_value); break; case write_gran_264bytes: - result = need_erase_gran_bytes(have, want, len, 264); + result = need_erase_gran_bytes(have, want, len, 264, erased_value); break; case write_gran_512bytes: - result = need_erase_gran_bytes(have, want, len, 512); + result = need_erase_gran_bytes(have, want, len, 512, erased_value); break; case write_gran_528bytes: - result = need_erase_gran_bytes(have, want, len, 528); + result = need_erase_gran_bytes(have, want, len, 528, erased_value); break; case write_gran_1024bytes: - result = need_erase_gran_bytes(have, want, len, 1024); + result = need_erase_gran_bytes(have, want, len, 1024, erased_value); break; case write_gran_1056bytes: - result = need_erase_gran_bytes(have, want, len, 1056); + result = need_erase_gran_bytes(have, want, len, 1056, erased_value); break; case write_gran_1byte_implicit_erase: /* Do not erase, handle content changes from anything->0xff by writing 0xff. */ @@ -1424,6 +1425,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, unsigned int starthere = 0, lenhere = 0; int ret = 0, skip = 1, writecount = 0; enum write_granularity gran = flash->chip->gran; + const uint8_t erased_value = ERASED_VALUE(flash); /* curcontents and newcontents are opaque to walk_eraseregions, and * need to be adjusted here to keep the impression of proper abstraction @@ -1431,7 +1433,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, curcontents += start; newcontents += start; msg_cdbg(":"); - if (need_erase(curcontents, newcontents, len, gran)) { + if (need_erase(curcontents, newcontents, len, gran, erased_value)) { msg_cdbg("E"); ret = erasefn(flash, start, len); if (ret) @@ -1441,7 +1443,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, return -1; } /* Erase was successful. Adjust curcontents. */ - memset(curcontents, 0xff, len); + memset(curcontents, erased_value, len); skip = 0; } /* get_next_write() sets starthere to a new value after the call. */ @@ -1938,6 +1940,7 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, int ret = 0; unsigned long size = flash->chip->total_size * 1024; int read_all_first = 1; /* FIXME: Make this configurable. */ + const uint8_t erased_value = ERASED_VALUE(flash); if (chip_safety_check(flash, force, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -1964,15 +1967,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_gerr("Out of memory!\n"); exit(1); } - /* Assume worst case: All bits are 0. */ - memset(oldcontents, 0x00, size); + /* Assume worst case: All bits are not erased. */ + memset(oldcontents, ~erased_value, size); newcontents = malloc(size); if (!newcontents) { msg_gerr("Out of memory!\n"); exit(1); } - /* Assume best case: All bits should be 1. */ - memset(newcontents, 0xff, size); + /* Assume best case: All bits should be erased. */ + memset(newcontents, erased_value, size); /* Side effect of the assumptions above: Default write action is erase * because newcontents looks like a completely erased chip, and * oldcontents being completely 0x00 means we have to erase everything -- 2.4.3

2 5

Re: [flashrom] Flash chip/chipset not found
by Carl-Daniel Hailfinger 02 Nov '15

02 Nov '15

Hi Mark, would it be possible for you to generate a log file using the additional parameter --output logfile.txt when doing a read of the flash chip, then send that log file to us? That would help us to finally merge support for the VT8251 chipset in your point-of-sale IBM/Toshiba AnyPlace Kiosk Model 48xx series. We have a strict rule that flashrom must be 100% reliable and thus we keep log files for any newly supported/tested chipset around for reference. Your log file would be used as reference for VT8251. That said, it would be very interesting to know where the settings are actually stored. Have you looked into the top 128 bytes of NVRAM? Maybe there is another flash chip? Is there any way to trace what the save/restore tool does (i.e. does it run on Linux)? Regards, Carl-Daniel On 28.10.2015 23:25, Rowlinson Mark wrote: > Hi Carl-Daniel, > > That change does allow the chipset to be recognised and it will write out the ROM. It seems to be the BIOS code only (no settings) as it doesn't change if I change any settings within the BIOS. > > I've been directed to a save/restore utility that comes on the BIOS update image and it seems the last version actually accesses the data I'm interested in so I'm investigating this route at the moment. > > Best Regards, > Mark Rowlinson > > -----Original Message----- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] > Sent: 24 October 2015 09:22 > To: Rowlinson Mark <Mark.Rowlinson(a)uk.fujitsu.com>; flashrom(a)flashrom.org > Subject: Re: [flashrom] Flash chip/chipset not found > > Hi Mark, > > this is a VIA VT8251 PCI to ISA Bridge you're using. > > I think Stefan Tauner (in CC) already was discussing something similar here: > http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html > That email even has a patch attached. > > > On 22.10.2015 22:24, Rowlinson Mark wrote: >> Thanks for the swift response, I have attached output from the command requested. >> >> The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. > Heh, would be fun to add this to our tests. > > Regards, > Carl-Daniel >

2 1

SOIC8 test clip - cant write to BIOS SPI flash chip
by Robert Brown 01 Nov '15

01 Nov '15

Unfortunately I don't have any soldering tools or experience, so if you could give an advice about ISP programming (In-System-Programming/In-Situ-Programming) , it will be super helpful! I teardown a bricked laptop, removed AC power, laptop's power battery, and even a small CMOS battery, and now I am trying to write a working BIOS image to laptop's SPI flash chip using a SOIC8 test clip. But here is a problem: I could read a dump from this BIOS chip without problems, however it fails when I am trying to write - so the contents of BIOS flash chip are remaining unchanged. Luckily I found out this helpful wiki page - http://flashrom.org/ISP , which describes common problems with this ISP method of flashing, as well as gives 3 hints for solution! Sadly this page is currently down, so here is a screenshot: http://i.imgur.com/SJEYHR2.png 1. - tried to make shorter wires, less than 10cm as they recommend - it did not help 2. - soldering is out of possibility, cant do it, and also: wires are already short and they are good quality (pure copper) 3. - This hint looks more promising, but I need help in understanding this piece of information: "disconnect Vcc from the programmer and power it with its normal PSU" If I understand correctly, by Vcc they mean Vcc pin of the BIOS flash chip. But if I disconnect Vcc from the programmer, what is "normal PSU" which should power this Vcc pin? Should I connect to motherboard a laptop's power battery, or small CMOS battery, or AC adapter of laptop, so that this Vcc pin would be powered by them, or it is forbidden to do it while using SPI programmer in the same time? Or its better to try to power Vcc of flash chip from "USB to TTL" adapter - which has this 3V3 (3.3V) voltage pin? Yours faithfully, Robert Brown _______________________________________________________________ Get the Free email that has everyone talking at <a href=http://www.mail2world.com target=new>http://www.mail2world.com</a> Unlimited Email Storage POP3 Calendar SMS Translator Much More!

3 3

[PATCH] Add (implicit) support for musl libc.
by Stefan Tauner 31 Oct '15

31 Oct '15

This is mostly achieved by fixing or refining the inclusion of header files and replacing glibc-specific ifdefs with more generic ones. - <sys/io.h>: Contains iopl(2) and x86 I/O port access functions (inb, outb etc). Generally Linux-specific but also availble on debian/kFreeBSD. Provided by glibc as well as musl and uclibc. Include it if we are running Linux or if glibc is detected. - <sys/fcntl.h>: should be (and is) replaced by <fcntl.h> (without the "sys" prefix). - <linux/spi/spidev.h>: Does not include all necessary headers, namely _IOC_SIZEBITS that is used in the definition of SPI_MSGSIZE is not brought in via <linux/ioctl.h> but instead we relied so far on glibc's including it via <sys/ioctl.h>. Change that to explicitly including <linux/ioctl.h>. - <endian.h>: Would also be available in musl but there is no easy way to detect it so we do not try yet. The bug report and initial patches were Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou(a)trabucayre.com> Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- New version because the sys/io.h change was actually breaking Debian/kFreeBSD! Moved it down where all the IN[BWL]/OUT[BWL] definitions are. hwaccess.h | 14 ++++++++------ linux_spi.c | 5 +++-- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/hwaccess.h b/hwaccess.h index 3e46192..390f0e4 100644 --- a/hwaccess.h +++ b/hwaccess.h @@ -26,12 +26,6 @@ #include "platform.h" -#if IS_X86 -#if defined(__GLIBC__) -#include <sys/io.h> -#endif -#endif - #if NEED_PCI == 1 /* * libpci headers use the variable name "index" which triggers shadowing @@ -115,6 +109,7 @@ #if !defined (__FLASHROM_BIG_ENDIAN__) && !defined (__FLASHROM_LITTLE_ENDIAN__) /* Nonstandard libc-specific macros for determining endianness. */ +/* musl provides an endian.h as well... but it can not be detected from within C. */ #if defined(__GLIBC__) #include <endian.h> #if BYTE_ORDER == LITTLE_ENDIAN @@ -204,6 +199,13 @@ cpu_to_be(64) #if NEED_PCI == 1 #if IS_X86 +/* sys/io.h provides iopl(2) and x86 I/O port access functions (inb, outb etc). + * It is included in glibc (thus available also on debian/kFreeBSD) but also in other libcs that mimic glibc, + * e.g. musl and uclibc. */ +#if defined(__linux__) || defined(__GLIBC__) +#include <sys/io.h> +#endif + #define __FLASHROM_HAVE_OUTB__ 1 /* for iopl and outb under Solaris */ diff --git a/linux_spi.c b/linux_spi.c index 26725e1..19b4965 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -22,13 +22,14 @@ #include <stdio.h> #include <string.h> #include <stdlib.h> -#include <sys/fcntl.h> +#include <fcntl.h> #include <errno.h> #include <ctype.h> #include <unistd.h> +#include <sys/ioctl.h> #include <linux/types.h> #include <linux/spi/spidev.h> -#include <sys/ioctl.h> +#include <linux/ioctl.h> #include "flash.h" #include "chipdrivers.h" #include "programmer.h" -- Kind regards, Stefan Tauner

1 0

[PATCH 1/2] Add missing header for musl compatibility
by Gwenhael Goavec-Merou 30 Oct '15

30 Oct '15

From: Gwenhael Goavec-Merou <gwenhael.goavec-merou(a)trabucayre.com> According to : http://autobuild.buildroot.net/results/3de/3de936d9be79e151e66af15193084d82… linux/ioctl.h header must be included in linux_spi.c to obtain missing _IOC_SIZEBITS. Patch based on : http://git.buildroot.net/buildroot/commit/package/c-periphery/0001-Add-miss… Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou(a)trabucayre.com> --- linux_spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/linux_spi.c b/linux_spi.c index 26725e1..8d72420 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -28,6 +28,7 @@ #include <unistd.h> #include <linux/types.h> #include <linux/spi/spidev.h> +#include <linux/ioctl.h> #include <sys/ioctl.h> #include "flash.h" #include "chipdrivers.h" -- 2.4.9

3 6

Re: [flashrom] Flash chip/chipset not found
by Carl-Daniel Hailfinger 28 Oct '15

28 Oct '15

Hi Mark, this is a VIA VT8251 PCI to ISA Bridge you're using. I think Stefan Tauner (in CC) already was discussing something similar here: http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html That email even has a patch attached. On 22.10.2015 22:24, Rowlinson Mark wrote: > Thanks for the swift response, I have attached output from the command requested. > > The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. Heh, would be fun to add this to our tests. Regards, Carl-Daniel

2 2

CHIPSET: alix 3d3
by John Vacek 27 Oct '15

27 Oct '15

Proceeding anyway because user forced us to. Found chipset "AMD CS5536". Enabling flash write... OK. WARNING: unexpected second chipset match: "AMD CS5536" ignoring, please report lspci and board URL to flashrom(a)flashrom.org with 'CHIPSET: your board name' in the subject line. Found AMIC flash chip "A49LF040A" (512 kB, LPC) at physical address 0xfff80000. No operations were specified. http://www.pcengines.ch/alix3d3.htm root@kali-alix:~# lspci -nn 00:01.0 Host bridge [0600]: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] (rev 33) 00:01.1 VGA compatible controller [0300]: Advanced Micro Devices [AMD] Geode LX Video [1022:2081] 00:01.2 Entertainment encryption device [1010]: Advanced Micro Devices [AMD] Geode LX AES Security Block [1022:2082] 00:09.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) 00:0c.0 SATA controller [0106]: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller [1095:3512] (rev 01) 00:0e.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11a/b/g [14e4:4324] (rev 02) 00:0f.0 ISA bridge [0601]: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA [1022:2090] (rev 03) 00:0f.2 IDE interface [0101]: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE [1022:209a] (rev 01) 00:0f.3 Multimedia audio controller [0401]: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio [1022:2093] (rev 01) 00:0f.4 USB controller [0c03]: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC [1022:2094] (rev 02) 00:0f.5 USB controller [0c03]: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC [1022:2095] (rev 02)

1 0

Re: [flashrom] Flash chip/chipset not found
by Carl-Daniel Hailfinger 22 Oct '15

22 Oct '15

Hi Mark, On 21.10.2015 16:18, Rowlinson Mark wrote: > I have a 32bit touch screen device running CentOS 5.2 which has some of its BIOS settings accessible in /dev/nvram and others elsewhere else (that's why I've been loooking at flashrom). > I have tried later distributions (CentOS 6.7 and the System Rescue CD) and they both report the following: > [root@server ~]# /var/tmp/flashrom-0.9.8/flashrom -p internal > flashrom v0.9.8-r1888 on Linux 2.6.32-573.el6.i686 (i686) > [...] > WARNING: No chipset found. Flash detection will most likely fail. > No EEPROM/flash device found. It seems we have to add some PCI IDs to our southbridge table. Do you have an exact name of the machine in question? > What information is needed to identify the chipset in use so support can be added for these devices? (as root) lspci -nnvvvxxx That should be sufficient for us to find out the southbridge and some of its settings. Regards, Carl-Daniel

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom October 2015