flashrom July 2011

flashrom@flashrom.org

50 participants
275 discussions

Re: [flashrom] [PATCH 4/8] ichspi.c: preserve reserved bits in address registers
by Carl-Daniel Hailfinger 06 Jul '11

06 Jul '11

Am 28.06.2011 05:33 schrieb Stefan Tauner: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > Makes sense, but I worry that this might eventually break something. Do we (want to) report the inital address setting during programmer init, especially the reserved bits? Anyway, this is Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

3 2

Re: [flashrom] [Patch] NVIDIA Tegra2 SPI controller support
by Carl-Daniel Hailfinger 06 Jul '11

06 Jul '11

Am 28.06.2011 01:52 schrieb David Hendricks: > This patch set makes Flashrom a bit more ARM-friendly and adds raw Tegra2 > SPI controller support. It isolates a few PCI-isms, adds some low-level > hardware access stubs, adds Tegra2 processor detection, and adds Tegra2 raw > SPI controller code. > Nice! > I've attached some logfiles for read/erase/write operations. This particular > patch set was tested using a board based off NVIDIA's Tegra2 reference board > ("Seaboard"). Earlier revisions were tested on a Seaboard. > > All three attached patches are: > Signed-off-by: David Hendricks <dhendrix(a)google.com> > > Much of the original U-Boot --> Flashrom porting work was done by Stefan > Reinauer <reinauer(a)google.com>, and the FIFO code updated / fixed up by > Louis Lo <yjlou(a)google.com>. > > A few notes: > 1. A few programmers must be disabled due to reliance on PCI. You can hack > up your Makefile or compile with "CONFIG_RAYER_SPI=no CONFIG_NIC3COM=no > CONFIG_NICREALTEK=no CONFIG_SATAMV=no". > Actually, it is a requirement for PCI port I/O space (well, the non-memmapped space specified in the PCI standard, usually accesses with in[bwl]/out[bwl] functions). We ought to detect unavailability of that at compile time, preferably in the Makefile. > 2. Due to issues with libpci, you can't use the same binary on machines with > PCI and without PCI. So for example, you can't program a SPI ROM onboard a > PCI card that is connected to your ARM SoC. > Could you explain more? IIRC some people were using flashrom on ARM (independent patch) with PCI support. Not calling any PCI functions should be enough to avoid any and all interactions between libpci and the hardware. > 4. The tegra2_spi code was originally contributed by NVIDIA to the Chromium > OS U-Boot<http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=blob;…> > branch > and was later grafted into Flashrom so we could more easily perform SPI ROM > updates from userspace. Please excuse minor style inconsistencies as we are > trying to stay reasonably close to the code checked into the U-Boot tree ;-) > Ah, that explains some of the quirks I saw. Could you explain the Tegra2 hardware a bit more? The code suggests that it is more or less a slightly intelligent bitbanging controller with a "special" programing interface. At a first glance, the following issues stick out: 1-3-isolate_pci_isms.patch This essentially declares ARM a no-PCI zone. That's OK for testing, but not for merge. What exactly is the problem with PCI probing here? Does it return errors? Does it crash or terminate the application? Does it mess with the machine in ways which might cause breakage? 2-3-add_arm_isms.patch Have you checked with an architecture guru that sync_primitive() can really be empty, not only for that arch in general, but also for accesses to a mmapped region the way flashrom does it? 3-3-add_tegra2_spi_controller.patch Not your fault, but we really need a way to detect the target architecture in the Makefile. The issues of which SPI masters to include for internal exists on all architectures. Any ideas? I experimented with uname calls in the past, but that checks the host arch, not the target arch. Grepping the preprocessor output for the compiler might be an option. echo|gcc -dM -E -|grep "whatever\|arch\|defines" Or you try this pretty straightforward solution: Create a file arch.h with these contents: #if defined (__i386__) #define __FLASHROM_ARCH__ "x86" #elif defined (__x86_64__) #define __FLASHROM_ARCH__ "x86_64" #elif defined (__mips) || defined (__mips__) || defined (_mips) || defined (mips) #define __FLASHROM_ARCH__ "mips" #elif defined(__powerpc__) || defined(__powerpc64__) || defined(__ppc__) || defined(__ppc64__) #define __FLASHROM_ARCH__ "ppc" #endif __FLASHROM_ARCH__ Then run gcc -E arch.h|grep -v ^# The result on my machine will be "x86" Side note: Such an arch.h file (with some extensions) might save us from having to check every possible arch define everywhere we need to differentiate between architectures. I will comment on the Tegra2 SPI driver later, we should get the infrastructure questions addressed first. Regards, Carl-Daniel -- http://www.hailfinger.org/

3 2

Re: [flashrom] [PATCH] Autodetect target processor architecture
by Carl-Daniel Hailfinger 06 Jul '11

06 Jul '11

Thanks for the reviews! New version. Autodetect target processor architecture. Enable architecture dependent compilation of individual sub-drivers for the internal programmer. With this patch, you no longer have to edit the Makefile to compile the internal driver on MIPS/ARM/... Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-target_arch/Makefile =================================================================== --- flashrom-target_arch/Makefile (Revision 1364) +++ flashrom-target_arch/Makefile (Arbeitskopie) @@ -37,7 +37,10 @@ CFLAGS += -Werror endif -# FIXME We have to differentiate between host and target arch. +# Determine the destination processor architecture +ARCH = $(strip $(shell LC_ALL=C $(CC) -E arch.h|grep -v '^\#')) + +# FIXME We have to differentiate between host and target OS architecture. OS_ARCH ?= $(shell uname) ifneq ($(OS_ARCH), SunOS) STRIP_ARGS = -s @@ -304,8 +307,10 @@ ifeq ($(CONFIG_INTERNAL), yes) FEATURE_CFLAGS += -D'CONFIG_INTERNAL=1' PROGRAMMER_OBJS += processor_enable.o chipset_enable.o board_enable.o cbtable.o dmi.o internal.o -# FIXME: The PROGRAMMER_OBJS below should only be included on x86. +ifeq ($(ARCH),"x86") PROGRAMMER_OBJS += it87spi.o it85spi.o ichspi.o sb600spi.o wbsio_spi.o mcp6x_spi.o +else +endif NEED_PCI := yes endif @@ -500,6 +505,11 @@ echo "found." || ( echo "not found."; \ rm -f .test.c .test$(EXEC_SUFFIX); exit 1) @rm -f .test.c .test$(EXEC_SUFFIX) + @printf "ARCH is " + @# FreeBSD wc will output extraneous whitespace. + @echo $(ARCH)|wc -l|grep -q '^[[:blank:]]*1[[:blank:]]*$$' || \ + ( echo "unknown. Aborting."; exit 1) + @printf "%s\n" '$(ARCH)' ifeq ($(CHECK_LIBPCI), yes) pciutils: compiler Index: flashrom-target_arch/arch.h =================================================================== --- flashrom-target_arch/arch.h (Revision 0) +++ flashrom-target_arch/arch.h (Revision 0) @@ -0,0 +1,31 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2011 Carl-Daniel Hailfinger + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* + * Header file for CPU architecture checking. + */ + +#if defined (__i386__) || defined (__x86_64__) +#define __FLASHROM_ARCH__ "x86" +#elif defined (__mips) || defined (__mips__) || defined (_mips) || defined (mips) +#define __FLASHROM_ARCH__ "mips" +#elif defined(__powerpc__) || defined(__powerpc64__) || defined(__ppc__) || defined(__ppc64__) +#define __FLASHROM_ARCH__ "ppc" +#endif +__FLASHROM_ARCH__ -- http://www.hailfinger.org/

2 2

Re: [flashrom] PCCHIPS M863G V5.1A + Winbond W49V002AP - Write OK
by Stefan Tauner 06 Jul '11

06 Jul '11

On Sun, 3 Jul 2011 11:11:16 -0300 Marcos Felipe Rasia de Mello <marcosfrm(a)gmail.com> wrote: > 2011/7/3 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > > > > hello and thanks for your report! > > i have added the board to our supported hw list and marked the W49V002A > > as fully tested and will commit that later. > > > > You are welcome. > When should I send "lspci -nnvvxxx" output? Is only "flashrom -V" > output sufficient? > well, i would say for all reports that do not involve board enables (i.e. if there is no ""Disabling flash write protection for board" in the output), then flashrom -V is enough. but having the associated lspci data does not hurt (us) at all... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

AT26F004 support [PATCH]
by Tim Small 06 Jul '11

06 Jul '11

Hi, Back from holiday now - was wondering if there were any thoughts regarding the AT26F004 support patch? http://marc.info/?l=flashrom&m=130861563117389&w=2 <http://marc.info/?l=flashrom&m=130861563117389&w=2> Anything else needed to get it merged? Cheers! Tim.

1 0

Re: [flashrom] SPI Controller ICH9 Flash driver
by Stefan Tauner 06 Jul '11

06 Jul '11

On Tue, 5 Jul 2011 23:27:31 +0000 "Branham, Paul" <paul.branham(a)hp.com> wrote: > Hello, > > We are using your open source flashrom driver for Intel PCH Ibex Peak. (SPI_Controller_ICH9 in the source code with generation>8 => ie. SPIBAR = 0x3800). > > The flash ROM driver works well using CS0 by design. > > What we are looking for is information on how to use the other chip select -CS1- for some other SPI device. All Intel documentation we have found for this SPI Controller only specifies how to use the Flash capabilities of CS0, but no information whatsoever on how to use CS1 for any other SPI device. > > Would you have any source code or other information that may be of help? > hello paul, most of the public documentation from Intel does not help a lot as you already have found out... :) as far as i understand it, using multiple chips is only supported with hardware sequencing. you can read about that in detail here: http://blogs.coreboot.org/blog/2011/06/11/gsoc-2011-flashrom-part-1/ we are working on that and you can look at the following patches for preliminary support: http://patchwork.coreboot.org/patch/3242/ http://patchwork.coreboot.org/patch/3243/ http://patchwork.coreboot.org/patch/3244/ http://patchwork.coreboot.org/patch/3253/ they should be applied to the current source files, see http://flashrom.org/Downloads#Installation_from_source for details if your flash descriptors are correct and indicate two attached devices it should already work with the above patches unless the ME or the FREG registers prohibits flashrom to access some regions (which is likely on ibex peak platforms). in that case flashrom is not an option yet. i am working on that too, but it is not ready yet. in any case, sending us verbose logs of running flashrom with the patches above applied would be much appreciated. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH 3/3] ichspi.c: add support for Intel Hardware Sequencing
by Stefan Tauner 05 Jul '11

05 Jul '11

"fuzzy" on irc has tested the 6.1 patch set. the attached patch fixes the address checking. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

SPI Controller ICH9 Flash driver
by Branham, Paul 05 Jul '11

05 Jul '11

Hello, We are using your open source flashrom driver for Intel PCH Ibex Peak. (SPI_Controller_ICH9 in the source code with generation>8 => ie. SPIBAR = 0x3800). The flash ROM driver works well using CS0 by design. What we are looking for is information on how to use the other chip select -CS1- for some other SPI device. All Intel documentation we have found for this SPI Controller only specifies how to use the Flash capabilities of CS0, but no information whatsoever on how to use CS1 for any other SPI device. Would you have any source code or other information that may be of help? Thanks, - Paul Paul Branham Software Engineer, EB ESSN HPN Security Hewlett-Packard Company 512-681-8511

1 0

Additional voltages
by Steven Zakulec 04 Jul '11

04 Jul '11

Hello, I've attached some additional voltages for a number of the remaining chips in flashchips.c. I have some questions about some of the remaining chips: Should the voltage range always be the most restrictive one offered, with others mentioned in the comments? Where can I find the datasheet for the Sanyo LF25FW203A ? Can I ignore the .REMS/etc text after a chip name when looking for the datasheet? Is it something I need to be aware of? Is there a difference for M25P40 and P40-old? For the W25Q64, it seems to be on the same datasheet as the Q80, Q16, and Q32, but it's only referenced once in the sheet, and makes me wonder if this is the correct sheet then. For other chips, I'm mostly still working on them. Signed-off-by: Steven Zakulec <spzakulec(a)gmail.com>

1 0

Gigabyte M720-US3
by Grim Reaper 04 Jul '11

04 Jul '11

Hi, I sucessfully flash my BIOS using flashrom, but warning apear. See attachement - there is output from "flashrom -V". studio@studio:~$ sudo dmidecode -t baseboard # dmidecode 2.9 SMBIOS 2.4 present. Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: Gigabyte Technology Co., Ltd. Product Name: M720-US3 Version: Serial Number: If you need some more info simply ask. BTW. great APP ;-) Best Regards XJ

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom July 2011