- flashrom - mail.coreboot.org

Foxconn H61MXL-K verbose flashrom output
by Ryan Solomon 10 Sep '15

10 Sep '15

1 0

SST49LF016C: Supermicro X7DWT successfully reflashed
by Steven Stremciuc 10 Sep '15

10 Sep '15

The Supermicro X7DWT motherboard is not listed on the flashrom supported hardware page, and the SST49LF016C chip has an "?" for erase and write status. I successfully reflashed the chip using flashrom, and thought I would send you a note so you can update the supported hardware list, if you would like. This board(s) was in a Dell C6100 XS23-SB. Thanks, Steven Stremciuc

1 0

Re: [flashrom] Teensy ISP on Synology mainboard
by Urja Rannikko 31 Aug '15

31 Aug '15

Hi, try to keep it on the mailing list too (i made a mistake of both you and the ML last time...) On Mon, Aug 31, 2015 at 11:56 AM, Guillaume Maugein <guillaume.maugein(a)gmail.com> wrote: > Hi, > > Thanks for the feedback. I'll try to see what I can do with the reset. > > I'll let you know if I can manage to ISP with the teensy, but I don't see > any reason why it could work on an unsoldered chip, but not ISP. Yeah it should work given a short enough cable and an non-interfering target; but as you see that sentence, an unsoldered chip is 0 interference and near-0 "cable" length, so it is a very optimal setup. But i wouldnt have added the little section in the wiki unless i thought it is possible to do ISP with the teensy. > > Maybe I'll try to grip my scope to the signals and see what is going on. > > > If I cannot manage this, would you recommend me buying a bus pirate, or not > ? I have 0 experience with buspirate so i cannot say much (except i've heard it is slow). If you want what other people are suggesting for ISP get a beaglebone black (price: ha..), but in general I'll say if you have measurement tools and can make the NAS not interfere with the ISP the Teensy should be electrically as good as either of those. (As i was investigating whether my statement was true or not, this is what i found: The Teensy (MK20DX256) with "high drive strength" (that is enabled currently in the FW) has a drive strength of 9mA. The BBB has a drive strength (note: just from some forum post) of 4, 6 or 8 mA The buspirate PIC24FJ64 has an asymmetric drive strength of 3mA high 8mA low ) > > 2015-08-31 0:39 GMT+02:00 Urja Rannikko <urjaman(a)gmail.com>: >> >> Hi, >> >> On Sun, Aug 30, 2015 at 6:10 PM, Guillaume Maugein >> <guillaume.maugein(a)gmail.com> wrote: >> > Hey, >> > >> > First of all, thank you for the great work. >> > >> > I am trying to access the Micron N25Q064A13 flash chip on my Synology >> > NAS >> > DS413j. >> > >> > I happen to have a teensy board available at hand, so I programmed it >> > with >> > serprog software, using the instructions to which the flashrom website >> > points to. >> > I am under Xubuntu 15.04, and I installed flashrom from the daily builds >> > ppa. >> > If I remember, the version was 20150705~ubuntu14.04.1. >> >> >> >> xubuntu@xubuntu:~$ flashrom -R >> >> flashrom v0.9.8-unknown on Linux 3.19.0-25-generic (x86_64) >> > >> > >> > >> > I connected the programmer with GND, MISO, MOSI, CLK and CS using grips. >> > As >> > I am ISP, I did not connect the VCC. >> > >> > I double-checked my connections, and they seem to be fine. >> > >> > I start the NAS, and using serial terminal (on a different computer), I >> > stop >> > the boot sequence at uboot prompt. >> > If I flinfo in the uboot, I get the following info : >> > >> >> Marvell>> flinfo >> >> >> >> Bank#1: >> >> Flash Base Address : 0xf8000000 >> >> Flash Model : ST N25Q064 >> >> Manufacturer ID : 0x20 >> >> Device Id : 0xba17 >> >> Sector Size : 64K >> >> Number of sectors : 128 >> >> Page Size : 256 >> >> Write Protection : All >> > >> > >> > While the system is waiting on the prompt, I launch a flashrom command, >> > and >> > the chip is not recognized : >> >> >> >> xubuntu@xubuntu:~$ sudo flashrom -V -p serprog:dev=/dev/ttyACM0:2000000 >> >> flashrom v0.9.8-unknown on Linux 3.19.0-25-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.8.4, little endian >> >> Command line (3 args): flashrom -V -p serprog:dev=/dev/ttyACM0:2000000 >> >> Calibrating delay loop... OS timer resolution is 1 usecs, 1104M loops >> >> per >> >> second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 >> >> myus = >> >> 9998 us, 4 myus = 4 us, OK. >> >> Initializing serprog programmer >> >> Baud rate is 2000000 now. >> >> serprog: connected - attempting to synchronize >> >> . >> >> serprog: Synchronized >> >> serprog: Interface version ok. >> >> serprog: Bus support: parallel=off, LPC=off, FWH=off, SPI=on >> >> serprog: Maximum write-n length is 2037 >> >> serprog: Maximum read-n length is 400384 >> >> serprog: Programmer name is "Teensy LPC+SPI" >> >> serprog: Serial buffer size is 2044 >> >> serprog: operation buffer size is 2048 >> >> serprog: Output drivers enabled >> >> The following protocols are supported: SPI. >> >> Probing for {... the list is long ...} >> >> >> >> Probing for Micron/Numonyx/ST N25Q064..1E, 8192 kB: RDID byte 0 parity >> >> violation. probe_spi_rdid_generic: id1 0x00, id2 0x00 >> >> Probing for Micron/Numonyx/ST N25Q064..3E, 8192 kB: RDID byte 0 parity >> >> violation. probe_spi_rdid_generic: id1 0x00, id2 0x00 >> This (0x00 reply) means that there's something wrong with the >> connections/communications. >> My guess is either a wiring problem or the NAS is also driving the >> SPI I/O lines and the Teensy is not strong enough to override (it >> could also be harmful to the chipset if it was). >> >> Maybe try finding a reset line and holding the NAS in reset while >> doing the programming. >> >> Also note that I havent tested the teensy in any ISP application, so >> you're doing something untested. Have fun :) >> >> >> -- >> Urja Rannikko > > -- Urja Rannikko

1 0

Re: [flashrom] Teensy ISP on Synology mainboard
by Urja Rannikko 31 Aug '15

31 Aug '15

Hi, On Sun, Aug 30, 2015 at 6:10 PM, Guillaume Maugein <guillaume.maugein(a)gmail.com> wrote: > Hey, > > First of all, thank you for the great work. > > I am trying to access the Micron N25Q064A13 flash chip on my Synology NAS > DS413j. > > I happen to have a teensy board available at hand, so I programmed it with > serprog software, using the instructions to which the flashrom website > points to. > I am under Xubuntu 15.04, and I installed flashrom from the daily builds > ppa. > If I remember, the version was 20150705~ubuntu14.04.1. >> >> xubuntu@xubuntu:~$ flashrom -R >> flashrom v0.9.8-unknown on Linux 3.19.0-25-generic (x86_64) > > > > I connected the programmer with GND, MISO, MOSI, CLK and CS using grips. As > I am ISP, I did not connect the VCC. > > I double-checked my connections, and they seem to be fine. > > I start the NAS, and using serial terminal (on a different computer), I stop > the boot sequence at uboot prompt. > If I flinfo in the uboot, I get the following info : > >> Marvell>> flinfo >> >> Bank#1: >> Flash Base Address : 0xf8000000 >> Flash Model : ST N25Q064 >> Manufacturer ID : 0x20 >> Device Id : 0xba17 >> Sector Size : 64K >> Number of sectors : 128 >> Page Size : 256 >> Write Protection : All > > > While the system is waiting on the prompt, I launch a flashrom command, and > the chip is not recognized : >> >> xubuntu@xubuntu:~$ sudo flashrom -V -p serprog:dev=/dev/ttyACM0:2000000 >> flashrom v0.9.8-unknown on Linux 3.19.0-25-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.8.4, little endian >> Command line (3 args): flashrom -V -p serprog:dev=/dev/ttyACM0:2000000 >> Calibrating delay loop... OS timer resolution is 1 usecs, 1104M loops per >> second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 myus = >> 9998 us, 4 myus = 4 us, OK. >> Initializing serprog programmer >> Baud rate is 2000000 now. >> serprog: connected - attempting to synchronize >> . >> serprog: Synchronized >> serprog: Interface version ok. >> serprog: Bus support: parallel=off, LPC=off, FWH=off, SPI=on >> serprog: Maximum write-n length is 2037 >> serprog: Maximum read-n length is 400384 >> serprog: Programmer name is "Teensy LPC+SPI" >> serprog: Serial buffer size is 2044 >> serprog: operation buffer size is 2048 >> serprog: Output drivers enabled >> The following protocols are supported: SPI. >> Probing for {... the list is long ...} >> >> Probing for Micron/Numonyx/ST N25Q064..1E, 8192 kB: RDID byte 0 parity >> violation. probe_spi_rdid_generic: id1 0x00, id2 0x00 >> Probing for Micron/Numonyx/ST N25Q064..3E, 8192 kB: RDID byte 0 parity >> violation. probe_spi_rdid_generic: id1 0x00, id2 0x00 This (0x00 reply) means that there's something wrong with the connections/communications. My guess is either a wiring problem or the NAS is also driving the SPI I/O lines and the Teensy is not strong enough to override (it could also be harmful to the chipset if it was). Maybe try finding a reset line and holding the NAS in reset while doing the programming. Also note that I havent tested the teensy in any ISP application, so you're doing something untested. Have fun :) -- Urja Rannikko

1 0

Teensy ISP on Synology mainboard
by Guillaume Maugein 30 Aug '15

30 Aug '15

Hey, First of all, thank you for the great work. I am trying to access the Micron N25Q064A13 flash chip on my Synology NAS DS413j. I happen to have a teensy board available at hand, so I programmed it with serprog software, using the instructions to which the flashrom website points to. I am under Xubuntu 15.04, and I installed flashrom from the daily builds ppa. If I remember, the version was 20150705~ubuntu14.04.1. > xubuntu@xubuntu:~$ flashrom -R > flashrom v0.9.8-unknown on Linux 3.19.0-25-generic (x86_64) > I connected the programmer with GND, MISO, MOSI, CLK and CS using grips. As I am ISP, I did not connect the VCC. I double-checked my connections, and they seem to be fine. I start the NAS, and using serial terminal (on a different computer), I stop the boot sequence at uboot prompt. If I flinfo in the uboot, I get the following info : Marvell>> flinfo > > Bank#1: > Flash Base Address : 0xf8000000 > Flash Model : ST N25Q064 > Manufacturer ID : 0x20 > Device Id : 0xba17 > Sector Size : 64K > Number of sectors : 128 > Page Size : 256 > Write Protection : All While the system is waiting on the prompt, I launch a flashrom command, and the chip is not recognized : > xubuntu@xubuntu:~$ sudo flashrom -V -p serprog:dev=/dev/ttyACM0:2000000 > flashrom v0.9.8-unknown on Linux 3.19.0-25-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.8.4, little endian > Command line (3 args): flashrom -V -p serprog:dev=/dev/ttyACM0:2000000 > Calibrating delay loop... OS timer resolution is 1 usecs, 1104M loops per > second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 myus > = 9998 us, 4 myus = 4 us, OK. > Initializing serprog programmer > Baud rate is 2000000 now. > serprog: connected - attempting to synchronize > . > serprog: Synchronized > serprog: Interface version ok. > serprog: Bus support: parallel=off, LPC=off, FWH=off, SPI=on > serprog: Maximum write-n length is 2037 > serprog: Maximum read-n length is 400384 > serprog: Programmer name is "Teensy LPC+SPI" > serprog: Serial buffer size is 2044 > serprog: operation buffer size is 2048 > serprog: Output drivers enabled > The following protocols are supported: SPI. > Probing for {... the list is long ...} Probing for Micron/Numonyx/ST N25Q064..1E, 8192 kB: RDID byte 0 parity > violation. probe_spi_rdid_generic: id1 0x00, id2 0x00 > Probing for Micron/Numonyx/ST N25Q064..3E, 8192 kB: RDID byte 0 parity > violation. probe_spi_rdid_generic: id1 0x00, id2 0x00 > Probing for {... the list continues ...} > No EEPROM/flash device found. > Note: flashrom can never write if the flash chip isn't found automatically. > serprog: Output drivers disabled > Do you guys have any idea of what could I try next ? I'm stuck there... Thanks for any help you could provide. G.

1 0

Asus A78M-E eeprom not found
by Vinarz Balázs 29 Aug '15

29 Aug '15

Dear Devs, i've got a ASUS A78M-E mobo. Unfortunately its non-working at the moment. Please look at the file attached, maybe its helpful. Thanks

2 6

Re: [flashrom] FAILED: ASUS P4P800
by Idwer Vollering 29 Aug '15

29 Aug '15

2015-08-28 6:16 GMT+02:00 Alan Kirby <alankirby2(a)gmail.com>: > Hi Folks > > Had a result from flashrom that asked me to send this log to you guys. I'm > certainly thankful for that. > > The mainboard flash ROM had (probably still has) malware within it that is > persistent. Maybe it's lighteater. You can extract the chip's content, from file, using bios_extract: https://github.com/coreboot/bios_extract and/or radare: http://rada.re/ > Since I haven't fully diagnosed it, I've > attached a 64KiB file that is a dump of the boot block: F'0000 - F'FFFF. > One of the things it does is prevent afudos (engineer's version) from > overwriting the boot block. The bootblock, or in this case whole chip protection is put in place by the vendor BIOS. > Another thing it does : if you hit Enter at the > afudos command, then pull out the keyboard cable, the Disk Driver (INT 13h > handler) throws an error, saying there was a disk read error. That > shouldn't happen, so these interrupt handlers are checking up on each > other, in order to achieve overall persistence. BY ALL MEANS: THEN DON'T PULL OUT THE KEYBOARD CABLE? One could permanently break a mainboard, or at least its PS/2 port, by doing so. > > So, to get round these protections, I was attempting to shift away from > FreeDOS and flash the ROM from Linux - Ubuntu (Trust Tahr 6.0), in fact. > > I see the warning about the mainboard-specific code but I couldn't tally > that with any action I should take. I saw that the ASUS P4P800 is supported > and that it is autodetected. I also tried putting different strings after > mainboard, whilst simply probing the hardware: =ASUS, =P4P800, =ASUS > P4P800, =ASUS:P4P800. Each generated an error. Removing the = and > everything after it worked - the probe worked without error. That gave me > confidence that I'd understood the autodetect part. Which model of P4P800 is this? Is it the P4P800-VM? If I recall correctly, a newer release of flashrom (0.9.7 or 0.9.8) will detect the supported (sub)model. Source: I had an ASUS P4P800-VM. > > Regards > > Alan K HTH, Idwer > > # ./flashrom -p internal:mainboard -E > flashrom v0.9.6.1-r1563 on Linux 3.14.20 (i686) > flashrom is free software, get the source code at http://www.flashrom.org > > Calibrating delay loop... OK. > Found chipset "Intel ICH5/ICH5R". Enabling flash write... OK. > WARNING: Your mainboard is ASUS P4P800, but the mainboard-specific > code has not been tested, and thus will not be executed by default. > Depending on your hardware environment, erasing, writing or even probing > can fail without running the board specific code. > > Please see the man page (section PROGRAMMER SPECIFIC INFO, subsection > "internal programmer") for details. > Unhandled programmer parameters: mainboard > Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) at physical address > 0xfff80000. > Erasing and writing flash chip... ERASE FAILED at 0x00001c40 ! > Expected=0xff, Read=0x44, failed byte count from 0x00001000-0x00001fff: > 0x3a2 > ERASE FAILED! > Reading current flash chip contents... done. ERASE FAILED at 0x00001c40 ! > Expected=0xff, Read=0x44, failed byte count from 0x00000000-0x0000ffff: > 0xe2c5 > ERASE FAILED! > Reading current flash chip contents... done. ERASE FAILED at 0x00001c40 ! > Expected=0xff, Read=0x44, failed byte count from 0x00000000-0x0007ffff: > 0x7a92c > ERASE FAILED! > FAILED! > Your flash chip is in an unknown state. > Get help on IRC at chat.freenode.net (channel #flashrom) or > mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"! > -------------------------------------------------------------------------- > DO NOT REBOOT OR POWEROFF! > > A non-text attachment MR-F0000.BIN has been stripped. > It is available at http://paste.flashrom.org/view.php?id=2783 > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom

1 0

Programmers
by Keith Emery 29 Aug '15

29 Aug '15

G'day I read recently you were interested in expanding the list of programmers supported by flashrom. I would recommend supporting those that appear on ebay; as they are cheap and readily available. In Particular the following as it happens to be the one I already own. :) http://www.ebay.com/itm/XTW100-Programmer-USB-Motherboard-BIOS-SPI-FLASH-24… lsusb -v is as follows: Bus 004 Device 002: ID 16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class Couldn't open device, some information will be missing bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x16c0 Van Ooijen Technische Informatica idProduct 0x05dc shared ID for use with libusb bcdDevice 1.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 18 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 (Missing must-be-set bit!) Self Powered MaxPower 20mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0

2 3

[PATCH] WIP: Add support for continious SPI reads
by Nico Huber 28 Aug '15

28 Aug '15

Rebased this old, rotting patch. Not tested in the last two years, but might help to speed up some things (ftdi got pretty fast with this). It has to be enabled per chip (see WINBOND/W25Q64.V for example). --- chipdrivers.h | 1 + cli_common.c | 14 +++++++++++--- flash.h | 23 ++++++++++++++--------- flashchips.c | 4 ++-- spi.c | 5 ++++- spi25.c | 18 ++++++++++++++++++ 6 files changed, 50 insertions(+), 15 deletions(-) diff --git a/chipdrivers.h b/chipdrivers.h index cac94f3..f79195c 100644 --- a/chipdrivers.h +++ b/chipdrivers.h @@ -59,6 +59,7 @@ int spi_byte_program(struct flashctx *flash, unsigned int addr, uint8_t databyte int spi_nbyte_program(struct flashctx *flash, unsigned int addr, const uint8_t *bytes, unsigned int len); int spi_nbyte_read(struct flashctx *flash, unsigned int addr, uint8_t *bytes, unsigned int len); int spi_read_chunked(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len, unsigned int chunksize); +int spi_read_unbound(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len, unsigned int chunksize); int spi_write_chunked(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len, unsigned int chunksize); /* spi25_statusreg.c */ diff --git a/cli_common.c b/cli_common.c index 71cc2dd..289d56a 100644 --- a/cli_common.c +++ b/cli_common.c @@ -73,17 +73,22 @@ void print_chip_support_status(const struct flashchip *chip) if ((chip->tested.probe == BAD) || (chip->tested.probe == NT) || (chip->tested.read == BAD) || (chip->tested.read == NT) || (chip->tested.erase == BAD) || (chip->tested.erase == NT) || - (chip->tested.write == BAD) || (chip->tested.write == NT)){ + (chip->tested.write == BAD) || (chip->tested.write == NT) || + ((chip->feature_bits & FEATURE_UNBOUND_READ) && + chip->tested.uread == BAD || chip->tested.uread == NT)) { msg_cinfo("===\n"); if ((chip->tested.probe == BAD) || (chip->tested.read == BAD) || (chip->tested.erase == BAD) || - (chip->tested.write == BAD)) { + (chip->tested.write == BAD) || + ((chip->feature_bits & FEATURE_UNBOUND_READ) && chip->tested.uread == BAD)) { msg_cinfo("This flash part has status NOT WORKING for operations:"); if (chip->tested.probe == BAD) msg_cinfo(" PROBE"); if (chip->tested.read == BAD) msg_cinfo(" READ"); + if ((chip->feature_bits & FEATURE_UNBOUND_READ) && chip->tested.uread == BAD) + msg_cinfo(" UNBOUND_READ"); if (chip->tested.erase == BAD) msg_cinfo(" ERASE"); if (chip->tested.write == BAD) @@ -93,12 +98,15 @@ void print_chip_support_status(const struct flashchip *chip) if ((chip->tested.probe == NT) || (chip->tested.read == NT) || (chip->tested.erase == NT) || - (chip->tested.write == NT)) { + (chip->tested.write == NT) || + ((chip->feature_bits & FEATURE_UNBOUND_READ) && chip->tested.uread == NT)) { msg_cinfo("This flash part has status UNTESTED for operations:"); if (chip->tested.probe == NT) msg_cinfo(" PROBE"); if (chip->tested.read == NT) msg_cinfo(" READ"); + if ((chip->feature_bits & FEATURE_UNBOUND_READ) && chip->tested.uread == NT) + msg_cinfo(" UNBOUND_READ"); if (chip->tested.erase == NT) msg_cinfo(" ERASE"); if (chip->tested.write == NT) diff --git a/flash.h b/flash.h index 2c2839f..b3962ee 100644 --- a/flash.h +++ b/flash.h @@ -122,6 +122,7 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_UNBOUND_READ (1 << 10) enum test_state { OK = 0, @@ -131,17 +132,20 @@ enum test_state { NA, /* Not applicable (e.g. write support on ROM chips) */ }; -#define TEST_UNTESTED (struct tested){ .probe = NT, .read = NT, .erase = NT, .write = NT } +#define TEST_UNTESTED (struct tested){ .probe = NT, .read = NT, .uread = NT, .erase = NT, .write = NT } -#define TEST_OK_PROBE (struct tested){ .probe = OK, .read = NT, .erase = NT, .write = NT } -#define TEST_OK_PR (struct tested){ .probe = OK, .read = OK, .erase = NT, .write = NT } -#define TEST_OK_PRE (struct tested){ .probe = OK, .read = OK, .erase = OK, .write = NT } -#define TEST_OK_PREW (struct tested){ .probe = OK, .read = OK, .erase = OK, .write = OK } +#define TEST_OK_PROBE (struct tested){ .probe = OK, .read = NT, .uread = NT, .erase = NT, .write = NT } +#define TEST_OK_PR (struct tested){ .probe = OK, .read = OK, .uread = NT, .erase = NT, .write = NT } +#define TEST_OK_PRU (struct tested){ .probe = OK, .read = OK, .uread = OK, .erase = NT, .write = NT } +#define TEST_OK_PRE (struct tested){ .probe = OK, .read = OK, .uread = NT, .erase = OK, .write = NT } +#define TEST_OK_PRUE (struct tested){ .probe = OK, .read = OK, .uread = OK, .erase = OK, .write = NT } +#define TEST_OK_PREW (struct tested){ .probe = OK, .read = OK, .uread = NT, .erase = OK, .write = OK } +#define TEST_OK_PRUEW (struct tested){ .probe = OK, .read = OK, .uread = OK, .erase = OK, .write = OK } -#define TEST_BAD_PROBE (struct tested){ .probe = BAD, .read = NT, .erase = NT, .write = NT } -#define TEST_BAD_PR (struct tested){ .probe = BAD, .read = BAD, .erase = NT, .write = NT } -#define TEST_BAD_PRE (struct tested){ .probe = BAD, .read = BAD, .erase = BAD, .write = NT } -#define TEST_BAD_PREW (struct tested){ .probe = BAD, .read = BAD, .erase = BAD, .write = BAD } +#define TEST_BAD_PROBE (struct tested){ .probe = BAD, .read = NT, .uread = NT, .erase = NT, .write = NT } +#define TEST_BAD_PR (struct tested){ .probe = BAD, .read = BAD, .uread = NT, .erase = NT, .write = NT } +#define TEST_BAD_PRE (struct tested){ .probe = BAD, .read = BAD, .uread = NT, .erase = BAD, .write = NT } +#define TEST_BAD_PREW (struct tested){ .probe = BAD, .read = BAD, .uread = NT, .erase = BAD, .write = BAD } struct flashctx; typedef int (erasefunc_t)(struct flashctx *flash, unsigned int addr, unsigned int blocklen); @@ -170,6 +174,7 @@ struct flashchip { struct tested { enum test_state probe; enum test_state read; + enum test_state uread; enum test_state erase; enum test_state write; } tested; diff --git a/flashchips.c b/flashchips.c index 574ad74..be6383b 100644 --- a/flashchips.c +++ b/flashchips.c @@ -13961,8 +13961,8 @@ const struct flashchip flashchips[] = { .page_size = 256, /* supports SFDP */ /* OTP: 1024B total, 256B reserved; read 0x48; write 0x42, erase 0x44, read ID 0x4B */ - .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP, - .tested = TEST_OK_PREW, + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_UNBOUND_READ, + .tested = TEST_OK_PRUEW, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, .block_erasers = diff --git a/spi.c b/spi.c index 894f73f..a7da50a 100644 --- a/spi.c +++ b/spi.c @@ -85,7 +85,10 @@ int default_spi_read(struct flashctx *flash, uint8_t *buf, unsigned int start, "flashrom(a)flashrom.org\n", __func__); return 1; } - return spi_read_chunked(flash, buf, start, len, max_data); + if (flash->chip->feature_bits & FEATURE_UNBOUND_READ) + return spi_read_unbound(flash, buf, start, len, max_data); + else + return spi_read_chunked(flash, buf, start, len, max_data); } int default_spi_write_256(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len) diff --git a/spi25.c b/spi25.c index af4b6db..34fd7d5 100644 --- a/spi25.c +++ b/spi25.c @@ -978,6 +978,24 @@ int spi_read_chunked(struct flashctx *flash, uint8_t *buf, unsigned int start, } /* + * Read a part of the flash chip. + * Ignore pages as we shall read the data continuously. The only bound is the chunksize. + */ +int spi_read_unbound(struct flashctx *flash, uint8_t *buf, unsigned int start, + unsigned int len, unsigned int chunksize) +{ + int rc = 0; + unsigned int i; + + for (i = start; i < (start + len); i += chunksize) { + rc = spi_nbyte_read(flash, i, buf + (i - start), min(chunksize, start + len - i)); + if (rc) + break; + } + return rc; +} + +/* * Write a part of the flash chip. * FIXME: Use the chunk code from Michael Karcher instead. * Each page is written separately in chunks with a maximum size of chunksize. -- 2.4.6

2 1

FAILED: ASUS P4P800
by Alan Kirby 28 Aug '15

28 Aug '15

Hi Folks Had a result from flashrom that asked me to send this log to you guys. I'm certainly thankful for that. The mainboard flash ROM had (probably still has) malware within it that is persistent. Maybe it's lighteater. Since I haven't fully diagnosed it, I've attached a 64KiB file that is a dump of the boot block: F'0000 - F'FFFF. One of the things it does is prevent afudos (engineer's version) from overwriting the boot block. Another thing it does : if you hit Enter at the afudos command, then pull out the keyboard cable, the Disk Driver (INT 13h handler) throws an error, saying there was a disk read error. That shouldn't happen, so these interrupt handlers are checking up on each other, in order to achieve overall persistence. So, to get round these protections, I was attempting to shift away from FreeDOS and flash the ROM from Linux - Ubuntu (Trust Tahr 6.0), in fact. I see the warning about the mainboard-specific code but I couldn't tally that with any action I should take. I saw that the ASUS P4P800 is supported and that it is autodetected. I also tried putting different strings after mainboard, whilst simply probing the hardware: =ASUS, =P4P800, =ASUS P4P800, =ASUS:P4P800. Each generated an error. Removing the = and everything after it worked - the probe worked without error. That gave me confidence that I'd understood the autodetect part. Regards Alan K # ./flashrom -p internal:mainboard -E flashrom v0.9.6.1-r1563 on Linux 3.14.20 (i686) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "Intel ICH5/ICH5R". Enabling flash write... OK. WARNING: Your mainboard is ASUS P4P800, but the mainboard-specific code has not been tested, and thus will not be executed by default. Depending on your hardware environment, erasing, writing or even probing can fail without running the board specific code. Please see the man page (section PROGRAMMER SPECIFIC INFO, subsection "internal programmer") for details. Unhandled programmer parameters: mainboard Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) at physical address 0xfff80000. Erasing and writing flash chip... ERASE FAILED at 0x00001c40 ! Expected=0xff, Read=0x44, failed byte count from 0x00001000-0x00001fff: 0x3a2 ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00001c40 ! Expected=0xff, Read=0x44, failed byte count from 0x00000000-0x0000ffff: 0xe2c5 ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00001c40 ! Expected=0xff, Read=0x44, failed byte count from 0x00000000-0x0007ffff: 0x7a92c ERASE FAILED! FAILED! Your flash chip is in an unknown state. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"! -------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! A non-text attachment MR-F0000.BIN has been stripped. It is available at http://paste.flashrom.org/view.php?id=2783

1 0

ECS 15-V09-011012: flashrom -V
by Markus Flür 25 Aug '15

25 Aug '15

(Chipset : NVIDIA MCP67) flashrom v0.9.6.1-r1563 on Linux 3.16.0-38-generic (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.9, GCC 4.7.1, little endian Command line (1 args): flashrom -V Please select a programmer with the --programmer parameter. Valid choices are: internal, dummy, nic3com, nicrealtek, gfxnvidia, drkaiser, satasii, ft2232_spi, serprog, buspirate_spi, rayer_spi, pony_spi, nicintel, nicintel_spi, ogp_spi, satamv

1 0

Report on Flashing chip
by Евгений Черкашин 24 Aug '15

24 Aug '15

Hi! I saw Your notification when flashing my Motherboard BIOS. It said that flashing is successful Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P5GD1-VM Version: Rev 1.xx Serial Number: MB-1234567890 Reboot was successful too. CHIP ID: W39V040FA Best regards, Evgeny Cherkashin.

1 0

Phoenix BIOS with NVIDIA MCP55 ROM MAC Address Help Needed
by compevo communications 21 Aug '15

21 Aug '15

We have a huge batch of these servers that our client has hosted with us. 1. They are Dell CS24-NV5 with a Dell rebranded GA-3CESL-RH Motherboard and asked us to update the firmware. 2. They have asked us to help them update their firmware to support 6-core CPUs. 3. The problem is that no support or firmware files seem to be available from Dell (the Gigabyte BIOS is not suitable because it does not recognize or control the chassis fans). 4. flashrom has been great in that we had access to machines with the newer BIOS. We read it with flashrom but and wrote it back to one of their machines. 5. The problem is that it seems the MAC address is stored in the BIOS as well, so it copied the MAC address of the source machine. We cannot have multiple servers with duplicate MAC's for obvious reasons. *What we have tried:* 1.) All the tools mentioned online such as CBROM, Phoenix Mod, etc... have been unsuccessful (they cannot seem to properly access or open these files). *What we need help with:* 1. Can someone make a perl or python script to replace the MAC addresses in the attached ROM? Does it help if we know the MAC addresses currently in the ROM? 2. Or if someone happens to have the 1.89a factory flash for a Dell CS24-NV7 that is even better. 3. Or if someone can modify this ROM to remove the NIC/MCP55 LAN module that contains the MAC addresses (we attempted with CBROM but it cannot read the ROM). Any help would be appreciated. We are willing to pay someone if necessary. Cheers -- compevo communications http://compevo.com Toll-Free: 1-877-347-5238 Vancouver, Canada: 604-484-9873 Hong Kong: 852 5808-3267 Singapore: 6531581387 San Francisco, USA: 415-704-7591

2 2

Gigabyte GA-Z97MX Gaming 5
by XVilka Haos of System 20 Aug '15

20 Aug '15

Hello! Trying to make flashrom working on the Gigabyte GA-Z97MX Gaming 5 mainboard. It has ITE IT8620E Super I/O chip, DualBIOS configuration, thus 2 MXIC MX25L6473E chips. Attaching some logs: http://paste.flashrom.org/view.php?id=2779 Kind regards, XVilka.

1 0

BP4 Open-Drain command line Option
by Cosimo Orlando 19 Aug '15

19 Aug '15

Dear Flashrom Team, I'd like to add a simple feature to your BP4 support to allow the user to set up an open-drain SPI on command line exactly as for pullups option! Enable the pullups without an open-drain setting into configuration is useless, instead with it is very easy to flash an 1.8v eeprom. All details into the topic right here Could you add this feature? Or release a patch? Thanks. Regards, Cosimo Orlando P.S. Many users are looking for a solution right this into Dangerous Prototypes forum. -- *IT engineer in Electronics, Embedded Software Developer & C/D Blogger*

1 0

[PATCH] Add support for SST25WF080B 1 MB flash.
by Ben Gardner 19 Aug '15

19 Aug '15

Apart from the JEDEC ID (621614) the difference from the SST25WF080 is that it lacks op codes 0xAD (AAI Word program) and 0x52 (32K erase). Tested under Linux with spidev. Signed-off-by: Ben Gardner <bgardner(a)wabtec.com> --- flashchips.c | 35 +++++++++++++++++++++++++++++++++++ flashchips.h | 3 ++- 2 files changed, 37 insertions(+), 1 deletion(-) diff --git a/flashchips.c b/flashchips.c index 8b5d1ec..b71bd2c 100644 --- a/flashchips.c +++ b/flashchips.c @@ -11803,6 +11803,41 @@ const struct flashchip flashchips[] = { { .vendor = "SST", + .name = "SST25WF080B", + .bustype = BUS_SPI, + .manufacture_id = SST_ID_62, + .model_id = SST_SST25WF080B, + .total_size = 1024, + .page_size = 256, + .feature_bits = FEATURE_WRSR_EITHER, + .tested = TEST_OK_PREW, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 256} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {64 * 1024, 16} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + }, + }, + .printlock = spi_prettyprint_status_register_sst25, /* *does* have a BP3 but it is useless */ + .unlock = spi_disable_blockprotect_bp3_srwd, + .write = spi_chip_write_256, + .read = spi_chip_read, /* Fast read (0x0B) supported */ + .voltage = {1650, 1950}, + }, + + { + .vendor = "SST", .name = "SST28SF040A", .bustype = BUS_PARALLEL, .manufacture_id = SST_ID, diff --git a/flashchips.h b/flashchips.h index 07ae49d..d6b2b8d 100644 --- a/flashchips.h +++ b/flashchips.h @@ -659,6 +659,7 @@ * byte of device ID is related to log(bitsize) at least for some chips. */ #define SST_ID 0xBF /* SST */ +#define SST_ID_62 0x62 /* SST */ #define SST_SST25LF020_REMS 0x43 /* REMS or RES opcode */ #define SST_SST25WF512 0x2501 #define SST_SST25WF010 0x2502 @@ -669,7 +670,7 @@ * IDs and were not spotted in the wild yet. Their datasheets show a 4 byte long response w/o a vendor ID. */ #define SST_SST25WF020A /* 0x62 0x16 0x12 0x00 */ #define SST_SST25WF040B /* 0x62 0x16 0x13 0x00 */ -#define SST_SST25WF080B /* 0x62 0x16 0x14 0x00 */ +#define SST_SST25WF080B 0x1614 /* 0x62 0x16 0x14 0x00 */ #define SST_SST25VF512_REMS 0x48 /* REMS or RES opcode, same as SST25VF512A */ #define SST_SST25VF010_REMS 0x49 /* REMS or RES opcode, same as SST25VF010A */ #define SST_SST25VF020_REMS 0x43 /* REMS or RES opcode, same as SST25LF020A */ -- 1.9.1 This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

1 0

End user flash tool - Adding new working configurations and testing
by Łukasz Dmitrowski 18 Aug '15

18 Aug '15

Hello, I am looking for people who want to help with testing automatic building of coreboot rom(and other features) with end user flash tool. To make automatic building possible for your machines first I need to prepare a configuration for particular hardware set(s). Until tomorrow I will provide a pdf with description of application features, building process and rest of details.For now best source of info about the app is here: http://blogs.coreboot.org/blog/author/dmitro/ If someone wants to help with testing (and also making a list of working configurations bigger) please contact me and send: * lspci -nn output * cat /sys/class/drm/card0-LVDS-1/edid | edid-decode * dmidecode –t 2 * short description of how you normally proceed with building image for your system (important or unusual steps), are additional option roms or other kinds of action needed? * if it needs factory VGABIOS, which one is working – extracted from memory or extracted from factory BIOS rom? please also attach needed file(s) * coreboot .config file with your configuration Thanks in advance for help! Regards, Lukasz Dmitrowski

1 1

MS7336 (HP Compaq dx2300 Microtower motherboard) successful BIOS update
by Benjamin Bellec 18 Aug '15

18 Aug '15

Hello, I successfully flashed this motherboard with a Winbond flash chip "W39V080FA (1024 kB, FWH)" which is currently tagged as UNTESTED for ERASE and WRITE. http://h20564.www2.hp.com/hpsc/swd/public/readIndex?sp4ts.oid=3353051 I flashed from BIOS version 1.08 to 1.14 (the last one). Note that the BIOS included some DMI data (SKU number, Serial number, UUID, etc.) which have been deleted during the operation. See dmidecode_before/after log files attached for more information. Here are the logs. Regards. -- Benjamin

1 0

Phoenix BIOS with NVIDIA MCP55 ROM MAC Address Help Needed
by compevo communications 16 Aug '15

16 Aug '15

We have a huge batch of these servers that our client has hosted with us. 1. They are Dell CS24-NV5 with a Dell rebranded GA-3CESL-RH Motherboard and asked us to update the firmware. 2. They have asked us to help them update their firmware to support 6-core CPUs. 3. The problem is that no support or firmware files seem to be available from Dell (the Gigabyte BIOS is not suitable because it does not recognize or control the chassis fans). 4. flashrom has been great in that we had access to machines with the newer BIOS. We read it with flashrom but and wrote it back to one of their machines. 5. The problem is that it seems the MAC address is stored in the BIOS as well, so it copied the MAC address of the source machine. We cannot have multiple servers with duplicate MAC's for obvious reasons. *What we have tried:* 1.) All the tools mentioned online such as CBROM, Phoenix Mod, etc... have been unsuccessful (they cannot seem to properly access or open these files). *What we need help with:* 1. Can someone make a perl or python script to replace the MAC addresses in the attached ROM? Does it help if we know the MAC addresses currently in the ROM? 2. Or if someone happens to have the 1.89a factory flash for a Dell CS24-NV7 that is even better. 3. Or if someone can modify this ROM to remove the NIC/MCP55 LAN module that contains the MAC addresses (we attempted with CBROM but it cannot read the ROM). Any help would be appreciated. We are willing to pay someone if necessary. Cheers -- compevo communications http://compevo.com Toll-Free: 1-877-347-5238 Vancouver, Canada: 604-484-9873 Hong Kong: 852 5808-3267 Singapore: 6531581387 San Francisco, USA: 415-704-7591 A non-text attachment DellCS24NV7-GA-3CESL-RH-1.89a-2010.rom has been stripped. It is available at http://paste.flashrom.org/view.php?id=2784

1 0

Dediprogress (was: Re: dediprog: Use command 0x0B only on older SF100s)
by David Hendricks 16 Aug '15

16 Aug '15

(I figured we could use a new thread to track overall progress) A few more tweaks and now writes work, too: https://chromium-review.googlesource.com/#/c/293889 On Sat, Aug 15, 2015 at 6:26 PM, David Hendricks <david.hendricks(a)gmail.com> wrote: > Voilà! > > https://chromium-review.googlesource.com/#/c/293924/ > > Freed of the shackles of Subversion and Patchwork, maybe now I can get > some real work done on this thing. > > On Fri, Aug 14, 2015 at 2:09 AM, 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) >> > Signed-off-by: David Hendricks <dhendrix(a)chromium.org> >> >> Can you push a git tree somewhere with those 'subsequent patches' >> please? I know you said they're just the ones I posted, but I could >> have sworn I'd *tried* what you're doing in this patch, and my testers >> said it didn't work (I only have SF100 locally). >> >> http://git.infradead.org/users/dwmw2/flashrom.git has my version of >> those 'subsequent patches' — can you confirm that your patch works on >> top of that? >> >> -- >> David Woodhouse Open Source Technology Centre >> David.Woodhouse(a)intel.com Intel Corporation >> >> _______________________________________________ >> flashrom mailing list >> flashrom(a)flashrom.org >> http://www.flashrom.org/mailman/listinfo/flashrom >> > >

1 0

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

16 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) > Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Can you push a git tree somewhere with those 'subsequent patches' please? I know you said they're just the ones I posted, but I could have sworn I'd *tried* what you're doing in this patch, and my testers said it didn't work (I only have SF100 locally). http://git.infradead.org/users/dwmw2/flashrom.git has my version of those 'subsequent patches' — can you confirm that your patch works on top of that? -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation

2 1

Supermicro X9SRL-F mainboard
by Adam Hill 15 Aug '15

15 Aug '15

$ sudo flashrom -V flashrom v0.9.5.2-r1530 on Linux 3.10.0-229.el7.x86_64 (x86_64), built with libpci 3.2.0, GCC 4.8.2 20131106 (Red Hat 4.8.2-3), little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 2000M loops per second, 10 myus = 10 us, 100 myus = 95 us, 1000 myus = 955 us, 10000 myus = 9130 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Supermicro" DMI string system-product-name: "X9SRL-F" DMI string system-version: "0123456789" DMI string baseboard-manufacturer: "Supermicro" DMI string baseboard-product-name: "X9SRL-F" DMI string baseboard-version: "0123456789" DMI string chassis-type: "Main Server Chassis" Found chipset "Intel X79" with PCI ID 8086:1d41. 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... 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 disabled 0xff600000/0xff200000 FWH decode disabled 0xff500000/0xff100000 FWH decode disabled 0xff400000/0xff000000 FWH decode disabled Maximum FWH chip size: 0x100000 bytes BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2a WARNING: BIOS region SMM protection is enabled! Root Complex Register Block address = 0xfed1c000 GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3800 0x04: 0x6008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=0 Programming OPCODES... program_opcodes: preop=5006 optype=463b opmenu=05d80302c79f0190 done 0x06: 0x0000 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 0x08: 0x00000000 (FADDR) 0x50: 0x00001a1b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x1a, BRRA 0x1b 0x54: 0x000f0000 FREG0: WARNING: Flash Descriptor region (0x00000000-0x0000ffff) is read-only. 0x58: 0x07ff0400 FREG1: BIOS region (0x00400000-0x007fffff) is read-write. 0x5C: 0x03ff0020 FREG2: WARNING: Management Engine region (0x00020000-0x003fffff) is locked. 0x64: 0x001f0010 FREG4: Platform Data region (0x00010000-0x0001ffff) is read-write. Please send a verbose log to flashrom(a)flashrom.org if this board is not listed on http://flashrom.org/Supported_hardware#Supported_mainboards yet. Writes have been disabled. You can enforce write support with the ich_spi_force programmer option, but it will most likely harm your hardware! If you force flashrom you will get no support if something breaks. 0x90: 0x84 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xf84140 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=1, SME=0, SCF=0 0x94: 0x5006 (PREOP) 0x96: 0x463b (OPTYPE) 0x98: 0x05d80302 (OPMENU) 0x9C: 0xc79f0190 (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x00002005 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0 0xC8: 0x00002005 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0 0xD0: 0x00000000 (FPB) SPI Read Configuration: prefetching enabled, caching enabled, OK. The following protocols are supported: FWH, SPI. Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L10PU, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L40PT, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L80P, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L16PT, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L16PU, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L512, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L010, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L020, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L040, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L080, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L016, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25L032, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for AMIC A25LQ032, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF021, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF041A, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF081, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF081A, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF161, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF321, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF321A, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DF641(A), 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25DQ161, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25F512B, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25FS010, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT25FS040, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT26DF041, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT26DF081A, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT26DF161, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT26DF161A, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT26F004, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45CS1282, 16896 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB011D, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB021D, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB041D, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB081D, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB161D, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB321C, 4224 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB321D, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel AT45DB642D, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for EMST F25L008A, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B05, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B05T, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B10, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B10T, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B20, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B20T, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B40T, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B80T, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B16T, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B32T, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25B64T, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F05, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F10, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F20, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25F32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25Q40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25Q80(A), 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25Q32(A/B), 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon EN25QH16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q20, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for GigaDevice GD25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L512, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L1005, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L2005, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L4005, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L8005, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L1605, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L1635D, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L1635E, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L3205, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L3235D, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L6405, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix MX25L12805, 16384 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Numonyx M25PE10, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Numonyx M25PE20, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Numonyx M25PE40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Numonyx M25PE80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Numonyx M25PE16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Numonyx N25Q064, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC Pm25LV010, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC Pm25LV016B, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC Pm25LV020, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC Pm25LV040, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC Pm25LV080B, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC Pm25LV512, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Sanyo LF25FW203A, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Spansion S25FL004A, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Spansion S25FL008A, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Spansion S25FL016A, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Spansion S25FL032A, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for SST SST25LF040A, 512 kB: program_opcodes: preop=5006 optype=462b opmenu=05ab0302c79f0190 on-the-fly OPCODE (0xAB) re-programmed, op-pos=2 probe_spi_res2: id1 0x16, id2 0x16 Probing for SST SST25LF080A, 1024 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for SST SST25VF010, 128 kB: probe_spi_rems: id1 0xef, id2 0x16 Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for SST SST25VF032B, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for SST SST25VF064C, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for SST SST25VF040, 512 kB: probe_spi_rems: id1 0xef, id2 0x16 Probing for SST SST25VF040B, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for SST SST25VF040B.REMS, 512 kB: probe_spi_rems: id1 0xef, id2 0x16 Probing for SST SST25VF080B, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P05-A, 64 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P05, 64 kB: Ignoring RES in favour of RDID. Probing for ST M25P10-A, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P10, 128 kB: Ignoring RES in favour of RDID. Probing for ST M25P20, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P40-old, 512 kB: Ignoring RES in favour of RDID. Probing for ST M25P80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25P128, 16384 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25PX16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25PX32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST M25PX64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25Q80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25Q32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Chip status register is 00 Found Winbond flash chip "W25Q64" (8192 kB, SPI) at physical address 0xff800000. Probing for Winbond W25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X10, 128 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X20, 256 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X40, 512 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X80, 1024 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X16, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X32, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Winbond W25X64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Unknown SFDP-capable chip, 0 kB: program_opcodes: preop=5006 optype=462b opmenu=055a0302c79f0190 on-the-fly OPCODE (0x5A) re-programmed, op-pos=2 Parsing JEDEC flash parameter table... done. Probing for AMIC unknown AMIC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Atmel unknown Atmel SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Eon unknown Eon SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Macronix unknown Macronix SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for PMC unknown PMC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for SST unknown SST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for ST unknown ST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Sanyo unknown Sanyo SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xef, id2 0x16 Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x7a, id2 0xcc, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: Chip size 2048 kB is bigger than supported size 1024 kB of chipset/board/programmer for FWH interface, probe/read/erase/write may fail. 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 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: Chip size 2048 kB is bigger than supported size 1024 kB of chipset/board/programmer for FWH interface, probe/read/erase/write may fail. 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 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0x33, id2 0x03, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0x33, id2 0x03, 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 0x0b, id2 0xbb, id1 is normal flash content, id2 is normal flash content Found Winbond flash chip "W25Q64" (8192 kB, SPI). This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). No operations were specified. Restoring MMIO space at 0x7f3cae4088a0 Restoring MMIO space at 0x7f3cae40889c Restoring MMIO space at 0x7f3cae408898 Restoring MMIO space at 0x7f3cae408896 Restoring MMIO space at 0x7f3cae408894 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

[PATCH 0/4] Libflashrom
by Łukasz Dmitrowski 15 Aug '15

15 Aug '15

Hello, I improved and extended libflashrom patch, so I am posting it for a second review. I based on work of Nico Huber and Anton Kochkov. As Nico Huber's patch has been already sent some time ago I will send only Anton Kochkov's building and compilation fixes (thanks for sharing it with me) and my changes. Content: 1 / 4 - Fix libflashrom compilation (by Anton Kochkov) 2 / 4 - Fix libflashrom building (by Anton Kochkov) 3 / 4 - Added querying functions to libflashrom 4 / 4 - Added function which returns string list of multiple chips found I will be grateful for your opinions - it helps me to improve the patch. All this code you can also find here: https://github.com/lukaszdmitrowski/flashrom/tree/libflashrom Regards, Lukasz Dmitrowski

2 1

[PATCH 3/4] Libflashrom - Querying functions
by Łukasz Dmitrowski 14 Aug '15

14 Aug '15

Added querying functions Signed-off-by: Lukasz Dmitrowski <lukasz.dmitrowski(a)gmail.com> --- Makefile | 4 +- libflashrom.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- libflashrom.h | 40 +++++++++++++++++ 3 files changed, 180 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2c7fccd..0c97268 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) udelay.o +LIBFLASHROM_OBJS = $(CHIP_OBJS) $(PROGRAMMER_OBJS) $(LIB_OBJS) OBJS = $(CLI_OBJS) $(LIBFLASHROM_OBJS) all: hwlibs features $(PROGRAM)$(EXEC_SUFFIX) $(PROGRAM).8 @@ -737,7 +737,7 @@ endif $(PROGRAM)$(EXEC_SUFFIX): $(OBJS) $(CC) $(LDFLAGS) -o $(PROGRAM)$(EXEC_SUFFIX) $(OBJS) $(LIBS) $(PCILIBS) $(FEATURE_LIBS) $(USBLIBS) -libflashrom.a: $(LIBFLASHROM_OBJS) +libflashrom.a: $(LIBFLASHROM_OBJS) print.o cli_common.o $(AR) rcs $@ $^ $(RANLIB) $@ diff --git a/libflashrom.c b/libflashrom.c index c96a2e9..3b94215 100644 --- a/libflashrom.c +++ b/libflashrom.c @@ -103,7 +103,144 @@ int print(const enum msglevel level, const char *const fmt, ...) * @{ */ -/* TBD */ +/** + * @brief Returns flashrom version + * @return Flashrom version + */ +const char *fl_version(void) +{ + return flashrom_version; +} + +/** + * @brief Returns a list of supported programmers + * @return List of supported programmers + */ +const char **fl_supported_programmers(void) +{ + enum programmer p = 0; + const char **supported_programmers = NULL; + + supported_programmers = malloc((PROGRAMMER_INVALID + 1) * sizeof(char*)); + if (!supported_programmers) { + msg_gerr("Out of memory!"); + } else { + for (; p < PROGRAMMER_INVALID; ++p) { + supported_programmers[p] = programmer_table[p].name; + } + supported_programmers[PROGRAMMER_INVALID] = NULL; + } + + return supported_programmers; +} + +/** + * @brief Returns list of supported flash ROM chips + * @return List of supported flash ROM chips + */ +fl_flashchip_info *fl_supported_flash_chips(void) +{ + int i = 0; + fl_flashchip_info *flashchip_info = NULL; + + flashchip_info = malloc(flashchips_size * sizeof(fl_flashchip_info)); + if (!flashchip_info) { + msg_gerr("Out of memory!"); + } else { + for (; i < flashchips_size; ++i) { + flashchip_info[i].vendor = flashchips[i].vendor; + flashchip_info[i].name = flashchips[i].name; + flashchip_info[i].tested.erase = flashchips[i].tested.erase; + flashchip_info[i].tested.probe = flashchips[i].tested.probe; + flashchip_info[i].tested.read = flashchips[i].tested.read; + flashchip_info[i].tested.write = flashchips[i].tested.write; + flashchip_info[i].total_size = flashchips[i].total_size; + } + } + + return flashchip_info; +} + +/** + * @brief Returns list of supported mainboards + * @return List of supported mainborads + */ +fl_board_info *fl_supported_boards(void) +{ + const struct board_info *binfo = boards_known; + fl_board_info *supported_boards = NULL; + int boards_known_size = 0; + int i = 0; + + while ((binfo++)->vendor) + ++boards_known_size; + binfo = boards_known; + /* add place for {0} */ + ++boards_known_size; + + supported_boards = malloc(boards_known_size * sizeof(fl_board_info)); + + if (!supported_boards) { + msg_gerr("Out of memory!"); + } else { + for (; i < boards_known_size; ++i) { + supported_boards[i].vendor = binfo[i].vendor; + supported_boards[i].name = binfo[i].name; + supported_boards[i].working = binfo[i].working; + } + } + + return supported_boards; +} + +/** + * @brief Returns list of supported chipsets + * @return List of supported chipsets + */ +fl_chipset_info *fl_supported_chipsets(void) +{ + const struct penable *chipset = chipset_enables; + fl_chipset_info *supported_chipsets = NULL; + int chipset_enbales_size = 0; + int i = 0; + + while ((chipset++)->vendor_name) + ++chipset_enbales_size; + chipset = chipset_enables; + /* add place for {0}*/ + ++chipset_enbales_size; + + supported_chipsets = malloc(chipset_enbales_size * sizeof(fl_chipset_info)); + + if (!supported_chipsets) { + msg_gerr("Out of memory!"); + } else { + for (; i < chipset_enbales_size; ++i) { + supported_chipsets[i].vendor = chipset[i].vendor_name; + supported_chipsets[i].chipset = chipset[i].device_name; + supported_chipsets[i].status = chipset[i].status; + } + } + + return supported_chipsets; +} + +/** + * @brief Frees fl_*_info and string lists allocated by flashrom + * @param Pointer to block of memory which should be freed + * @return 0 on success + * 1 on null pointer error + */ +int fl_data_free(void *const p) +{ + if (!p) { + msg_gerr("Null pointer!"); + return 1; + } else { + free(p); + return 0; + } +} /** @} */ /* end fl-query */ diff --git a/libflashrom.h b/libflashrom.h index 2077407..5308fa3 100644 --- a/libflashrom.h +++ b/libflashrom.h @@ -38,6 +38,46 @@ typedef enum { /* This has to match enum msglevel. */ typedef int(fl_log_callback_t)(fl_log_level_t, const char *format, va_list); void fl_set_log_callback(fl_log_callback_t *); +typedef enum { + FL_TESTED_OK = 0, + FL_TESTED_NT = 1, + FL_TESTED_BAD = 2, + FL_TESTED_DEP = 3, + FL_TESTED_NA = 4, +} fl_test_state; + +typedef struct { + const char *vendor; + const char *name; + unsigned int total_size; + + struct fl_tested { + fl_test_state probe; + fl_test_state read; + fl_test_state erase; + fl_test_state write; + } tested; +} fl_flashchip_info; + +typedef struct { + const char *vendor; + const char *name; + fl_test_state working; +} fl_board_info; + +typedef struct { + const char *vendor; + const char *chipset; + fl_test_state status; +} fl_chipset_info; + +const char** fl_supported_programmers(void); +const char* fl_version(void); +fl_flashchip_info *fl_supported_flash_chips(void); +fl_board_info *fl_supported_boards(void); +fl_chipset_info *fl_supported_chipsets(void); +int fl_data_free(void *const p); + int fl_programmer_init(const char *prog_name, const char *prog_params); int fl_programmer_shutdown(void); -- 2.1.4

1 1

[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

Re: [flashrom] about CH341A programmer
by Márton Miklós 18 Jul '15

18 Jul '15

Hi, Someone had already reverse engineered the protocol and created an SPI flasher tool for that: https://github.com/setarcos/ch341prog Using this code it won't be a big issue to add flashrom support. Regards, Miklos Marton > I can write to log usb activity with operations with CH341A usb > programmer from original 1.18 software with operation read, write.. > this log is very happy with support of CH341A in flashrom? >> On Tue, 6 Jan 2015 05:20:22 +0500 >> novoagansk(a)gmail.com wrote: >>> ????????????, . >>> >>> Sorry, Please tell me about: how add support for this programmer in flashrom? >>> >>> If you can - please tell me "example" how USB device parallel add in >>> flashrom. >>> >>> or other links to support any usb devices in flashrom.. >>> >>> >>> CH341A usb chip: >>> http://www.seekic.com/circuit_diagram/Basic_Circuit/USB_to_parallel_serial_… >> There is not much information available about that chip. The available >> English datasheets do not cover the most important part: the >> communication protocol between the chip and the host. Without that it >> is not exactly trivial to add support for it in flashrom. One has to >> reverse engineer the protocol first. Members of the flashrom community >> have done that for the Dediprog SF100 once but they are no longer >> active, so please don't expect it to be done. dediprog.c is probably >> the most similar programmer flashrom currently supports because it is >> the only one that uses a completely custom USB protocol. > > > Üdvözlettel, Márton Miklós +36-70-39-60-009 Üdvözlettel, Márton Miklós +36-70-39-60-009

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom