flashrom January 2015

flashrom@flashrom.org

35 participants
121 discussions

[PATCH 3/3] Properly include libusb-win32 header.
by Stefan Tauner 19 Jan '15

19 Jan '15

libusb-win32 is using a different header file name for a while, use that on Windows builds to make clear that this is currently the correct header to include. Hopefully this will change soonish with migrating away from libusb-0. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- Makefile | 5 +++++ dediprog.c | 8 ++++++++ 2 files changed, 13 insertions(+) diff --git a/Makefile b/Makefile index 54ebfe4..03670d2 100644 --- a/Makefile +++ b/Makefile @@ -843,7 +843,12 @@ endef export LIBPCI_TEST define LIBUSB0_TEST +#include "platform.h" +#if IS_WINDOWS +#include <lusb0_usb.h> +#else #include <usb.h> +#endif int main(int argc, char **argv) { (void) argc; diff --git a/dediprog.c b/dediprog.c index 71a9f8b..4248499 100644 --- a/dediprog.c +++ b/dediprog.c @@ -17,11 +17,19 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include "platform.h" + #include <stdio.h> #include <string.h> #include <limits.h> #include <errno.h> + +#if IS_WINDOWS +#include <lusb0_usb.h> +#else #include <usb.h> +#endif + #include "flash.h" #include "chipdrivers.h" #include "programmer.h" -- Kind regards, Stefan Tauner

1 0

[PATCH 2/3] Add support for SPARC (maybe).
by Stefan Tauner 19 Jan '15

19 Jan '15

Does (cross-)compile but is not run-tested. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- Makefile | 2 +- hwaccess.h | 8 ++++++++ platform.h | 5 ++++- 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index b738e73..54ebfe4 100644 --- a/Makefile +++ b/Makefile @@ -320,7 +320,7 @@ endif # below uses CC itself. override ARCH := $(strip $(shell LC_ALL=C $(CC) $(CPPFLAGS) -E archtest.c 2>/dev/null | grep -v '^\#' | grep '"' | cut -f 2 -d'"')) -# PCI port I/O support is unimplemented on PPC/MIPS and unavailable on ARM. +# PCI port I/O support is unimplemented on PPC/MIPS/SPARC and unavailable on ARM. # Right now this means the drivers below only work on x86. ifneq ($(ARCH), x86) ifeq ($(CONFIG_NIC3COM), yes) diff --git a/hwaccess.h b/hwaccess.h index a4fd502..5378361 100644 --- a/hwaccess.h +++ b/hwaccess.h @@ -89,6 +89,10 @@ #define __FLASHROM_LITTLE_ENDIAN__ 1 #endif +#elif IS_SPARC +/* SPARC is big endian in general (but allows to access data in little endian too). */ +#define __FLASHROM_BIG_ENDIAN__ 1 + #endif /* IS_? */ #if !defined (__FLASHROM_BIG_ENDIAN__) && !defined (__FLASHROM_LITTLE_ENDIAN__) @@ -357,6 +361,10 @@ int libpayload_wrmsr(int addr, msr_t msr); /* PCI port I/O is not yet implemented on MIPS. */ +#elif IS_SPARC + +/* PCI port I/O is not yet implemented on SPARC. */ + #elif IS_ARM /* Non memory mapped I/O is not supported on ARM. */ diff --git a/platform.h b/platform.h index f57fd12..9cde054 100644 --- a/platform.h +++ b/platform.h @@ -45,9 +45,12 @@ defined(__aarch64__) #define __FLASHROM_ARCH__ "arm" #define IS_ARM 1 +#elif defined (__sparc__) || defined (__sparc) + #define __FLASHROM_ARCH__ "sparc" + #define IS_SPARC 1 #endif -#if !(IS_X86 || IS_MIPS || IS_PPC || IS_ARM) +#if !(IS_X86 || IS_MIPS || IS_PPC || IS_ARM || IS_SPARC) #error Unknown architecture #endif -- Kind regards, Stefan Tauner

1 0

[PATCH 1/3] Let pkg-config work with cross-compilers.
by Stefan Tauner 19 Jan '15

19 Jan '15

In cross-compiler setups pkg-config often needs some help to determine the correct libraries. This can be done for example by setting PKG_CONFIG_LIBDIR to point to the directory where the cross-compile .pc files are located. If PKG_CONFIG_LIBDIR was not set already outside of the Makefile we set it according to LIBS_BASE and add the respective path to the linker's rpath. This makes it possible to easily cross-compile by only setting CC and LIBS_BASE on the command line. This patch also removes the explicit default for LIBS_BASE again because it does not play well with this change and was a bad idea to begin with. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- Makefile | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index a36628c..b738e73 100644 --- a/Makefile +++ b/Makefile @@ -37,7 +37,6 @@ MANDIR ?= $(PREFIX)/share/man CFLAGS ?= -Os -Wall -Wshadow EXPORTDIR ?= . RANLIB ?= ranlib -LIBS_BASE ?= .. # The following parameter changes the default programmer that will be used if there is no -p/--programmer # argument given when running flashrom. The predefined setting does not enable any default so that every @@ -65,8 +64,13 @@ ifeq ($(WARNERROR), yes) CFLAGS += -Werror endif +ifdef LIBS_BASE CPPFLAGS += -I$(LIBS_BASE)/include -LDFLAGS += -L$(LIBS_BASE)/lib +LDFLAGS += -L$(LIBS_BASE)/lib -Wl,-rpath -Wl,$(LIBS_BASE)/lib +ifndef PKG_CONFIG_LIBDIR + PKG_CONFIG_LIBDIR = $(LIBS_BASE)/lib/pkgconfig +endif +endif ############################################################################### # General OS-specific settings. @@ -611,7 +615,7 @@ PROGRAMMER_OBJS += usbblaster_spi.o endif ifeq ($(NEED_FTDI), yes) -FTDILIBS := $(shell pkg-config --libs libftdi 2>/dev/null || printf "%s" "-lftdi -lusb") +FTDILIBS := $(shell ([ -n "$(PKG_CONFIG_LIBDIR)" ] && export PKG_CONFIG_LIBDIR="$(PKG_CONFIG_LIBDIR)" ); pkg-config --libs libftdi || printf "%s" "-lftdi -lusb") FEATURE_CFLAGS += $(shell LC_ALL=C grep -q "FT232H := yes" .features && printf "%s" "-D'HAVE_FT232H=1'") FEATURE_LIBS += $(shell LC_ALL=C grep -q "FTDISUPPORT := yes" .features && printf "%s" "$(FTDILIBS)") # We can't set NEED_USB here because that would transform libftdi auto-enabling @@ -734,7 +738,7 @@ endif ifeq ($(NEED_USB), yes) CHECK_LIBUSB0 = yes FEATURE_CFLAGS += -D'NEED_USB=1' -USBLIBS := $(shell pkg-config --libs libusb 2>/dev/null || printf "%s" "-lusb") +USBLIBS := $(shell ([ -n "$(PKG_CONFIG_LIBDIR)" ] && export PKG_CONFIG_LIBDIR="$(PKG_CONFIG_LIBDIR)" ); pkg-config --libs libusb || printf "%s" "-lusb") endif ifeq ($(CONFIG_PRINT_WIKI), yes) -- Kind regards, Stefan Tauner

1 0

[PATCH]Build everything on request
by Patrick Georgi 19 Jan '15

19 Jan '15

Hi, attached patch adds a BUILD_EVERYTHING flag to Makefile that sets all CONFIG_* flags to "yes" if they were "no". This provides a comfortable way to ensure maximum code exposure to tools like coverity[0] or clang's scan-build. BUILD_EVERYTHING will likely fail on non-Linux/x86 systems, but it seems that's a hard dependency to compile everything at this time, so well... Signed-off-by: Patrick Georgi <patrick(a)georgi-clan.de> Regards, Patrick [0] https://scan.coverity.com/projects/1020

2 2

[commit] r1869 - trunk
by repository service 19 Jan '15

19 Jan '15

Author: stefanct Date: Mon Jan 19 20:52:34 2015 New Revision: 1869 URL: http://flashrom.org/trac/flashrom/changeset/1869 Log: Allow to easily build all optional modules. This patch adds a CONFIG_EVERYTHING flag to the Makefile that sets all CONFIG_* flags to "yes" if they were "no". This provides a comfortable way to ensure maximum code exposure to tools like coverity[0] or clang's scan-build. [0] https://scan.coverity.com/projects/1020 Signed-off-by: Patrick Georgi <patrick(a)georgi-clan.de> 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 Sat Jan 10 16:59:54 2015 (r1868) +++ trunk/Makefile Mon Jan 19 20:52:34 2015 (r1869) @@ -467,6 +467,13 @@ # Disable wiki printing by default. It is only useful if you have wiki access. CONFIG_PRINT_WIKI ?= no +# Enable all features if CONFIG_EVERYTHING=yes is given +ifeq ($(CONFIG_EVERYTHING), yes) +$(foreach var, $(filter CONFIG_%, $(.VARIABLES)),\ + $(if $(filter no, $($(var))),\ + $(eval $(var)=yes))) +endif + # Bitbanging SPI infrastructure, default off unless needed. ifeq ($(CONFIG_RAYER_SPI), yes) override CONFIG_BITBANG_SPI = yes

1 0

[PATCH] Fast flash read speed with FTDI FT2232H programmer
by Boris Baykov 18 Jan '15

18 Jan '15

The patch increases flash read speed via FTDI FT2232H programmer. New ft2232_spi_read function used instead of spi_read_chunked to read by 64k chunks instead of 256b chunks. According to 3-7 ms FTDI delay for each flash instruction this patch makes read operation faster in about 10 times. To have stable transfers with 64k buffer SPI frequency should be decreased to 5 MHz. I don't know why but higher freqs aren't working correct. DEFAULT_DIVISOR is changed to 12. Signed-off-by: Boris Baykov <dev(a)borisbaykov.com>, Russia, Jan 2015 --- diff -U 5 -N ./flashrom/ft2232_spi.c ./flashrom.fast_ftdi/ft2232_spi.c --- ./flashrom/ft2232_spi.c 2015-01-08 15:21:54.000000000 +0300 +++ ./flashrom.fast_ftdi/ft2232_spi.c 2015-01-18 08:44:26.000000000 +0300 @@ -27,10 +27,11 @@ #include <ctype.h> #include "flash.h" #include "programmer.h" #include "spi.h" #include <ftdi.h> +#include "chipdrivers.h" /* This is not defined in libftdi.h <0.20 (c7e4c09e68cfa6f5e112334aa1b3bb23401c8dc7 to be exact). * Some tests indicate that his is the only change that it is needed to support the FT232H in flashrom. */ #if !defined(HAVE_FT232H) #define TYPE_232H 6 @@ -73,11 +74,14 @@ {OLIMEX_VID, OLIMEX_ARM_TINY_H_PID, OK, "Olimex", "ARM-USB-TINY-H"}, {0}, }; -#define DEFAULT_DIVISOR 2 +/* Default divisor has been changed to 12 to provide 5 MHz frequency. + * This frequency is maximum stable frequency for operate with 64k buffer. + */ +#define DEFAULT_DIVISOR 12 #define BITMODE_BITBANG_NORMAL 1 #define BITMODE_BITBANG_SPI 2 /* Set data bits low-byte command: @@ -144,17 +148,20 @@ static int ft2232_spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr); +static int ft2232_spi_read(struct flashctx *flash, uint8_t *buf, + unsigned int start, unsigned int len); + static const struct spi_master spi_master_ft2232 = { .type = SPI_CONTROLLER_FT2232, .max_data_read = 64 * 1024, .max_data_write = 256, .command = ft2232_spi_send_command, .multicommand = default_spi_send_multicommand, - .read = default_spi_read, + .read = ft2232_spi_read, .write_256 = default_spi_write_256, .write_aai = default_spi_write_aai, }; /* Returns 0 upon success, a negative number upon errors. */ @@ -294,10 +301,15 @@ msg_perr("Error: Invalid SPI frequency divisor specified: \"%s\".\n" "Valid are even values between 2 and 131072.\n", arg); free(arg); return -2; } else { + if (temp < DEFAULT_DIVISOR) { + msg_pinfo("\nWarning: SPI frequency is too high for FT2232H with 64k buffer.\n" + "Some data from SPI may be lost. To ensure stability please\n" + "encrease the divisor value at least to %d.\n\n", DEFAULT_DIVISOR); + } divisor = (uint32_t)temp; } } free(arg); @@ -486,6 +498,53 @@ msg_perr("send_buf failed at end: %i\n", ret); return failed ? -1 : 0; } +/* FIXME: This function is optimized so that it does not split each transaction + * into chip page_size long blocks unnecessarily like spi_read_chunked. This has + * the advantage that it is much faster for most chips, but breaks those with + * non-continuous reads. When spi_read_chunked is fixed this method can be removed. */ +static int ft2232_spi_read(struct flashctx *flash, uint8_t *buf, + unsigned int start, unsigned int len) +{ + int ret; + unsigned int i, cur_len; + const unsigned int max_read = spi_master_ft2232.max_data_read; + int show_progress = 0; + unsigned int percent_last = 0, percent_current = 0; + + /* progress visualizaion init */ + if(len >= MIN_LENGTH_TO_SHOW_READ_PROGRESS) { + msg_cinfo(" "); /* only this space will go to logfile but + all strings with \b wont. */ + msg_cinfo("\b 0%%"); + percent_last = percent_current = 0; + show_progress = 1; /* enable progress visualizaion */ + } + + for (i = 0; i < len; i += cur_len) { + cur_len = min(max_read, (len - i)); + ret = (flash->chip->feature_bits & FEATURE_4BA_SUPPORT) == 0 + ? spi_nbyte_read(flash, start + i, buf + i, cur_len) + : flash->chip->four_bytes_addr_funcs.read_nbyte(flash, + start + i, buf + i, cur_len); + if (ret) + break; + + if(show_progress) { + percent_current = (unsigned int) + (((unsigned long long)(i + cur_len)) * 100 / len); + if(percent_current != percent_last) { + msg_cinfo("\b\b\b%2d%%", percent_current); + percent_last = percent_current; + } + } + } + + if(show_progress && !ret) + msg_cinfo("\b\b\b\b"); /* remove progress percents from the screen */ + + return ret; +} + #endif

2 4

Re: [flashrom] arm, chromebook and pci.h
by Stefan Tauner 18 Jan '15

18 Jan '15

On Sun, 11 Jan 2015 20:43:23 -0800 bruce m beach <brucembeach(a)gmail.com> wrote: > Here are some straightforward results > > 1----------------------------------------- > )flashrom -p linux_spi:dev=/dev/spidev1.0 > flashrom v0.9.7-r1711 on Linux 3.4.0 (armv7l) > flashrom is free software, get the source code at > http://www.flashrom.org > > Calibrating delay loop... OK. > Found Winbond flash chip "W25Q32.W" (4096 kB, SPI) on linux_spi. > No operations were specified. > ) > > 2----------------------------------------- > )flashrom -r original_flash -p linux_spi:dev=/dev/spidev1.0 > flashrom v0.9.7-r1711 on Linux 3.4.0 (armv7l) > flashrom is free software, get the source code at > http://www.flashrom.org > > Calibrating delay loop... OK. > Found Winbond flash chip "W25Q32.W" (4096 kB, SPI) on linux_spi. > Block protection could not be disabled! > Reading flash... done. > ) That's probably due to the hardware write protection enabled... as you probably know the chrombooks have a screw or switch that does that. There is public documentation about this for most/all chromebooks... > >> Is the Chromebook not supported by this version of flashrom > >That's exactly the case... google has forked flashrom in > >chromiumos and I strongly recommend using their version at the > >moment on those systems. > > I'm aware of the chromiumos fork and spent an afternoon reading > everything I could and decided flashrom was what I wanted (as > apposed to flashrom_chrome say). I run a totally stock linux > system. It is not an Ubuntu, debian or anything system. All the > packages including yours I build out of the box with no > modifications and no reference at all to the fact that this is an > arm system. It is completely transparent. It is reasonable expect > that even the low level operations work properly. It is all taken > care of by the kernel. Not necessarily. Flashrom uses interfaces that the kernel does not provide but that reside directly in the hardware. (That's also the reason why it does work on non-Linux systems.) > Now far as getting flashrom_chrome, I > don't have it. I have long since blown chrome away (I store my > source files where it used to be) and don't want anything to do > with it. (my hostname is system_zinc) Furthermore I don't think I > could even build it on this machine without a great deal of work. You don't need chromeos just to build chromoiumos' flashrom. It should build just like vanilla flashrom (apart from some minor bugs like wrong includes etc. that I am sure you can fix). I just build current chromiumos' master of flashrom and it runs just fine. > > a *truly* horrible thought is the inevitable work to be done to > > converge the two flashroms again but that should not be your > > problem except if you want to. ;) > > This is not out of the question. I have been looking at that > source but have not been able to do a 'git clone' on it, but > might be able get it eventually. There are some addtional command > line options that might be nice to have in addition to the > chromebook stuff that they are probably concentrating on. I'm > refering to the fact that there are a zillion different chromebooks out > there. Intel based is one that comes immediately to mind, as > apposed to arm. Do you have a wish list? Currently not. There are too many other open questions right now to start even thinking about this yet. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Gmail's blocking flashrom mails
by Stefan Tauner 18 Jan '15

