flashrom

flashrom@flashrom.org

5 participants
9161 discussions

[PATCH] Handle insufficient DOS timer precision
by Carl-Daniel Hailfinger 04 Jun '10

04 Jun '10

Handle insufficient DOS timer precision by measuring a 100 ms delay instead of a 100 us delay. This should reduce the likelihood of flashrom timer complaints from 100% to 50%. If you want less complaints, use 1000 ms instead. This is mostly a proof of concept and I'd appreciate tests. Once I know which #defines to look for on MinGW and Cygwin, I can modify the #if to cover them as well. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-measure_delay_precision_dos/udelay.c =================================================================== --- flashrom-measure_delay_precision_dos/udelay.c (Revision 1008) +++ flashrom-measure_delay_precision_dos/udelay.c (Arbeitskopie) @@ -93,7 +93,19 @@ * a scheduler delay or something similar. */ for (i = 0; i < 4; i++) { - if (measure_delay(100) < 90) { +#if !defined(__DJGPP__) + timeusec = measure_delay(100); +#else + /* This zero delay workaround should be active for + * DOS and Windows and maybe libpayload. The criterion + * here is insufficient (worse than 100 us) OS timer + * resolution which will result in measure_delay(100)=0 + * whereas a longer delay (100 ms) will be sufficient + * to get a nonzero time measurement. + */ + timeusec = measure_delay(100000) / 1000; +#endif + if (timeusec < 90) { msg_pdbg("delay more than 10%% too short, " "recalculating... "); goto recalibrate; -- http://www.hailfinger.org/

3 5

[commit] r1001 - tags/flashrom-0.9.2
by repository service 04 Jun '10

04 Jun '10

Author: hailfinger Date: Wed May 19 18:55:43 2010 New Revision: 1001 URL: http://flashrom.org/trac/coreboot/changeset/1001 Log: Tag flashrom 0.9.2 Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Sean Nelson <audiohacked(a)gmail.com> Acked-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Acked-by: Luc Verhaegen <libv(a)skynet.be> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Added: tags/flashrom-0.9.2/ - copied from r1000, trunk/

3 3

[commit] r1028 - trunk
by repository service 03 Jun '10

03 Jun '10

Author: hailfinger Date: Thu Jun 3 23:48:13 2010 New Revision: 1028 URL: http://flashrom.org/trac/coreboot/changeset/1028 Log: Do not trust the OS at all and measure timer precision before calibrating the delay loop and use that measurement to get reasonable precision for our own delay code. Print a measurement for a delay of 4x the OS timer resolution. Be precise about how bad the deviation was if we had to recalculate. Tested on Windows XP, 32 bit, built using MinGW by Uwe. Tested on FreeDOS v1.0 Final, 32bit, built using DJGPP 4.3.2 by Idwer. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Idwer Vollering <vidwer+lists.flashrom(a)gmail.com> Modified: trunk/udelay.c Modified: trunk/udelay.c ============================================================================== --- trunk/udelay.c Thu Jun 3 18:35:51 2010 (r1027) +++ trunk/udelay.c Thu Jun 3 23:48:13 2010 (r1028) @@ -37,6 +37,30 @@ } } +unsigned long measure_os_delay_resolution(void) +{ + unsigned long timeusec; + struct timeval start, end; + unsigned long counter = 0; + + gettimeofday(&start, 0); + timeusec = 0; + + while (!timeusec && (++counter < 1000000000)) { + gettimeofday(&end, 0); + timeusec = 1000000 * (end.tv_sec - start.tv_sec) + + (end.tv_usec - start.tv_usec); + /* Protect against time going forward too much. */ + if ((end.tv_sec > start.tv_sec) && + ((end.tv_sec - start.tv_sec) >= LONG_MAX / 1000000 - 1)) + timeusec = 0; + /* Protect against time going backwards during leap seconds. */ + if ((end.tv_sec < start.tv_sec) || (timeusec > LONG_MAX)) + timeusec = 0; + } + return timeusec; +} + unsigned long measure_delay(int usecs) { unsigned long timeusec; @@ -61,10 +85,16 @@ void myusec_calibrate_delay(void) { unsigned long count = 1000; - unsigned long timeusec; + unsigned long timeusec, resolution; int i, tries = 0; msg_pinfo("Calibrating delay loop... "); + resolution = measure_os_delay_resolution(); + if (resolution) { + msg_pdbg("OS timer resolution is %u usecs, ", resolution); + } else { + msg_pinfo("OS timer resolution is unusable. "); + } recalibrate: count = 1000; @@ -94,9 +124,27 @@ * a scheduler delay or something similar. */ for (i = 0; i < 4; i++) { - if (measure_delay(100) < 90) { - msg_pdbg("delay more than 10%% too short, " - "recalculating... "); + if (resolution && (resolution < 10)) { + timeusec = measure_delay(100); + } else if (resolution && + (resolution < ULONG_MAX / 200)) { + timeusec = measure_delay(resolution * 10) * + 100 / (resolution * 10); + } else { + /* This workaround should be active for broken + * OS and maybe libpayload. The criterion + * here is horrible or non-measurable OS timer + * resolution which will result in + * measure_delay(100)=0 whereas a longer delay + * (1000 ms) may be sufficient + * to get a nonzero time measurement. + */ + timeusec = measure_delay(1000000) / 10000; + } + if (timeusec < 90) { + msg_pdbg("delay more than 10%% too short (got " + "%lu%% of expected delay), " + "recalculating... ", timeusec); goto recalibrate; } } @@ -113,6 +161,8 @@ msg_pdbg("1000 myus = %ld us, ", timeusec); timeusec = measure_delay(10000); msg_pdbg("10000 myus = %ld us, ", timeusec); + timeusec = measure_delay(resolution * 4); + msg_pdbg("%ld myus = %ld us, ", resolution * 4, timeusec); msg_pinfo("OK.\n"); }

1 0

[commit] r1027 - trunk
by repository service 03 Jun '10

03 Jun '10

Author: uwe Date: Thu Jun 3 18:35:51 2010 New Revision: 1027 URL: http://flashrom.org/trac/coreboot/changeset/1027 Log: Fix bug in wiki printing and whitespace (trivial). The required "-m" options were not in the wiki output due to a mistake that I think I introduced recently. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/print.c trunk/print_wiki.c Modified: trunk/print.c ============================================================================== --- trunk/print.c Thu Jun 3 02:49:50 2010 (r1026) +++ trunk/print.c Thu Jun 3 18:35:51 2010 (r1027) @@ -450,14 +450,14 @@ /* Please keep this list alphabetically ordered by vendor/board. */ const struct board_info laptops_known[] = { #if defined(__i386__) || defined(__x86_64__) - B("Acer", "Aspire 1520", 1, "http://support.acer.com/us/en/acerpanam/notebook/0000/Acer/Aspire1520/Aspir…", NULL), - B("Acer", "Aspire One", 0, NULL, "http://www.coreboot.org/pipermail/coreboot/2009-May/048041.html"), - B("ASUS", "Eee PC 701 4G",0, "http://www.asus.com/product.aspx?P_ID=h6SPd3tEzLEsrEiS", "It seems the chip (25X40VSIG) is behind some SPI flash translation layer (likely in the EC, the ENE KB3310)."), - B("Dell", "Latitude CPi A366XT",0, "http://www.coreboot.org/Dell_Latitude_CPi_A366XT", "The laptop immediately powers off if you try to hot-swap the chip. It's not yet tested if write/erase would work on this laptop."), - B("HP/Compaq", "nx9010", 0, "http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us…", "Hangs upon '''flashrom -V''' (needs hard power-cycle then)."), - B("IBM/Lenovo", "Thinkpad T40p",0, "http://www.thinkwiki.org/wiki/Category:T40p", NULL), - B("IBM/Lenovo", "240", 0, "http://www.stanford.edu/~bresnan//tp240.html", "Seems to (partially) work at first, but one block/sector cannot be written which then leaves you with a bricked laptop. Maybe this can be investigated and fixed in software later."), - B("Lenovo", "3000 V100 TF05Cxx",1, "http://www5.pc.ibm.com/europe/products.nsf/products?openagent&brand=Lenovo3…", NULL), + B("Acer", "Aspire 1520", 1, "http://support.acer.com/us/en/acerpanam/notebook/0000/Acer/Aspire1520/Aspir…", NULL), + B("Acer", "Aspire One", 0, NULL, "http://www.coreboot.org/pipermail/coreboot/2009-May/048041.html"), + B("ASUS", "Eee PC 701 4G", 0, "http://www.asus.com/product.aspx?P_ID=h6SPd3tEzLEsrEiS", "It seems the chip (25X40VSIG) is behind some SPI flash translation layer (likely in the EC, the ENE KB3310)."), + B("Dell", "Latitude CPi A366XT", 0, "http://www.coreboot.org/Dell_Latitude_CPi_A366XT", "The laptop immediately powers off if you try to hot-swap the chip. It's not yet tested if write/erase would work on this laptop."), + B("HP/Compaq", "nx9010", 0, "http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us…", "Hangs upon '''flashrom -V''' (needs hard power-cycle then)."), + B("IBM/Lenovo", "Thinkpad T40p", 0, "http://www.thinkwiki.org/wiki/Category:T40p", NULL), + B("IBM/Lenovo", "240", 0, "http://www.stanford.edu/~bresnan//tp240.html", "Seems to (partially) work at first, but one block/sector cannot be written which then leaves you with a bricked laptop. Maybe this can be investigated and fixed in software later."), + B("Lenovo", "3000 V100 TF05Cxx", 1, "http://www5.pc.ibm.com/europe/products.nsf/products?openagent&brand=Lenovo3…", NULL), #endif {}, Modified: trunk/print_wiki.c ============================================================================== --- trunk/print_wiki.c Thu Jun 3 02:49:50 2010 (r1026) +++ trunk/print_wiki.c Thu Jun 3 18:35:51 2010 (r1027) @@ -146,8 +146,8 @@ k = 0; while ((b[k].vendor_name != NULL) - && !strcmp(b[k].vendor_name, boards[i].vendor) - && !strcmp(b[k].board_name, boards[i].name)) { + && strcmp(b[k].vendor_name, boards[i].vendor) + && strcmp(b[k].board_name, boards[i].name)) { k++; }

1 0

[commit] r1026 - trunk
by repository service 03 Jun '10

03 Jun '10

Author: hailfinger Date: Thu Jun 3 02:49:50 2010 New Revision: 1026 URL: http://flashrom.org/trac/coreboot/changeset/1026 Log: Fix fallout from r1021 which caused compile failures if only the dummy programmer was selected. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/flash.h Modified: trunk/flash.h ============================================================================== --- trunk/flash.h Tue Jun 1 18:09:06 2010 (r1025) +++ trunk/flash.h Thu Jun 3 02:49:50 2010 (r1026) @@ -25,6 +25,7 @@ #define __FLASH_H__ 1 #include <stdint.h> +#include <stddef.h> #include "hwaccess.h" #ifdef _WIN32 #include <windows.h> @@ -32,10 +33,6 @@ #undef max #endif -#ifndef NULL -#define NULL ((void *) 0) -#endif - typedef unsigned long chipaddr; enum programmer {

1 0

ABIT SM5 rev 1.5 motherboard
by Alex Buell 03 Jun '10

03 Jun '10

> Apparently latest flashrom fails to detect the eeprom on Abit SM5 rev. > 1.5 motherboard. > > As requested, here's the details attached with this e-mail. > > [attached flashrom -V, lspci -nnvvxxx, superiotool -deV' and also the > BIOS files and flasher program] Forwarded without the SM5.ZIP files :) Please ask me when you need them to look at! -- http://www.munted.org.uk One very high maintenance cat living here.

1 0

[PATCH] Fix broken links for Gigabyte motherboards
by Peter Lemenkov 02 Jun '10

02 Jun '10

2 1

Can't write or Erase on Abit IC7
by Anders Jenbo 02 Jun '10

02 Jun '10

Hi, i'm trying to use a Abit IC7 to cross flash the BIOS for another board but neither erase or wirte works. The chips that i am trying to flash is a SST SST49LF004A, I am able to read it's content just fine. Any ideas what might be the issue here? -Anders

4 5

Tyan S2915 OEM / HP xw9400 now supported
by Carl-Daniel Hailfinger 02 Jun '10

02 Jun '10

Hi, flashrom should work fine since version 0.9.2 revision 1008 on all Tyan S2915 OEM boards. The reason for the failing access was that those boards have two MCP55 LPC bridges. flashrom enabled the first LPC bridge (oddball PCI class) instead of the second one (ISA bridge PCI class). Since we don't have any reports of PCI ID 10de:0361 being used as "real" primary LPC bridge, we blacklisted that ID for now until class checking is in place (which may break on other boards with buggy BIOS, not sure). The "real" LPC bridge on this board has the PCI ID I'd appreciate full output of flashrom -V with latest flashrom (at least 0.9.2-r1008). Thanks to everyone who tested and provided lspci output. Regards, Carl-Daniel -- http://www.hailfinger.org/

4 6

Re: [flashrom] [PATCH] Add support for RayeR SPIPGM hardware.
by rayer 02 Jun '10

02 Jun '10

Hi, it still hangs while autodetecting flash chip at AE49F2008 (is displayed as last probed), only with -c option it works. ============================ Martin, could you test the new binary at http://khepri.openbios.org/~idwer/flashrom/r1017-patchwork-1418/flashrom.exe It should work insofar as that it won't crash and won't complain about miscompilation. On 30.05.2010 03:49, Idwer Vollering wrote: > 2010/5/30 Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > > >> On 27.05.2010 03:04, Carl-Daniel Hailfinger wrote: >> >>> On 27.05.2010 02:32, Carl-Daniel Hailfinger wrote: >>> >>> >>>> New version, fixes a few bugs where #ifdefs were missing. >>>> >>>> Add support for RayeR SPIPGM hardware as described in >>>> http://rayer.ic.cz/elektro/spipgm.htm >>>> >>>> Known bugs/limitations: >>>> - Won't compile/work on non-x86 architectures. Guards against >>>> compilation on non-x86 are missing. >>>> >>>> >>>> >>> Besides that, using "byte" as variable name breaks on mingw because >>> it shadows a global variable with that name in the mingw headers. >>> >>> >> New version, fixes a missing variable initialization which led to >> immediate segfault on programmer init. >> >> > > This segfault is confirmed to be resolved, tested using FreeDOS -- I > don't have the hardware that this patch targets. > > The other limitations are still present. > >> Signed-off-by: Carl-Daniel Hailfinger >> <c-d.hailfinger.devel.2006(a)gmx.net> >> >> > > Acked-by: Idwer Vollering <vidwer(a)gmail.com> > Thanks. We'll wait for RayeR to test, then I will commit. Regards, Carl-Daniel

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom