August 2013 - flashrom - mail.coreboot.org

Re: [flashrom] flashrom behavior report: Sun Fire X4500 w/FlashROM 0.9.7
by Idwer Vollering Aug. 26, 2013

Aug. 26, 2013

2013/8/26 Rich <rercola(a)pha.jhu.edu> > A brief summary: > Nothing works. > > # ./flashrom -p internal > flashrom v0.9.7-r1711 on Linux 3.8.0-29-generic (x86_64) > flashrom is free software, get the source code at http://www.flashrom.org > > Calibrating delay loop... OK. > Found chipset "AMD AMD8111". Enabling flash write... OK. > No EEPROM/flash device found. > Note: flashrom can never write if the flash chip isn't found automatically. > It's likely that remote management (DRAC, iLO/IPMI) peripheral hardware are hiding the flash chip. > Log from lspci, superiotool, and flashrom 0.9.7 attached. > The X4500 is from 2006, my guess is that the flash chip comes in the TSOP form factor: http://flashrom.org/Technology Can you remove the CPU/processor board (and take a high resolution photo)? > - Rich > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

1 0

flashrom behavior report: Sun Fire X4500 w/FlashROM 0.9.7
by Rich Aug. 26, 2013

Aug. 26, 2013

A brief summary: Nothing works. # ./flashrom -p internal flashrom v0.9.7-r1711 on Linux 3.8.0-29-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "AMD AMD8111". Enabling flash write... OK. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. Log from lspci, superiotool, and flashrom 0.9.7 attached. - Rich

1 0

Re: [flashrom] MX25U1635E (on OLPC XO-4 B1) with flashrom r1657
by Stefan Tauner Aug. 26, 2013

Aug. 26, 2013

On Tue, 19 Mar 2013 16:12:43 +1100 James Cameron <quozl(a)laptop.org> wrote: > G'day, > > I'm an Open Firmware developer working for One Laptop per Child. > > We have used the MX25U3235E chip in revision B1 of our XO-4 design, > and I am trying to use flashrom (r1657) with a Bus Pirate to read from > a chip. > > I see you pushed a patch for this chip in the past few days. A happy > coincidence perhaps. > > Is there anything I can do to help you change TEST_UNTESTED to > something else? > > (Sorry if this is an obvious question, but I have very little > knowledge of flashrom, having used for the first time yesterday with a > different chip. Mostly we program the chip from within Open > Firmware.) > > I changed TEST_UNTESTED to TEST_OK_PR on my system, and captured the > attached logs. > > While the identify worked, the read gave errors, and the output file > contained 0xff only. We have never intentionally enabled any block > protection on this chip. > Hello James, the .tested field is only used for QA and telling the user about it. Changing it does not influence functionality. If you are in a hurry skip this paragraph. :) I am a bit puzzled at the moment regarding the (read) log. If you look at the detailed output of the contents of the status register at line 132 ff. you see that flashrom (mistakenly) reads 0xFF, which leads to the assumption that a block protection is enabled (see bottom of page 26 in the datasheet of the chip; that's quite a standard layout of a SPI flash status register...). It then tries to disable the "protection" and fails because another bit in the status register - the WIP bit - remains at 1. I have no idea why it (always) reads 0xFF from the status register... I have checked the opcode and it is correct, and there is nothing fancy about... apart from one thing I just noticed which you could test: in spi_read_status_register() in spi25_statusreg.c replace 2 with 1 in the array declaration readarr[2] so that this line becomes unsigned char readarr[1]; /* JEDEC_RDSR_INSIZE=1 but wbsio needs 2 */ wbsio is our driver for a very annoying winbond SPI master and as the fixme in the function says, this hack should not be in the generic code. If the macronix chip does not repeat the status register contents when one reads more than one byte after sending the RDSR (read status register) opcode (which chips usually do) but 0xFF then we have found the culprit. PS: please send further mails to flashrom(a)flashrom.org - our mailing list, thanks. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

Re: [flashrom] [PATCH] Add support for Fujitsu MBM29LV160BE/TE.
by Stefan Tauner Aug. 25, 2013

Aug. 25, 2013

On Sat, 10 Aug 2013 03:57:49 +0200 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> The user did not respond on IRC... let's merge it untested. Self-acked and committed in r1722. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[commit] r1722 - trunk
by repository service Aug. 25, 2013

Aug. 25, 2013

Author: stefanct Date: Sun Aug 25 15:31:43 2013 New Revision: 1722 URL: http://flashrom.org/trac/flashrom/changeset/1722 Log: Add support for Fujitsu MBM29LV160BE/TE. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/flashchips.c trunk/flashchips.h Modified: trunk/flashchips.c ============================================================================== --- trunk/flashchips.c Sun Aug 25 02:10:56 2013 (r1721) +++ trunk/flashchips.c Sun Aug 25 15:31:43 2013 (r1722) @@ -4580,6 +4580,70 @@ }, { + .vendor = "Fujitsu", + .name = "MBM29LV160BE", + .bustype = BUS_PARALLEL, + .manufacture_id = FUJITSU_ID, + .model_id = FUJITSU_MBM29LV160BE, + .total_size = 2 * 1024, + .page_size = 0, + .feature_bits = FEATURE_ADDR_SHIFTED | FEATURE_SHORT_RESET, + .tested = TEST_UNTESTED, + .probe = probe_m29f400bt, + .probe_timing = TIMING_IGNORED, + .block_erasers = + { + { + .eraseblocks = { + {16 * 1024, 1}, + {8 * 1024, 2}, + {32 * 1024, 1}, + {64 * 1024, 31}, + }, + .block_erase = block_erase_m29f400bt, + }, { + .eraseblocks = { {2048 * 1024, 1} }, + .block_erase = block_erase_chip_m29f400bt, + }, + }, + .write = write_m29f400bt, /* Supports a fast mode too */ + .read = read_memmapped, + .voltage = {3000, 3600}, /* 3.0-3.6V for type -70, others 2.7-3.6V */ + }, + + { + .vendor = "Fujitsu", + .name = "MBM29LV160TE", + .bustype = BUS_PARALLEL, + .manufacture_id = FUJITSU_ID, + .model_id = FUJITSU_MBM29LV160TE, + .total_size = 2 * 1024, + .page_size = 0, + .feature_bits = FEATURE_ADDR_SHIFTED | FEATURE_SHORT_RESET, + .tested = TEST_UNTESTED, + .probe = probe_m29f400bt, + .probe_timing = TIMING_IGNORED, + .block_erasers = + { + { + .eraseblocks = { + {64 * 1024, 31}, + {32 * 1024, 1}, + {8 * 1024, 2}, + {16 * 1024, 1}, + }, + .block_erase = block_erase_m29f400bt, + }, { + .eraseblocks = { {2048 * 1024, 1} }, + .block_erase = block_erase_chip_m29f400bt, + }, + }, + .write = write_m29f400bt, /* Supports a fast mode too */ + .read = read_memmapped, + .voltage = {3000, 3600}, /* 3.0-3.6V for type -70, others 2.7-3.6V */ + }, + + { .vendor = "GigaDevice", .name = "GD25LQ32", .bustype = BUS_SPI, Modified: trunk/flashchips.h ============================================================================== --- trunk/flashchips.h Sun Aug 25 02:10:56 2013 (r1721) +++ trunk/flashchips.h Sun Aug 25 15:31:43 2013 (r1722) @@ -332,6 +332,8 @@ #define FUJITSU_MBM29LV400TC 0xB9 #define FUJITSU_MBM29LV800BA 0x5B /* Same as MBM29LV800BE */ #define FUJITSU_MBM29LV800TA 0xDA /* Same as MBM29LV800TE */ +#define FUJITSU_MBM29LV160BE 0x49 /* 16 b mode 0x2249 */ +#define FUJITSU_MBM29LV160TE 0xC4 /* 16 b mode 0x22C4 */ #define GIGADEVICE_ID 0xC8 /* GigaDevice */ #define GIGADEVICE_GD25T80 0x3114

1 0

[PATCH] libpayload: By default build libflashrom.a instead of flashrom.
by Stefan Tauner Aug. 25, 2013

Aug. 25, 2013

flashrom won't built nor run as native payload very soon (or ever). This patch changes a special GNU make variable that allows to select the default goal which is taken if no goal is given explicitly on the command line. Normally this would be the first rule in Makefile, i.e. all. This won't compile if the target OS is libpayload, hence change it to "libflashrom.a" in that case. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- refined version to make old men happy by not breaking even older build hosts. Makefile | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Makefile b/Makefile index 3b24bc4..b992790 100644 --- a/Makefile +++ b/Makefile @@ -218,6 +218,16 @@ endif endif ifeq ($(TARGET_OS), libpayload) +# We want to build libflashrom.a by default here. To override the default target we need the special GNU make +# variable DEFAULT_GOAL which is available since 3.81. To support building on ancient hosts check this first. +min_version_needed := 3.81 +ok := $(filter $(min_version_needed), $(firstword $(sort $(MAKE_VERSION) $(min_version_needed)))) +ifneq ($(ok),) +ifeq ($(MAKECMDGOALS),) +.DEFAULT_GOAL := libflashrom.a +$(info Setting default goal to libflashrom.a) +endif +endif FLASHROM_CFLAGS += -DSTANDALONE ifeq ($(CONFIG_DUMMY), yes) UNSUPPORTED_FEATURES += CONFIG_DUMMY=yes -- Kind regards, Stefan Tauner

1 0

[commit] r1721 - trunk
by repository service Aug. 25, 2013

Aug. 25, 2013

Author: stefanct Date: Sun Aug 25 02:10:56 2013 New Revision: 1721 URL: http://flashrom.org/trac/flashrom/changeset/1721 Log: Makefile: Explain process of handling CONFIG_* variables. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Sat Aug 24 14:18:17 2013 (r1720) +++ trunk/Makefile Sun Aug 25 02:10:56 2013 (r1721) @@ -61,10 +61,13 @@ endif ############################################################################### -# General OS/architecture specific settings. +# General OS-specific settings. +# 1. Prepare for later by gathering information about host and target OS +# 2. Set compiler flags and parameters according to OSes +# 3. Likewise verify user-supplied CONFIG_* variables. # HOST_OS is only used to work around local toolchain issues. -HOST_OS ?= $(shell uname) +HOST_OS ?= $(shell uname) ifeq ($(HOST_OS), MINGW32_NT-5.1) # Explicitly set CC = gcc on MinGW, otherwise: "cc: command not found". CC = gcc @@ -263,6 +266,10 @@ endif endif +############################################################################### +# General architecture-specific settings. +# Like above for the OS, below we verify user-supplied options depending on the target architecture. + # Determine the destination processor architecture. # IMPORTANT: The following line must be placed before ARCH is ever used # (of course), but should come after any lines setting CC because the line @@ -334,6 +341,9 @@ SVNDEF := -D'FLASHROM_VERSION="$(VERSION)"' +############################################################################### +# Default settings of CONFIG_* variables. + # Always enable internal/onboard support for now. CONFIG_INTERNAL ?= yes @@ -426,6 +436,7 @@ ############################################################################### # Programmer drivers and programmer support infrastructure. +# Depending on the CONFIG_* variables set and verified above we set compiler flags and parameters below. FEATURE_CFLAGS += -D'CONFIG_DEFAULT_PROGRAMMER=$(CONFIG_DEFAULT_PROGRAMMER)'

1 0

[PATCH] libpayload: By default build libflashrom.a instead of flashrom.
by Stefan Tauner Aug. 25, 2013

Aug. 25, 2013

flashrom won't built nor run as native payload very soon (or ever). This patch changes a special GNU make variable that allows to select the default goal which is taken if no goal is given explicitly on the command line. Normally this would be the first rule in Makefile, i.e. all. This won't compile if the target OS is libpayload, hence change it to "libflashrom.a" in that case. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 023c41d..e6834a3 100644 --- a/Makefile +++ b/Makefile @@ -215,6 +215,10 @@ endif endif ifeq ($(TARGET_OS), libpayload) +ifeq ($(MAKECMDGOALS),) +.DEFAULT_GOAL := libflashrom.a +$(info Setting default goal to libflashrom.a) +endif FLASHROM_CFLAGS += -DSTANDALONE ifeq ($(CONFIG_DUMMY), yes) UNSUPPORTED_FEATURES += CONFIG_DUMMY=yes -- Kind regards, Stefan Tauner

1 0

Re: [flashrom] Fwd: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash
by Антон Кочков Aug. 24, 2013

Aug. 24, 2013

Please, attach exact/full logs of this error. Best regards, Anton Kochkov. On Sat, Aug 24, 2013 at 10:30 PM, Beeblebrox <zaphod(a)berentweb.com> wrote: > Hello. as follow-up to recent discussion with your mail list, I would like > to share the following correspondence from the FreeDOS mail list. > > My Question re below info: Is it possible to use FLASHROM as advised below > (USB drive) when infact it's not working from full OS environment? I think > it is NOT possible, but want your confirmation. > > BTW, I also booted into Ubuntu-Linux and tried the same flash - I get the > same err as I did from FreeBSD O/S. > > > On Sat, Aug 24, 2013 at 8:10 PM, Beeblebrox <zaphod(a)berentweb.com> wrote: > I want to update system BIOS using USB Flash. The USB drive has grub2 > installed, I use it as a rescue drive & I can add menu items however I like. > I am able to boot into FreeDOS from grub2 this way: > linux16 (hd0,1)/boot/memdisk raw > linux16 (hd0,1)/boot/FDOEM.144 > When I boot into FreeDOS, only the contents of the mem-loaded image file > (FDOEM.144) are visible. All the tutorials I have found confirm this > behaviour by instructions to add BIOS-update-files into the FDOEM.144 file, > so that the BIOS update files become available in the memory-file > environment. > MY QUESTION: Would it be possible to provide access from the FreeDOS > mem-file environment to a folder on the USB drive? This way, one would boot > into FreeDOS from grub2, chdir to the folder route defined in the FreeDOS > config.sys (?) and run the dos-biosupdate.exe. If this is possible, one > would just copy the BIOS files into the defined folder and be done with it. > Instead, with current definitions one mnust loop-mount FDOEM.144, copy the > BIOS files into a sub-folder, unmount FDOEM.144 and copy it to the USB > drive. > > > From: Антон Кочков <anton.kochkov(a)gmail.com> > Date: Sat, Aug 24, 2013 at 8:49 PM > Subject: Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash > To: zaphod(a)berentweb.com, "Discussion and general questions about FreeDOS." > <freedos-user(a)lists.sourceforge.net> > > > Hello! > You can try to use flashrom (http://flashrom.org) utility for that. > See download link http://ra.openbios.org/~idwer/flashrom/dos - version > for DOS > Best regards, > Anton Kochkov. > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom

1 0

Fwd: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash
by Beeblebrox Aug. 24, 2013

Aug. 24, 2013

Hello. as follow-up to recent discussion with your mail list, I would like to share the following correspondence from the FreeDOS mail list. My Question re below info: Is it possible to use FLASHROM as advised below (USB drive) when infact it's not working from full OS environment? I think it is NOT possible, but want your confirmation. BTW, I also booted into Ubuntu-Linux and tried the same flash - I get the same err as I did from FreeBSD O/S. On Sat, Aug 24, 2013 at 8:10 PM, Beeblebrox <zaphod(a)berentweb.com> wrote: I want to update system BIOS using USB Flash. The USB drive has grub2 installed, I use it as a rescue drive & I can add menu items however I like. I am able to boot into FreeDOS from grub2 this way: linux16 (hd0,1)/boot/memdisk raw linux16 (hd0,1)/boot/FDOEM.144 When I boot into FreeDOS, only the contents of the mem-loaded image file (FDOEM.144) are visible. All the tutorials I have found confirm this behaviour by instructions to add BIOS-update-files into the FDOEM.144 file, so that the BIOS update files become available in the memory-file environment. MY QUESTION: Would it be possible to provide access from the FreeDOS mem-file environment to a folder on the USB drive? This way, one would boot into FreeDOS from grub2, chdir to the folder route defined in the FreeDOS config.sys (?) and run the dos-biosupdate.exe. If this is possible, one would just copy the BIOS files into the defined folder and be done with it. Instead, with current definitions one mnust loop-mount FDOEM.144, copy the BIOS files into a sub-folder, unmount FDOEM.144 and copy it to the USB drive. From: Антон Кочков <anton.kochkov(a)gmail.com> Date: Sat, Aug 24, 2013 at 8:49 PM Subject: Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash To: zaphod(a)berentweb.com, "Discussion and general questions about FreeDOS." <freedos-user(a)lists.sourceforge.net> Hello! You can try to use flashrom (http://flashrom.org) utility for that. See download link http://ra.openbios.org/~idwer/flashrom/dos - version for DOS Best regards, Anton Kochkov.

1 0