18 Jan '15

Hi, I am writing to you directly because gmail decided to not deliver any mails from the flashrom mailing list to you anymore and hence you got unsubscribed automatically after a number of bounces. I am wondering if this mail is coming through as well because it is addressed to about 100 gmail accounts at once... :) In any case... I am not administrating the mail server and even if I would, I would probably not dance to google's tune anyway. If your choice is to let google decide what mails can reach you, then so be it and good bye. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 2

ASUS A8N-SLI Deluxe SUCCESS
by Brendan Martens 17 Jan '15

17 Jan '15

1 0

Re: [flashrom] Erase transactions failing
by Stephan G. 17 Jan '15

17 Jan '15

In vanilla.log, I observe the following: Found Winbond flash chip "W25Q64.V" (8192 kB, SPI). This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). Are you sure your flash is not partially protected, as indicated ? Also, for point 2, I forgot to ask. What is output of ich_descriptors_tool (can be found in flashrom source tree) ? Le 16/01/2015 07:41, David Mirabito a écrit : > Hello, > > We have a Rangely-based board and would strongly prefer to be able to > update the bios via flashrom, and I'm coming across two issues here: > > Attached is the output from > './flashrom --programmer internal:laptop=this_is_not_a_laptop -o > vanilla.log -VV' > > 1) Note the descriptor table: > --- Details --- > Region 0 (Descr.) 0x00000000 - 0x0000ffff > Region 1 (BIOS ) 0x00200000 - 0x007fffff > Region 2 (ME ) is unused. > Region 3 (GbE ) is unused. > Region 4 (Platf.) is unused. > > The gap between Regions 0 and 1 appears unreadable, and I get > transaction failures at 0x00010000. Modifying flashrom to only dump > the final 6MB works as expected. > > 2) Given the above modifications (which ideally I'll roll properly > into the layout file infrastructure) I am still having trouble writing > to Region 1. > > After making sure that nothing is attempting to read or write outside > the required range, the write transaction still fails at the first > access (see fail.log): > > ETransaction error! > SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 > SSFC: SCGO=0, ACS=1, SPOP=0, COP=2, DBC=0, SME=0, SCF=0 > Running OPCODE 0x20 failed at address 0x400000 (payload length was 0). > spi_block_erase_20 failed during command execution at address 0x400000 > > (interestingly, last time I tried this I had the same error at 0x200000) > > It appears to me that it should be writiable, is this not the case? > > ----- > > Thanks for any input! Additionally we may have some input with the > BIOS vendor (and ability to write via JTAG or EFIshell), so if there's > anything specific we might ask for as far as leaving chipset registers > in a certain state, then this may be a posisbility if it comes to that. > > Cheers, > DavidM > > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom January 2015