- flashrom - mail.coreboot.org

[PATCH 2/4] Libflashrom: Fix libflashrom building
by Łukasz Dmitrowski 14 Aug '15

14 Aug '15

Anton Kochkov's fixes for libflashrom building Signed-off-by: Lukasz Dmitrowski <lukasz.dmitrowski(a)gmail.com> --- Makefile | 2 +- flashrom.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index d18de09..2c7fccd 100644 --- a/Makefile +++ b/Makefile @@ -726,7 +726,7 @@ FEATURE_CFLAGS += $(shell LC_ALL=C grep -q "UTSNAME := yes" .features && printf # We could use PULLED_IN_LIBS, but that would be ugly. FEATURE_LIBS += $(shell LC_ALL=C grep -q "NEEDLIBZ := yes" .libdeps && printf "%s" "-lz") -LIBFLASHROM_OBJS = $(CHIP_OBJS) $(PROGRAMMER_OBJS) $(LIB_OBJS) +LIBFLASHROM_OBJS = $(CHIP_OBJS) $(PROGRAMMER_OBJS) $(LIB_OBJS) udelay.o OBJS = $(CLI_OBJS) $(LIBFLASHROM_OBJS) all: hwlibs features $(PROGRAM)$(EXEC_SUFFIX) $(PROGRAM).8 diff --git a/flashrom.c b/flashrom.c index 9b82d4c..0bc821a 100644 --- a/flashrom.c +++ b/flashrom.c @@ -622,7 +622,7 @@ static unsigned int count_usable_erasers(const struct flashctx *flash) return usable_erasefunctions; } -static int compare_range(const uint8_t *wantbuf, const uint8_t *havebuf, unsigned int start, unsigned int len) +int compare_range(const uint8_t *wantbuf, const uint8_t *havebuf, unsigned int start, unsigned int len) { int ret = 0, failcount = 0; unsigned int i; @@ -1563,7 +1563,7 @@ int erase_and_write_flash(struct flashctx *flash, uint8_t *oldcontents, uint8_t return ret; } -static void nonfatal_help_message(void) +void nonfatal_help_message(void) { msg_gerr("Good, writing to the flash chip apparently didn't do anything.\n"); #if CONFIG_INTERNAL == 1 @@ -1581,7 +1581,7 @@ static void nonfatal_help_message(void) "mail flashrom(a)flashrom.org, thanks!\n"); } -static void emergency_help_message(void) +void emergency_help_message(void) { msg_gerr("Your flash chip is in an unknown state.\n"); #if CONFIG_INTERNAL == 1 @@ -1605,7 +1605,7 @@ void list_programmers(const char *delim) if (p < PROGRAMMER_INVALID - 1) msg_ginfo("%s", delim); } - msg_ginfo("\n"); + msg_ginfo("\n"); } void list_programmers_linebreak(int startcol, int cols, int paren) -- 2.1.4

1 0

[PATCH 1/4] Libflashrom: Fix libflashrom compilation
by Łukasz Dmitrowski 14 Aug '15

14 Aug '15

Anton Kochkov's fixes for libflashrom compilation. Signed-off-by: Lukasz Dmitrowski <lukasz.dmitrowski(a)gmail.com> --- libflashrom.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/libflashrom.c b/libflashrom.c index 507fee9..c96a2e9 100644 --- a/libflashrom.c +++ b/libflashrom.c @@ -187,12 +187,12 @@ int fl_flash_probe(fl_flashctx_t **const flashctx, const char *const chip_name) return 1; memset(*flashctx, 0, sizeof(**flashctx)); - for (i = 0; i < registered_programmer_count; ++i) { + for (i = 0; i < registered_master_count; ++i) { int flash_idx = -1; - if (!ret || (flash_idx = probe_flash(&registered_programmers[i], 0, *flashctx, 0)) != -1) { + if (!ret || (flash_idx = probe_flash(&registered_masters[i], 0, *flashctx, 0)) != -1) { ret = 0; /* We found one chip, now check that there is no second match. */ - if (probe_flash(&registered_programmers[i], flash_idx + 1, &second_flashctx, 0) != -1) { + if (probe_flash(&registered_masters[i], flash_idx + 1, &second_flashctx, 0) != -1) { ret = 3; break; } @@ -370,7 +370,7 @@ int fl_image_write(fl_flashctx_t *const flashctx, void *const buffer, const size goto _free_out; } - handle_romentries(flashctx, oldcontents, newcontents); + build_new_image(flashctx, oldcontents, newcontents); if (erase_and_write_flash(flashctx, oldcontents, newcontents)) { msg_cerr("Uh oh. Erase/write failed. Checking if anything changed.\n"); @@ -427,7 +427,7 @@ int fl_image_verify(fl_flashctx_t *const flashctx, void *const buffer, const siz goto _free_out; } - handle_romentries(flashctx, oldcontents, newcontents); + build_new_image(flashctx, oldcontents, newcontents); msg_cinfo("Verifying flash... "); -- 2.1.4

1 0

About to try flashrom on Asus F1 A55-M LX
by rcain 12 Aug '15

12 Aug '15

Hi, I am about to try updating my FLASH BIOS over the next couple of hours - i wondered how long you guys will be there for right now and whether you might be able to help me out if it goes horribly wrong? I am using Asus F1 A55-M LX motherboard - which i do not see listed in your table of supported/tested devices - would you recommend i give 'flashrom' a go anyway? (note: flashrom seems to recognize my chip set, etc - here is the output of a successful flashrom backup i just made: rcain@rcain-ubuntu:~/Backups/120815_1720_flashrom_backup$ sudo flashrom -p internal -r backup.rom -o backuplog.txt flashrom v0.9.6.1-r1563 on Linux 3.13.0-61-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "AMD Hudson". Enabling flash write... OK. Found Winbond flash chip "W25Q32" (4096 kB, SPI) at physical address 0xffc00000. Reading flash... done. ) Many thanks for any help/advise you can give. Rob Cain Director, SystemCore Ltd tel: 01483 428655 email: rcain(a)systemcore.co.uk skype: rjcain

1 0

HP XW9300 mainboard
by Federico Tomasi 12 Aug '15

12 Aug '15

Hi, I already tried some time ago to flash my hp xw9300 mainboard bios but with no luck. Then I realized that I was using Ubuntu on a VirtualBox so it maybe could not access the mainborad chip... I retried in these days using an Ubuntu live-cd, and I also read this old forum thread http://forums.bit-tech.net/showpost.php?s=c0347634d93e911f8254f28ec1a83fc1&… where a guy tells to have succesfully written a Tyan original bios on the HP branded version of the same mainboard (the Tyan K8WE S2895) that is the HP XW9300 mainboard. (I didn't connect pins as he edit it wasn't necessary to do that but to enable the jumper of boot block) It would be really nice for me to be able to write the Tyan version of bios as HP one doesn't support 4GB modules so I have lost almost all my ram. I report here what I got (I saw another guys got almost the same on the same mobo trying to install coreboot): "ubuntu@ubuntu:~/Desktop/flashrom-0.9.8$ sudo flashrom -p internal -w bios_1.06.bin -V flashrom v0.9.8-r1888 on Linux 3.19.0-15-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.2.1, GCC 4.9.2, little endian Command line (5 args): flashrom -p internal -w bios_1.06.bin -V Calibrating delay loop... OS timer resolution is 2 usecs, 922M loops per second, 10 myus = 11 us, 100 myus = 100 us, 1000 myus = 992 us, 10000 myus = 10008 us, 8 myus = 9 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Mini Tower" DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "HP xw9300 Workstation" DMI string system-version: " " DMI string baseboard-manufacturer: "Hewlett-Packard" DMI string baseboard-product-name: "09C4h" DMI string baseboard-version: "Not Specified" Found chipset "NVIDIA CK804" with PCI ID 10de:0051. Enabling flash write... OK. Warning: unexpected second chipset match: "NVIDIA CK804" ignoring, please report lspci and board URL to flashrom(a)flashrom.org with 'CHIPSET: your board name' in the subject line. The following protocols are supported: Non-SPI. Probing for AMD Am29F010A/B, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BB, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F002(N)BT, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F016D, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F040B, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29F080B, 1024 kB: probe_jedec_common: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV001BB, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV001BT, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV002BB, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV002BT, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV004BB, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV004BT, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV008BB, 1024 kB: probe_jedec_common: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV008BT, 1024 kB: probe_jedec_common: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV040B, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for AMD Am29LV081B, 1024 kB: probe_jedec_common: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002B, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29002T, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for AMIC A29040B, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for AMIC A49LF040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT29C512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT29C010A, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT29C020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT29C040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49BV512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49F002(N), 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49F002(N)T, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49(H)F010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49F020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49F040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49F080, 1024 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49F080T, 1024 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Catalyst CAT28F512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Bright BM29F040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for ESMT F49B002UA, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Eon EN29F010, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)B, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29F002(A)(N)T, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Eon EN29LV040(A), 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Eon EN29LV640B, 8192 kB: probe_en29lv640b: id1 0xffff, id2 0x00ff Probing for Eon EN29GL064(A)B, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Eon EN29GL064(A)T, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Eon EN29GL064H/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Eon EN29GL128, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Fujitsu MBM29F004BC, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F004TC, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F400BC, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29F400TC, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29LV160BE, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Fujitsu MBM29LV160TE, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Hyundai HY29F002T, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Hyundai HY29F002B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Hyundai HY29F040A, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F001BN/BX-B, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Intel 28F001BN/BX-T, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Intel 28F002BC/BL/BV/BX-T, 256 kB: probe_82802ab: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F008S3/S5/SC, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004B5/BE/BV/BX-B, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F004B5/BE/BV/BX-T, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/BX/CE/CV-B, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 28F400BV/BX/CE/CV-T, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ISSI IS29GL064B, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for ISSI IS29GL064T, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for ISSI IS29GL064H/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for ISSI IS29GL128H/L, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29F001B, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F001T, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002(N)B, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F002(N)T, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F022(N)B, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F022(N)T, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29F040, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for Macronix MX29GL320EB, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL320ET, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL320EH/L, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL640EB, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL640ET, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL640EH/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29GL128F, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Macronix MX29LV040, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for MoselVitelic V29C51000B, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for MoselVitelic V29C51000T, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for MoselVitelic V29C51400B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for MoselVitelic V29C51400T, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for MoselVitelic V29LC51000, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for MoselVitelic V29LC51001, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for MoselVitelic V29LC51002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for PMC Pm29F002T, 256 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm29F002B, 256 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV010, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV020, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV040, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm39LV512, 64 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Sharp LH28F008BJT-BTLZ1, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST28SF040A, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for SST SST29EE010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST29LE010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST29EE020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST29LE020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39SF512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39SF010A, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39SF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39SF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39VF512, 64 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39VF010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39VF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39VF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST39VF080, 1024 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF020A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SST SST49LF080A, 1024 kB: Chip lacks correct probe timing information, using default 10mS/40uS. probe_jedec_common: id1 0xbf, id2 0x5b Found SST flash chip "SST49LF080A" (1024 kB, LPC) mapped at physical address 0x00000000fff00000. Probing for SST SST49LF160C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002B, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F002T/NT, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29F040B, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M29F400BB, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M29F400BT, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M29W010B, 128 kB: probe_jedec_common: id1 0x65, id2 0xd0, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M29W040B, 512 kB: probe_jedec_common: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M29W512B, 64 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x20, id2 0x20, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50LPW080, 1024 kB: probe_82802ab: id1 0x48, id2 0x50, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50LPW116, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SyncMOS/MoselVitelic {F,S,V}29C51001B, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {F,S,V}29C51001T, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {F,S,V}29C51002B, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {F,S,V}29C51002T, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {F,S,V}29C51004B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {F,S,V}29C51004T, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {S,V}29C31004B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for SyncMOS/MoselVitelic {S,V}29C31004T, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for TI TMS29F002RB, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for TI TMS29F002RT, 256 kB: probe_jedec_common: id1 0xe4, id2 0xb9, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W29C010(M)/W29C011A/W29EE011/W29EE012-old, 128 kB: Old Winbond W29* probe method disabled because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29C010(M)/W29C011A/W29EE011/W29EE012-old' if you have a board with such a chip. Probing for Winbond W29C010(M)/W29C011A/W29EE011/W29EE012, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W29C020(C)/W29C022, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W29C040/P, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W29GL032CB, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL032CT, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL032CH/L, 4096 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL064CB, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL064CT, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL064CH/L, 8192 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W29GL128C, 16384 kB: probe_jedec_29gl: man_id 0xff, dev_id 0xffffff, man_id parity violation, man_id seems to be normal flash content, dev_id seems to be normal flash content Probing for Winbond W39F010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39L010, 128 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39L020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39L040, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V040A, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V040B, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V040C, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V080A, 1024 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W49F002U/N, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W49F020, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W49V002A, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xbf, id2 0x5b Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xbf, id2 0x5b Found SST flash chip "SST49LF080A" (1024 kB, LPC). Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:EFAILED at 0x00000000! Expected=0xff, Found=0x48, failed byte count from 0x00000000-0x00000fff: 0x100 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x00ffff:EFAILED at 0x00000000! Expected=0xff, Found=0x48, failed byte count from 0x00000000-0x0000ffff: 0x100 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Good, writing to the flash chip apparently didn't do anything. This means we have to add special support for your board, programmer or flash chip. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks!" Thank you for your support, Federico

1 0

Flashrom log report
by 雨宮鈴雪 12 Aug '15

12 Aug '15

Hardware: Lenovo ThinkServer TS240 Thank you developers!! ================================================= flashrom v0.9.8-r1888 on Linux 4.2.0-rc2-satori (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.2.1, GCC 4.8.4, little endian Command line (5 args): ./flashrom --programmer internal -V -r 1111 Calibrating delay loop... OS timer resolution is 1 usecs, 3214M loops per second, delay more than 10% too short (got 89% of expected delay), recalculating... 3195M loops per second, delay more than 10% too short (got 89% of expected delay), recalculating... 3233M loops per second, 10 myus = 9 us, 100 myus = 102 us, 1000 myus = 1006 us, 10000 myus = 9712 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Tower" DMI string system-manufacturer: "LENOVO" DMI string system-product-name: "ThinkServer TS240" DMI string system-version: "FFFFFFF" DMI string baseboard-manufacturer: "LENOVO" DMI string baseboard-product-name: "ThinkServer TS140" DMI string baseboard-version: "Not Defined " Found ITE Super I/O, ID 0x8733 on port 0x2e Found chipset "Intel C226" with PCI ID 8086:8c56. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching disabled, caching enabled, BIOS_CNTL = 0x22: BIOS Lock Enable: enabled, BIOS Write Enable: disabled Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0x22 to 0x01 failed. New value is 0x22. SPIBAR = 0x00007fd66ec38000 + 0x3800 0x04: 0xf008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 Warning: SPI Configuration Lockdown activated. Reading OPCODES... done 0x06: 0x3f00 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0 0x50: 0x00004a4b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x4a, BRRA 0x4b 0x54: 0x00000000 FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x0bff0580 FREG1: BIOS region (0x00580000-0x00bfffff) is read-write. 0x5C: 0x057f0003 FREG2: Warning: Management Engine region (0x00003000-0x0057ffff) is locked. 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see http://flashrom.org/ME for details. Writes have been disabled for safety reasons. You can enforce write support with the ich_spi_force programmer option, but you will most likely harm your hardware! If you force flashrom you will get no support if something breaks. On a few mainboards it is possible to enable write access by setting a jumper (see its documentation or the board itself). 0x90: 0xc0 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xfc4010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=4 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05200302 (OPMENU) 0x9C: 0x0000019f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x80802045 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x80002045 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x50444653 (FPB) Enabling hardware sequencing due to multiple flash chips detected. PROBLEMS, continuing anyway The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 2 attached SPI flash chips with a combined density of 12288 kB. The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0xbfffff. In that range are 1453 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x53, id2 0xe8, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0x53, id2 0xe8, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0x53, id2 0xe8, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xb8, id2 0x84, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0x53, id2 0xe8, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0x53, id2 0xe8, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xf4, id2 0xe8, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific). Reading flash... Reading 12582912 bytes starting at 0x000000. Transaction error between offset 0x00003000 and 0x0000303f (= 0x00003000 + 63)! HSFS: FDONE=1, FCERR=1, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0 Read operation failed! FAILED. Restoring MMIO space at 0x7fd66ec3b8a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

Re: [flashrom] Proposed changes to flashrom hosting and workflow
by David Hendricks 11 Aug '15

11 Aug '15

On Tue, Aug 11, 2015 at 2:25 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-08-11 2:28 GMT+02:00 Carl-Daniel Hailfinger < > c-d.hailfinger.devel.2006(a)gmx.net>: >> >> @Stepan: >> It would be good to know which of patchwork or svn (or both) cause extra >> maintenance burden. > > AFAICS at least svn seems to be automatically getting security updates >> on ra (coreboot server). >> > We run apache (with mod_dav_svn) just for svn. It's automatically updated > alright, but it still increases the system's surface. > > >> If we migrate off patchwork, is there a way to keep/import the old data >> into some other tool? > > Since it's unstructured data that will be hard to automate. > > >> Hm. In the end, we have to decide whether the tree will be managed >> > directly by humans or indirectly via Gerrit. I doubt we can have both at >> the same time without pretty explosions. >> > Even with gerrit, it's always managed by humans. Gerrit never presses the > 'submit' button by itself. > And if a patch doesn't apply cleanly to the current top of tree gerrit won't be able to commit it. I'd argue that there's less of a risk of "pretty explosions" with Gerrit, since developers will be less likely to push with additional local changes accidentally applied. Though I know stefanct often makes small corrections/modifications to patches before submitting them (because our code review process makes even small amounts of back-and-forth comments so cumbersome). At least this way such changes can be tracked trivially on-line by diffing the N and N-1 patch revisions in gerrit. > I assume the switch was done to get some gerrit features (jenkins >> integration) not present in patchwork. >> > The switch was done because patchwork became a dumping ground for > non-actionable diffs. > > The main advantages of gerrit over patchwork (IMHO) are: > 1. you can directly work from the list of open commits (in patch work you > can only reply by hunting down the thread that it archived in your local > mail client. if you weren't subscribed back then, you're out of luck) > 2. through the git push model of contributing you're guaranteed to have > context for the commit. compare "all history that leads to this commit" to > the diffs in patchwork: uh, that might be based on r5200 or maybe r1500 or > is it even manually edited and doesn't apply cleanly to anything? > #2 will also help us deal with the reality of lack of developer time and bit rotting patches. Gerrit makes rebasing stale patchsets reasonably straight-forward and simple. As Patrick says, the current state of many patches on patchwork is non-actionable - Tracking down whatever revision they apply to and dependencies for a patchset makes it very time-consuming and error-prone. To make matters worse, once a developer has applied patches and gotten things in a working state again, properly applying individual fixes to >1 patch in a series is excruciating. That's why we have developers pointing at external git servers with patchsets applied rather than uploading rebased patches to the mailing list. > > That we automatically test-build the commits and thus have some basic > sanity checks is a very useful bonus. But at least for me that wasn't the > reason for switching tools. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Graham Law, Christine Elizabeth Flores > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [flashrom] Proposed changes to flashrom hosting and workflow
by Carl-Daniel Hailfinger 11 Aug '15

11 Aug '15

On 10.08.2015 04:17, David Hendricks wrote: > On Sat, Aug 8, 2015 at 1:23 AM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >> I would like to avoid git at all costs, even if it means I have to host >> something non-git as main repo myself and pay for the hosting. Cloning >> git into a local svn on my side is not an option because it combines the >> worst usability aspects of git hosting (no version numbers) and svn >> clients (no offline commits). > +1 to what Patrick said, too. > >> I would be open >> to using mercurial (as master) because it at least has some sort of >> usability and can provide (conceptually limited) version numbers. I have >> worked for a few years with mercurial and the version numbers are >> extremely helpful even if they are per-branch and only semi-stable. > The point of this is that maintaining two different SCMs and code > review systems is a pain. Just keeping SVN up-to-date requires dealing > with several (maybe dozens?) extra packages that would not be needed > otherwise (Stefan can clarify). @Stepan: It would be good to know which of patchwork or svn (or both) cause extra maintenance burden. AFAICS at least svn seems to be automatically getting security updates on ra (coreboot server). Patchwork seems to require manual updating similar to what gerrit/jenkins require. If we migrate off patchwork, is there a way to keep/import the old data into some other tool? >> About jenkins: Seems to be a good idea and would help detect patch bitrot. > Agreed, but still doesn't really help lower the maintenance burden. Given that it feels like most of the upstream flashrom effort over the last two years was mostly trying to forward-port patches cleanly and/or make them work again, I think the maintenance burden from a flashrom developer POV would be lowered. Or did you mean the server administration burden? >> About gerrit: Last time I tried gerrit the usability was horrible: >> - needs registration (like a forum) >> - has no usable mail interface (like a forum) > Who says people can't send patches via mail? Those who want to stick > with the current process (but with an arguably better SCM) can > certainly do so. I don't see why it must be one or the other. Hm. In the end, we have to decide whether the tree will be managed directly by humans or indirectly via Gerrit. I doubt we can have both at the same time without pretty explosions. > Registration does kind of suck, but again, many active developers > already have a GitHub account (if not a Google account). IIRC OpenID had/has soem security bugs which partially stems from the design. That's one o the reasons why I wanted to avoid Gerrit. >> - you can't work on drafts for a review unless you keep the web browser >> window open (like a forum) > That't simply incorrect. One can upload drafts and work on them just > as with any other patch. Here's some more info: > http://www.coreboot.org/pipermail/coreboot/2012-November/071963.html Thanks, I stand corrected. I thought only patch drafts were possible, but apparently comment drafts on regular patches are possible as well. >> If we really want to move to gerrit, we should close the mailing list as >> well and switch to a forum which has roughly the same usability as >> gerrit. I really mean it. We seriously should consider moving to a forum >> _if_ developers prefer forum interfaces to mail. > Would you also make the same recommendation for the coreboot mailing > list? I doubt that anybody on the CB mailing list would want to do that. I do prefer email interfaces, but I have no idea what others think. That said, it seems the switch from patchwork to gerrit for coreboot seems to have been welcomed back then. I assume the switch was done to get some gerrit features (jenkins integration) not present in patchwork. Regards, Carl-Daniel

2 1

Re: [flashrom] Proposed changes to flashrom hosting and workflow
by Carl-Daniel Hailfinger 11 Aug '15

11 Aug '15

On 10.08.2015 19:46, Patrick Georgi wrote: > I wanted to note that mercurial can use git servers in the backend: > http://hg-git.github.io/ Hm. That sounds promising, thanks. On 08.08.2015 15:04, Patrick Georgi wrote: > 2015-08-08 10:23 GMT+02:00 Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net > <mailto:c-d.hailfinger.devel.2006@gmx.net>>: > > If there really is a large demand for a non-svn hosting, I would > be open > to using mercurial (as master) because it at least has some sort of > usability and can provide (conceptually limited) version numbers. > I have > worked for a few years with mercurial and the version numbers are > extremely helpful even if they are per-branch and only semi-stable. > > mercurial's notion of a monotonic commit counter (that you're looking > for if I understand you correctly) has about the same quality as git > describe's commits-since-last-tag counter. > > For a global numbering scheme, you could just (automatically) tag > every single commit of a certain branch (master, release, ...) with a > monotonic counter. That's more or less what the svn-to-git translation > of tianocore is doing, for example (with tags following the scheme > svn18670). That way, those numbers are actually global, unlike what > mercurial is doing. > Assume that the scheme is to use $version-$number since release: git > describe would emit something like 0.9.9-40-5-gabcde, meaning that > your tree is based on the tag 0.9.9-40 (globally unique), is 5 local > commits away from that, with your current local commit id being abcde. The auto-tag of every commit sounds like an option I could agree with. It would preserve the convenience of the global strong svn commit ID even for git. However, I don't know if this would be acceptable for Stefan (especially from a merging perspective). Regards, Carl-Daniel

1 0

Re: [flashrom] Proposed changes to flashrom hosting and workflow
by Carl-Daniel Hailfinger 10 Aug '15

10 Aug '15

I would like to avoid git at all costs, even if it means I have to host something non-git as main repo myself and pay for the hosting. Cloning git into a local svn on my side is not an option because it combines the worst usability aspects of git hosting (no version numbers) and svn clients (no offline commits). If there really is a large demand for a non-svn hosting, I would be open to using mercurial (as master) because it at least has some sort of usability and can provide (conceptually limited) version numbers. I have worked for a few years with mercurial and the version numbers are extremely helpful even if they are per-branch and only semi-stable. About jenkins: Seems to be a good idea and would help detect patch bitrot. About gerrit: Last time I tried gerrit the usability was horrible: - needs registration (like a forum) - has no usable mail interface (like a forum) - you can't work on drafts for a review unless you keep the web browser window open (like a forum) If we really want to move to gerrit, we should close the mailing list as well and switch to a forum which has roughly the same usability as gerrit. I really mean it. We seriously should consider moving to a forum _if_ developers prefer forum interfaces to mail. Regards, Carl-Daniel On 07.08.2015 20:51, David Hendricks wrote: > 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. > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom <

3 3

Re: [flashrom] MX25L6445E erase and write failed!
by The Raven 10 Aug '15

10 Aug '15

Hi again I have now tryed with frser-duino from "Urja Rannikko". With other chips i have better results (for example with the M25P10, this chips is working now). But the MX25L6445E is still not working. After a long time flashrom trys other erase options, but all failed. Have a look here (cut from log): ...............-0x0f5fff:E, 0x0f6000-0x0f6fff:E, 0x0f7000-0x0f7fff:E, 0x0f8000-0x0f8fff:E, 0x0f9000-0x0f9fff:E, 0x0fa000-0x0fafff:E, 0x0fb000-0x0fbfff:E, 0x0fc000-0x0fcfff:E, 0x0fd000-0x0fdfff:E, 0x0fe000-0x0fefff:E, 0x0ff000-0x0fffff:E, 0x100000-0x100fff:EFAILED at 0x00100000! Expected=0xff, Found=0xeb, failed byte count from 0x00100000-0x00100fff: 0xfe5 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 1... 0x000000-0x007fff:S, 0x008000-0x00ffff:S, 0x010000-0x017fff:S, 0x018000-0x01ffff:S, 0x020000-0x027fff:S, 0x028000-0x02ffff:S, 0x030000-0x037fff:S, 0x038000-0x03ffff:S, 0x040000-0x047fff:S, 0x048000-0x04ffff:S, 0x050000-0x057fff:S, 0x058000-0x05ffff:S, 0x060000-0x067fff:S, 0x068000-0x06ffff:S, 0x070000-0x077fff:S, 0x078000-0x07ffff:S, 0x080000-0x087fff:S, 0x088000-0x08ffff:S, 0x090000-0x097fff:S, 0x098000-0x09ffff:S, 0x0a0000-0x0a7fff:S, 0x0a8000-0x0affff:S, 0x0b0000-0x0b7fff:S, 0x0b8000-0x0bffff:S, 0x0c0000-0x0c7fff:S, 0x0c8000-0x0cffff:S, 0x0d0000-0x0d7fff:S, 0x0d8000-0x0dffff:S, 0x0e0000-0x0e7fff:S, 0x0e8000-0x0effff:S, 0x0f0000-0x0f7fff:S, 0x0f8000-0x0fffff:S, 0x100000-0x107fff:EFAILED at 0x00100000! Expected=0xff, Found=0xeb, failed byte count from 0x00100000-0x00107fff: 0x7f69 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 2... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S, 0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S, 0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:S, 0x080000-0x08ffff:S, 0x090000-0x09ffff:S, 0x0a0000-0x0affff:S, 0x0b0000-0x0bffff:S, 0x0c0000-0x0cffff:S, 0x0d0000-0x0dffff:S, 0x0e0000-0x0effff:S, 0x0f0000-0x0fffff:S, 0x100000-0x10ffff:EFAILED at 0x00100000! Expected=0xff, Found=0xeb, failed byte count from 0x00100000-0x0010ffff: 0xfb20 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 3... 0x000000-0x7fffff:EFAILED at 0x00100000! Expected=0xff, Found=0xeb, failed byte count from 0x00000000-0x007fffff: 0x26be30 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Trying erase function 4... 0x000000-0x7fffff:EFAILED at 0x00100000! Expected=0xff, Found=0xeb, failed byte count from 0x00000000-0x007fffff: 0x26be30 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! As you can see it always fails at the same byte count. I am still not sure if this problem is related to serprog/frser-duino. It looks like the chip is write protected or something like that.

1 1

W836xx: HP Proliant DL385 G7: flashrom -V
by Александр Трубицын 08 Aug '15

08 Aug '15

Hi, Stefan! I can't reflash DL385 G7, but can try flashrom -p internal -V and flashrom -p internal -Vr on this server with new versions of flashrom. With best regards, Alexander Trubitsyn

1 0

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

Not detecting Am29F010 using 3Com PCI nic
by Ignatius Grippa 29 Jul '15

29 Jul '15

1 0

Path syntax for Linux Flashrom?
by a webuser 22 Jul '15

22 Jul '15

I've found lots of helpful info on using Flashrom for updating an HP xw9400 BIOS using an Ubuntu Live DVD, but the commands never seem to include any path information! For example: flashrom -r biosbackup.rom flashrom -E flashrom -w 7D6_0403.bin In the first and third lines, where does Flashrom assume the files are located if no path is supplied? If I install a floppy to read/write to, what is the path syntax? About the Ubuntu Live DVD, could someone add a little more info to these cryptic instructions to install Flashrom (is this multiple steps)? install flashrom (open a terminal from the start menu, do sudo su) using apt-get install flashrom Thanks!

3 2

Re: [flashrom] Path syntax for Linux Flashrom?
by David Hendricks 22 Jul '15

22 Jul '15

(adding the list back) On Wed, Jul 22, 2015 at 1:00 PM, a webuser <awebuser(a)hotmail.com> wrote: > Hi! > > > Thanks for the reply, but I have zero background in Linux, and what > appears obvious to some is cryptic to others... ;) > > About the path declaration, I'm assuming it would be something like: > "flashrom -r a:\biosbackup.rom" (does Linux use a backslash?) > Something like that, though Linux distributions usually do not use that notation for paths. > > > About installing Flashrom from Ubuntu, a slightly more verbose description > would have helped in that case. I'm assuming they are two distinct command > prompt entries. > > It's basically the language that is odd with the use of "do" and "using", > which implies that they are one command, when I'm guessing they are not. > Your distribution of choice (Ubuntu?) has the documentation for those commands. Flashrom is just one of many programs which run on many distributions and variety of operating systems, therefore it is not practical to go that deep into details about the OS's package management. That is something you'll need to learn on your own. There's a non-zero chance that something will go horribly wrong when you run flashrom and you'll need to do something to recover. I suggest that you get comfortable with your tools and environment before doing something that is potentially destructive. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

W836xx: Lenovo Yoga 2 Pro: flashrom -V
by Peter Hoeg 20 Jul '15

20 Jul '15

Hi, here's the requested flashrom output. -- Regards, Peter

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom