flashrom

flashrom@flashrom.org

3 participants
9188 discussions

[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

Codes for noobs
by Thomas Saunders 05 Mar '12

05 Mar '12

Hi there :) We are building a mushroom farm out here in Denmark and were just wondering whether it was possible to change a chips code? We need the minimum temperature raised in the code. The chip itself is a G80F910C. Any help, however brief, is very much appreciated! Best wishes Thomas Saunders Danske Shiitake Hjelmagervej 7 8541 Skødstrup Danmark Tel: +4553144423 CVR: 33278721

1 0

Re: [flashrom] Ubuntu daily builds PPA
by Stefan Tauner 05 Mar '12

05 Mar '12

On Sun, 4 Mar 2012 15:00:08 -0800 Svetoslav Trochev <svetoslav.trochev(a)gmail.com> wrote: > On Sun, Mar 4, 2012 at 2:23 PM, Stefan Tauner > <stefan.tauner(a)student.tuwien.ac.at> wrote: > > On Sun, 4 Mar 2012 14:05:20 -0800 > > Svetoslav Trochev <svetoslav.trochev(a)gmail.com> wrote: > > > >> > i have setup a flashrom poject at http://launchpad.net/flashrom which > >> > auto-imports the svn every 6 hours and a package archive at > >> > http://launchpad.net/~flashrom-developers/+archive/flashrom-daily > >> > where new binaries are generated once a day whenever the svn has > >> > changed. > >> I found about daily PPA about couple days ago here: > >> http://flashrom.org/Downloads. And used it to collect data from > >> several boards. Is there plan to update the wiki page with info about > >> the new PPA? > > > > jup, i have updated the wiki page before sending the "announce" mail. > > what information do you think is missing/should be added? > > > > -- > > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > Ok. I was a bit confused as new person to the project. > There are 4 links: (package overview) [1], (questions) [2], (bugreports) [3] > Let say, I am using Ubuntu 10.04LTS and I want to download and install > latest well tested (stable) version of flashrom. I tried the first > link and there only can see version: 0.9.1+r946-1ubuntu1. > Next two links didn't help at all. Finally I found the > 0.9.5.1+r1508-1-20120303~lucid1 version in daily build PPA [4]. I > don't know how the releases are handled, but my experience is that > most of the daily PPAs brake without any notice. This made me quite > uncomfortable to flash M/B using daily build version. I am sure that I > sound quite stupid right now, but I hope that we can provide a bit > more clear picture how the binaries for Ubuntu are maintained and what > version should be used. I hope that this small improvement will lower > the barrier for entrance of new people and help flashrom project as > whole. > > [1] http://launchpad.net/ubuntu/+source/flashrom > [2] http://answers.launchpad.net/ubuntu/+source/flashrom/+questions?field.statu… > [3] http://bugs.launchpad.net/ubuntu/+source/flashrom/+bugs?field.status:list=N… > [4] http://code.launchpad.net/~flashrom-developers/+archive/flashrom-daily thanks for the verbose explanation! i have removed the answers and bugs links (nice idea of whoever added them, but i don't think they are useful. ubuntu users should be able to follow the links on the package overview page to that sections) and i have added more detail to the PPA description and the safety of the binaries. lowering the barrier for new and unexperienced ubuntu users might not necessarily help flashrom on the whole nor those users ;) if they are unsure they should ask us first. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] Zotac ZBOX-AD02-PLUS-U: System Testing
by Stefan Tauner 04 Mar '12

04 Mar '12

On Sat, 3 Mar 2012 16:05:11 -0800 Svetoslav Trochev <svetoslav.trochev(a)gmail.com> wrote: > Hi Everyone, > > I just tested (read-only) one more system: Zotac ZBOX-AD02-PLUS-U. I > am attaching the output files. Hello, and thanks for your mail. read tests are only useful in some cases (e.g. untested chips), for testing full board support we need a erase/write cycle. that does not mean that you should now erase your chip immediately, but the log as such does not help. if you ever try to update the firmware on that board on the other hand please send us a note. > I have question. Should I be concern very much about "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)."? > > I suspect this is about the UEFI secure boot option where the keys > are( or would) be stored. Is this correct? we can neither confirm nor deny this presumption. seriously... no that has nothing to do with secure boot afaik. these chips are used in many other devices not just PCs. the OTP area is usually just a few dozen bytes large, which might be enough for a few key hashes or so, but i doubt anyone would use them for this. it is just a feature to store a few bytes forever* and is probably only used in a few embedded devices. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] Ubuntu daily builds PPA
by Stefan Tauner 04 Mar '12

04 Mar '12

On Sun, 4 Mar 2012 14:05:20 -0800 Svetoslav Trochev <svetoslav.trochev(a)gmail.com> wrote: > > i have setup a flashrom poject at http://launchpad.net/flashrom which > > auto-imports the svn every 6 hours and a package archive at > > http://launchpad.net/~flashrom-developers/+archive/flashrom-daily > > where new binaries are generated once a day whenever the svn has > > changed. > I found about daily PPA about couple days ago here: > http://flashrom.org/Downloads. And used it to collect data from > several boards. Is there plan to update the wiki page with info about > the new PPA? jup, i have updated the wiki page before sending the "announce" mail. what information do you think is missing/should be added? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Ubuntu daily builds PPA
by Stefan Tauner 04 Mar '12

04 Mar '12

Hi, i have setup a flashrom poject at http://launchpad.net/flashrom which auto-imports the svn every 6 hours and a package archive at http://launchpad.net/~flashrom-developers/+archive/flashrom-daily where new binaries are generated once a day whenever the svn has changed. currently there is a bug in launchpad itself that makes it impossible to use version 0.4 recipes (recipes are used to configure the autobuilders). this is the reason the package names are a bit awkward (e.g. 0.9.5.1+r1508-1-20120303 for svn r1512). it is basically named by {debversion}-{date}. it is the best i could come up with, that indicates the included source in at least some way (date), will upgrade to newer ubuntu versions when they become available and actually build in current launchpad. another problem is that the autobuilt binaries will output this: flashrom v0.9.5.1-runknown on Linux 2.6.35-32-generic (x86_64), built with libpci 3.1.7, GCC 4.4.5, little endian i.e. no svn revision. the only way to work around this would be a second svn tree with an already (auto-)exported version of flashrom... if we could manage to set that up, we could probably build our own package too without launchpad :) maybe it is useful anyway for someone... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 3

Re: [flashrom] Raspberry Pi support as a programmer
by Carl-Daniel Hailfinger 04 Mar '12

04 Mar '12

Hi cemede, Am 04.03.2012 14:20 schrieb cmd_: > Recently has appeared a ultra-cheap board named Raspberry Pi (perhaps you > know http://www.raspberrypi.org/ ). This board has a powerful broadcom SoC > that comes with USB, UART, I2C, SPI, GPIO ports... all for 25/35$, awsome. > It could be a really versatile and powerful external/independent programmer > for flashrom! > > Just take a look here: http://elinux.org/RPi_Low-level_peripherals > > The SPI bus could be used to program SPI flash chips (obviously) and GPIO > for the other types. > I propose two ideas, first one, support the board by flashrom software, I already wrote a flashrom driver for the Raspberry Pi, I only need someone with hardware to test it. > second one, develop a daughter-board for the Raspberry-Pi to make a easy > use of all (with sockets to program IC's or some buffers if necessary for > other ones). I hope the Gertboard will accomplish some of that functionality. Designing our own PCB would be possible, sure, but my first focus is on getting the driver tested. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom