flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Proposed changes to flashrom hosting and workflow
by David Hendricks 07 Aug '15

07 Aug '15

For those who missed it on IRC, Stefan (Reinauer) has proposed retiring SVN and patch work in favor of Git and (likely) Gerrit + Jenkins. Maintaining SVN and Patchwork represents a surprisingly large maintenance burden on top of Git and Gerrit that coreboot uses. Additionally, many in the community work around SVN's limitations by mirroring the project at places like Github anyway. Stefan put up a Doodle poll here to hear out comments/concerns: http://doodle.com/p2dxtnksmsgwmzrq -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

ease projects task 1.1 find chips without voltage data
by sven.waldecker＠mail.de 04 Aug '15

04 Aug '15

Hello Flashrom members, i want to support the Flashrom project i was reading the easy projects page and want to do Task 1.1 "Find chips without voltage data". Ive read the flashchips.c hello flashrom.org members, i complete the voltage ranges in flashchips.c at the moment the INTEL_28F002BL-T VCC is available in a 3.3 Volt and in a 3.3 Volt Version. should i create two structs one for the 3.3 Volt and the other one for 5 Volt type ? best regards Sven ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

2 1

Re: [flashrom] dediprog: Use command 0x0B only on older SF100s
by David Woodhouse 04 Aug '15

04 Aug '15

On Tue, 2015-08-04 at 00:37 -0700, David Hendricks wrote: > > > On Mon, Aug 3, 2015 at 4:50 PM, David Woodhouse <dwmw2(a)infradead.org> > wrote: > > On Sun, 2015-08-02 at 15:09 -0700, David Hendricks wrote: > > > Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent > > patches) > > > > Where are these subsequent patches of which you speak? I have SF600 > > testers who would be happy to try them out... > I was just referring to the earlier patches that you and Stefan had > posted earlier (based off Simon Glass's work): > http://www.flashrom.org/pipermail/flashrom/2015-July/013759.html Hm. I could have sworn I'd tried simply disabling the call to dediprog_device_init(), and my SF600Plus tester (FW 7.1.1) still told me it wasn't working — or that it was working for reads but not erase/writes. Am I missing something more that your patch does? > <insert rant about SCM and code review process> Yeah. FWIW my set of patches is at http://git.infradead.org/users/dwmw2/flashrom.git — it's not *impossible* to work sanely, even if you are stuck with a project which for some reason is still stuck in the 20th century with Subversion. -- dwmw2

1 0

New programmer board "SPI_TT LPT" support - patch submission
by Max 04 Aug '15

04 Aug '15

Hello, everybody, involved into flashrom! I'd implemented support for well known in Russia SPI_TT LPT programmer. Basically, it's only Byteblaster clone with changed pinout. So, modifications was pretty straIghtforward. In attach - modified "rayer_spi.c" from trunk branch. Hope, it will be useful for someone. Best regards, Max Arephin.

1 0

Re: [flashrom] dediprog: Use command 0x0B only on older SF100s
by David Woodhouse 04 Aug '15

04 Aug '15

On Sun, 2015-08-02 at 15:09 -0700, David Hendricks wrote: > Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches) Where are these subsequent patches of which you speak? I have SF600 testers who would be happy to try them out... -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation

2 1

dediprog: Use command 0x0B only on older SF100s
by David Hendricks 03 Aug '15

03 Aug '15

As per e-mail with Dediprog, command 0x0B (which is not listed in the command spec) is used to set voltage level on older Dediprogs. SF100 V6.0.0 and newer as well as all SF600 programmers do not support it. This patch renames dediprog_device_init() to something more appropriate and adds comments for clarity, and only runs it conditionally if we cannot query the devicestring during init. Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches) Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Index: dediprog.c =================================================================== --- dediprog.c (revision 1896) +++ dediprog.c (working copy) @@ -75,6 +75,7 @@ CMD_READ_PROG_INFO = 0x08, CMD_SET_VCC = 0x09, CMD_SET_STANDALONE = 0x0A, + CMD_SET_VOLTAGE = 0x0B, /* Only in firmware older than 6.0.0 */ CMD_GET_BUTTON = 0x11, CMD_GET_UID = 0x12, CMD_SET_CS = 0x14, @@ -579,13 +580,15 @@ return 0; } -static int dediprog_device_init(void) +/* Only use dediprog_set_voltage on SF100 programmers with firmware older + * than V6.0.0. Newer programmers (including all SF600s) do not support it. */ +static int dediprog_set_voltage(void) { int ret; char buf[0x1]; memset(buf, 0, sizeof(buf)); - ret = usb_control_msg(dediprog_handle, REQTYPE_OTHER_IN, 0x0B, 0x0, 0x0, + ret = usb_control_msg(dediprog_handle, REQTYPE_OTHER_IN, CMD_SET_VOLTAGE, 0x0, 0x0, buf, 0x1, DEFAULT_TIMEOUT); if (ret < 0) { msg_perr("Command A failed (%s)!\n", usb_strerror()); @@ -595,6 +598,7 @@ msg_perr("Unexpected response to init!\n"); return 1; } + return 0; } @@ -853,11 +857,15 @@ if (register_shutdown(dediprog_shutdown, NULL)) return 1; - /* Perform basic setup. */ - if (dediprog_device_init()) - return 1; - if (dediprog_check_devicestring()) - return 1; + /* Try reading the devicestring. If that fails and the device is old + * (FW < 6.0.0) then we need to try the "set voltage" command and then + * attempt to read the devicestring again. */ + if (dediprog_check_devicestring()) { + if (dediprog_set_voltage()) + return 1; + if (dediprog_check_devicestring()) + return 1; + } /* Set all possible LEDs as soon as possible to indicate activity. * Because knowing the firmware version is required to set the LEDs correctly we need to this after

1 0

Re: [flashrom] [PATCH 1/3] dediprog: Fix dediprog_device_init()
by David Hendricks 02 Aug '15

02 Aug '15

Hmmm, on second thoughts my other 2 patches were basically just rebasing the other patches to add new protocol support and add basic SF600 support. No need to re-hash them. Just apply this along with the other two patches and SF600 should work (reads, not writes). On Sat, Aug 1, 2015 at 6:07 PM, David Hendricks <dhendrix(a)chromium.org> wrote: > As per e-mail with Dediprog, command 0x0B (which is not listed in the > command spec) is used to set voltage level on older Dediprogs. SF100 > V6.0.0 and newer as well as all SF600 programmers do not support it. > > This patch renames the function and adds comments for clarity, and > only runs it conditionally if we cannot query the devicestring during > init. > > Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches). > Signed-off-by: David Hendricks <dhendrix(a)chromium.org> > > Index: dediprog.c > =================================================================== > --- dediprog.c (revision 1896) > +++ dediprog.c (working copy) > @@ -75,6 +75,7 @@ > CMD_READ_PROG_INFO = 0x08, > CMD_SET_VCC = 0x09, > CMD_SET_STANDALONE = 0x0A, > + CMD_SET_VOLTAGE = 0x0B, /* Only in firmware older than 6.0.0 */ > CMD_GET_BUTTON = 0x11, > CMD_GET_UID = 0x12, > CMD_SET_CS = 0x14, > @@ -579,13 +580,15 @@ > return 0; > } > > -static int dediprog_device_init(void) > +/* Only use dediprog_set_voltage on SF100 programmers with firmware older > + * than V6.0.0. Newer programmers (including all SF600s) do not support it. */ > +static int dediprog_set_voltage(void) > { > int ret; > char buf[0x1]; > > memset(buf, 0, sizeof(buf)); > - ret = usb_control_msg(dediprog_handle, REQTYPE_OTHER_IN, 0x0B, 0x0, 0x0, > + ret = usb_control_msg(dediprog_handle, REQTYPE_OTHER_IN, > CMD_SET_VOLTAGE, 0x0, 0x0, > buf, 0x1, DEFAULT_TIMEOUT); > if (ret < 0) { > msg_perr("Command A failed (%s)!\n", usb_strerror()); > @@ -595,6 +598,7 @@ > msg_perr("Unexpected response to init!\n"); > return 1; > } > + > return 0; > } > > @@ -853,11 +857,15 @@ > if (register_shutdown(dediprog_shutdown, NULL)) > return 1; > > - /* Perform basic setup. */ > - if (dediprog_device_init()) > - return 1; > - if (dediprog_check_devicestring()) > - return 1; > + /* Try reading the devicestring. If that fails and the device is old > + * (FW < 6.0.0) then we need to try the "set voltage" command and then > + * attempt to read the devicestring again. */ > + if (dediprog_check_devicestring()) { > + if (dediprog_set_voltage()) > + return 1; > + if (dediprog_check_devicestring()) > + return 1; > + } > > /* Set all possible LEDs as soon as possible to indicate activity. > * Because knowing the firmware version is required to set the LEDs > correctly we need to this after

1 0

[PATCH 1/3] dediprog: Fix dediprog_device_init()
by David Hendricks 02 Aug '15

02 Aug '15

As per e-mail with Dediprog, command 0x0B (which is not listed in the command spec) is used to set voltage level on older Dediprogs. SF100 V6.0.0 and newer as well as all SF600 programmers do not support it. This patch renames the function and adds comments for clarity, and only runs it conditionally if we cannot query the devicestring during init. Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches). Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Index: dediprog.c =================================================================== --- dediprog.c (revision 1896) +++ dediprog.c (working copy) @@ -75,6 +75,7 @@ CMD_READ_PROG_INFO = 0x08, CMD_SET_VCC = 0x09, CMD_SET_STANDALONE = 0x0A, + CMD_SET_VOLTAGE = 0x0B, /* Only in firmware older than 6.0.0 */ CMD_GET_BUTTON = 0x11, CMD_GET_UID = 0x12, CMD_SET_CS = 0x14, @@ -579,13 +580,15 @@ return 0; } -static int dediprog_device_init(void) +/* Only use dediprog_set_voltage on SF100 programmers with firmware older + * than V6.0.0. Newer programmers (including all SF600s) do not support it. */ +static int dediprog_set_voltage(void) { int ret; char buf[0x1]; memset(buf, 0, sizeof(buf)); - ret = usb_control_msg(dediprog_handle, REQTYPE_OTHER_IN, 0x0B, 0x0, 0x0, + ret = usb_control_msg(dediprog_handle, REQTYPE_OTHER_IN, CMD_SET_VOLTAGE, 0x0, 0x0, buf, 0x1, DEFAULT_TIMEOUT); if (ret < 0) { msg_perr("Command A failed (%s)!\n", usb_strerror()); @@ -595,6 +598,7 @@ msg_perr("Unexpected response to init!\n"); return 1; } + return 0; } @@ -853,11 +857,15 @@ if (register_shutdown(dediprog_shutdown, NULL)) return 1; - /* Perform basic setup. */ - if (dediprog_device_init()) - return 1; - if (dediprog_check_devicestring()) - return 1; + /* Try reading the devicestring. If that fails and the device is old + * (FW < 6.0.0) then we need to try the "set voltage" command and then + * attempt to read the devicestring again. */ + if (dediprog_check_devicestring()) { + if (dediprog_set_voltage()) + return 1; + if (dediprog_check_devicestring()) + return 1; + } /* Set all possible LEDs as soon as possible to indicate activity. * Because knowing the firmware version is required to set the LEDs correctly we need to this after

1 0

Re: [flashrom] Not detecting Am29F010 using 3Com PCI nic
by Ignatius Grippa 01 Aug '15

01 Aug '15

1 0

Re: [flashrom] Not detecting Am29F010 using 3Com PCI nic
by Idwer Vollering 30 Jul '15

30 Jul '15

2015-07-29 20:38 GMT+02:00 Ignatius Grippa <ignatiusgrippa(a)gmx.com>: > Hello, > > First time posting. > > I cannot get my Am29F010 EEPROM recognized by flashrom v0.9.8-r1889 That chip *should* be detected: http://www.flashrom.org/Supported_hardware#Supported_flash_chips > > I'm using a 3Com PCI ethernet card (3C90xB) that recognizes the EEPROM > using a different program "bromutil" So what does [b|c|oc]romutil [1] do what the code in flashrom's nic3com.c doesn't do? http://git.etherboot.org/gpxe.git/tree/90bffed805ec453d2f75e61157b73eb2bb6b… > I've also tested my 3Com using a different chip AT29C010 which is recognized > & reads/writes with flashrom so I think it must be a software issue with the > AMD. > > I can get flashrom to read the AMD to a file if I do a force -f -c > Am29F010A/B but no write because it's not recognized. Forcing shouldn't be necessary... > I've attached my log. Seems flashrom is not reading the id codes correctly > for the AMD. Instead it reads the first 2 bytes of info stored on the chip > (4c ef in the log) However, probing for Atmel and many others retrieves the > correct manufacturer/model id codes for the AM29F010 which is 01 20 > > Any clue what might be happening? Thanks very much. > > Dave > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom