flashrom March 2012

flashrom@flashrom.org

46 participants
131 discussions

Start a nNew thread

Report for HP ProBook 4510s NX693EA for READ operation.
by user 09 Mar '12

09 Mar '12

Report for HP ProBook 4510s NX693EA for READ operation.

1 0

Re: [flashrom] FlashRom and Intel C204 chipset.
by Stefan Tauner 09 Mar '12

09 Mar '12

On Wed, 12 Oct 2011 22:01:01 +0400 "Andrey V. Bondarenko" <avbondarenko(a)gmail.com> wrote: > Hello, > > Verbose output is in the attachment file for chipset Intel C204. I sent this > e-mail because it was suggested to send report. > > # ./flashrom --read ./P8B-E-4L-ASUS-0602.ROM > flashrom v0.9.4-r1395 on Linux 2.6.18-274.3.1.el5.028stab094.3 (x86_64), > built with libpci 3.1.7, GCC 4.1.2 20080704 (Red Hat 4.1.2-51), little > endian > flashrom is free software, get the source code at http://www.flashrom.org > > Calibrating delay loop... OK. > Found chipset "Intel C204". > This chipset is marked as untested. If you are using an up-to-date version > of flashrom please email a report to flashrom(a)flashrom.org including a > verbose (-V) log. Thank you! > Enabling flash write... OK. > This chipset supports the following protocols: FWH, SPI. > Found Winbond flash chip "W25Q64" (8192 kB, SPI) at physical address > 0xff800000. > Reading flash... Transaction error! > Read operation failed! > FAILED. hello and thanks for your report. this is another case of a locked Management Engine (ME) region, which we can't unlock yet. i have added the P8B-E/4L to our list of boards with a note about the problem for now and will commit that later. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Report for chipset "Intel Q67" on a GA-Q67M-D2H-B3 motheboard.
by user 09 Mar '12

09 Mar '12

Sorry for my previous report. Report for chipset "Intel Q67" on a GA-Q67M-D2H-B3 motheboard for READ operation.

1 0

working card
by RiCH ＠ gmail 09 Mar '12

09 Mar '12

rfm6@amd64:~/ipxe/src$ sudo flashrom -p nicintel flashrom v0.9.4-r1394 on Linux 3.0.0-12-generic (i686), built with libpci 3.1.7, GCC 4.6.1, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found "Intel 82557/8/9/0/1 Ethernet Pro 100" (8086:1229, BDF 04:08.0). === This PCI device is UNTESTED. Please report the 'flashrom -p xxxx' output to flashrom(a)flashrom.org if it works for you. Please add the name of your PCI device to the subject. Thank you for your help! === Found "Intel 82557/8/9/0/1 Ethernet Pro 100" (8086:1229, BDF 04:08.0). === This PCI device is UNTESTED. Please report the 'flashrom -p xxxx' output to flashrom(a)flashrom.org if it works for you. Please add the name of your PCI device to the subject. Thank you for your help! === Mapping Intel NIC control/status reg at 0xfdaff000, unaligned size 0x10. Found Atmel flash chip "AT49BV512" (64 kB, Parallel) on nicintel. No operations were specified. rfm6@amd64:~/ipxe/src$ sudo flashrom -p nicintel -w test.rom [sudo] password for rfm6: flashrom v0.9.4-r1394 on Linux 3.0.0-12-generic (i686), built with libpci 3.1.7, GCC 4.6.1, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found "Intel 82557/8/9/0/1 Ethernet Pro 100" (8086:1229, BDF 04:08.0). === This PCI device is UNTESTED. Please report the 'flashrom -p xxxx' output to flashrom(a)flashrom.org if it works for you. Please add the name of your PCI device to the subject. Thank you for your help! === Found "Intel 82557/8/9/0/1 Ethernet Pro 100" (8086:1229, BDF 04:08.0). === This PCI device is UNTESTED. Please report the 'flashrom -p xxxx' output to flashrom(a)flashrom.org if it works for you. Please add the name of your PCI device to the subject. Thank you for your help! === Mapping Intel NIC control/status reg at 0xfdaff000, unaligned size 0x10. Found Atmel flash chip "AT49BV512" (64 kB, Parallel) on nicintel. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED.

1 0

[PATCH] flashrom 0.9.5.1
by Carl-Daniel Hailfinger 08 Mar '12

08 Mar '12

Increase flashrom release number to 0.9.5.2 Informal ack by Stefan Tauner on IRC. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Index: flashrom-0.9.5.2-release/Makefile =================================================================== --- flashrom-0.9.5.2-release/Makefile (Revision 1513) +++ flashrom-0.9.5.2-release/Makefile (Arbeitskopie) @@ -277,7 +277,7 @@ # will not require subversion. The downloadable snapshots are already exported. SVNVERSION := $(shell LC_ALL=C svnversion -cn . 2>/dev/null | sed -e "s/.*://" -e "s/$[0-9]*$.*/\1/" | grep "[0-9]" || LC_ALL=C svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || LC_ALL=C git svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || echo unknown) -RELEASE := 0.9.5.1 +RELEASE := 0.9.5.2 VERSION := $(RELEASE)-r$(SVNVERSION) RELEASENAME ?= $(VERSION) -- http://www.hailfinger.org/

1 2

[commit] r1515 - tags/flashrom-0.9.5.2
by repository service 08 Mar '12

08 Mar '12

Author: hailfinger Date: Thu Mar 8 23:01:25 2012 New Revision: 1515 URL: http://flashrom.org/trac/flashrom/changeset/1515 Log: Tag flashrom 0.9.5.2 Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Added: tags/flashrom-0.9.5.2/ - copied from r1514, trunk/

1 0

[commit] r1514 - trunk
by repository service 08 Mar '12

08 Mar '12

Author: hailfinger Date: Thu Mar 8 22:58:40 2012 New Revision: 1514 URL: http://flashrom.org/trac/flashrom/changeset/1514 Log: Increase flashrom release number to 0.9.5.2 Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Tue Mar 6 23:17:06 2012 (r1513) +++ trunk/Makefile Thu Mar 8 22:58:40 2012 (r1514) @@ -277,7 +277,7 @@ # will not require subversion. The downloadable snapshots are already exported. SVNVERSION := $(shell LC_ALL=C svnversion -cn . 2>/dev/null | sed -e "s/.*://" -e "s/$[0-9]*$.*/\1/" | grep "[0-9]" || LC_ALL=C svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || LC_ALL=C git svn info . 2>/dev/null | awk '/^Revision:/ {print $$2 }' | grep "[0-9]" || echo unknown) -RELEASE := 0.9.5.1 +RELEASE := 0.9.5.2 VERSION := $(RELEASE)-r$(SVNVERSION) RELEASENAME ?= $(VERSION)

1 0

Realtek NIC (8169)
by Mark Brown 07 Mar '12

07 Mar '12

Wonder if there is a way to support the RTL8169 chipset, for SPI based programming. Very common and inexpensive card. Would be wonderful to support something like gPXE/iPXE PXE ROMs on those NICs. The typical 128kbit SPI rom/eprom/prom variations are often ATMEL or like. e.f. ATMEL518 93C64 Marc

1 0

Re: [flashrom] [PATCH] Prevent submission of empty read requests in linux_spi
by Stefan Tauner 06 Mar '12

06 Mar '12

On Sat, 3 Mar 2012 16:28:47 +0100 Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> wrote: > The submission of zero-sized read requests in a write-only transaction > fails at least for omap2_mcspi drivers and is pointless in general. > > Even with this patch, zero-sized write requests might be submitted for > read-only transactions, but for most SPI chips, there always is a command > transferred (written) before reading data, so there is no such thing as > a pure-read transaction. maybe we should nevertheless guard against that with an if (readcnt != 0 && writecnt == 0) return SPI_INVALID_LENGTH; or so? > > Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> > --- > linux_spi.c | 10 +++++++++- > 1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/linux_spi.c b/linux_spi.c > index d994389..3d1ca3e 100644 > --- a/linux_spi.c > +++ b/linux_spi.c > @@ -114,6 +114,7 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, > const unsigned char *txbuf, > unsigned char *rxbuf) > { > + unsigned iocontrol_code; hm... afaics ioctl commands are always exactly 32b wide. naive kernel newbie question: why not use uint32_t? if there is a reason against that, please add "int" at least to match the rest of our code base. > struct spi_ioc_transfer msg[2] = { > { > .tx_buf = (uint64_t)(ptrdiff_t)txbuf, > @@ -128,7 +129,14 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, > if (fd == -1) > return -1; > > - if (ioctl(fd, SPI_IOC_MESSAGE(2), msg) == -1) { > + /* Just submit the first (write) request in case there is nothing > + to read. Otherwise submit both requests */ missing full stop, if one likes to nitpick... :) (in the subject too btw). > + if (readcnt == 0) > + iocontrol_code = SPI_IOC_MESSAGE(1); > + else > + iocontrol_code = SPI_IOC_MESSAGE(2); > + > + if (ioctl(fd, iocontrol_code, msg) == -1) { > msg_cerr("%s: ioctl: %s\n", __func__, strerror(errno)); > return -1; > } if (ioctl(fd, SPI_IOC_MESSAGE((readcnt == 0) ? 1 : 2), msg) == -1) would work too i guess (it compiles on my machine at least), but it has disadvantages too. one could get rid of the first problem (correct type of IOC) by assigning 1 or 2 instead of the expanded SPI_IOC_MESSAGE(x) value to the local variable and use the macro in the argument list with the variable as parameter. i have no preference for any of those solutions... the posted one is fine too. regarding correctness i think it is ok too, although i have to admit that my review is probably not as thorough as carldani's would have been. i have looked at most of the macros involved; i have looked at spidev_ioctl and spidev_message and everything makes sense... since it's also tested on hardware i think it is good to go so it is... Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[commit] r1513 - trunk
by repository service 06 Mar '12

06 Mar '12

Author: mkarcher Date: Tue Mar 6 23:17:06 2012 New Revision: 1513 URL: http://flashrom.org/trac/flashrom/changeset/1513 Log: Prevent submission of empty read requests in linux_spi. The submission of zero-sized read requests in a write-only transaction fails at least for omap2_mcspi drivers and is pointless in general. This patch does not address the implementation of zero-sized writes (which would need to skip the write command), as there are no flash transactions not starting with a command. Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/linux_spi.c Modified: trunk/linux_spi.c ============================================================================== --- trunk/linux_spi.c Sat Mar 3 19:09:33 2012 (r1512) +++ trunk/linux_spi.c Tue Mar 6 23:17:06 2012 (r1513) @@ -130,6 +130,7 @@ const unsigned char *txbuf, unsigned char *rxbuf) { + int iocontrol_code; struct spi_ioc_transfer msg[2] = { { .tx_buf = (uint64_t)(ptrdiff_t)txbuf, @@ -143,8 +144,19 @@ if (fd == -1) return -1; + /* The implementation currently does not support requests that + don't start with sending a command. */ + if (writecnt == 0) + return SPI_INVALID_LENGTH; - if (ioctl(fd, SPI_IOC_MESSAGE(2), msg) == -1) { + /* Just submit the first (write) request in case there is nothing + to read. Otherwise submit both requests. */ + if (readcnt == 0) + iocontrol_code = SPI_IOC_MESSAGE(1); + else + iocontrol_code = SPI_IOC_MESSAGE(2); + + if (ioctl(fd, iocontrol_code, msg) == -1) { msg_cerr("%s: ioctl: %s\n", __func__, strerror(errno)); return -1; }

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom March 2012