| .TH FLASHROM 8 "Feb 15, 2012" |
| .SH NAME |
| flashrom \- detect, read, write, verify and erase flash chips |
| .SH SYNOPSIS |
| .B flashrom \fR[\fB\-n\fR] [\fB\-V\fR] [\fB\-f\fR] [\fB\-h\fR|\fB\-R\fR|\ |
| \fB\-L\fR|\fB\-z\fR|\fB\-E\fR|\fB\-r\fR <file>|\fB\-w\fR <file>|\ |
| \fB\-v\fR <file>] |
| [\fB\-c\fR <chipname>] \ |
| [\fB\-l\fR <file>] |
| [\fB\-i\fR <image>] [\fB\-p\fR <programmername>[:<parameters>]] |
| .SH DESCRIPTION |
| .B flashrom |
| is a utility for detecting, reading, writing, verifying and erasing flash |
| chips. It's often used to flash BIOS/EFI/coreboot/firmware images in-system |
| using a supported mainboard. However, it also supports various external |
| PCI/USB/parallel-port/serial-port based devices which can program flash chips, |
| including some network cards (NICs), SATA/IDE controller cards, graphics cards, |
| the Bus Pirate device, various FTDI FT2232/FT4232H based USB devices, and more. |
| .PP |
| It supports a wide range of DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32, TSOP40, |
| TSOP48, and BGA chips, which use various protocols such as LPC, FWH, |
| parallel flash, or SPI. |
| .SH OPTIONS |
| .B IMPORTANT: |
| Please note that the command line interface for flashrom will change before |
| flashrom 1.0. Do not use flashrom in scripts or other automated tools without |
| checking that your flashrom version won't interpret options in a different way. |
| .PP |
| You can specify one of |
| .BR \-h ", " \-R ", " \-L ", " \-z ", " \-E ", " \-r ", " \-w ", " \-v |
| or no operation. |
| If no operation is specified, flashrom will only probe for flash chips. It is |
| recommended that if you try flashrom the first time on a system, you run it |
| in probe-only mode and check the output. Also you are advised to make a |
| backup of your current ROM contents with |
| .B \-r |
| before you try to write a new image. |
| .TP |
| .B "\-r, \-\-read <file>" |
| Read flash ROM contents and save them into the given |
| .BR <file> . |
| If the file already exists, it will be overwritten. |
| .TP |
| .B "\-w, \-\-write <file>" |
| Write |
| .B <file> |
| into flash ROM. This will first automatically |
| .B erase |
| the chip, then write to it. |
| .sp |
| In the process the chip is also read several times. First an in-memory backup |
| is made for disaster recovery and to be able to skip regions that are |
| already equal to the image file. This copy is updated along with the write |
| operation. In case of erase errors it is even re-read completely. After |
| writing has finished and if verification is enabled, the whole flash chip is |
| read out and compared with the input image. |
| .TP |
| .B "\-n, \-\-noverify" |
| Skip the automatic verification of flash ROM contents after writing. Using this |
| option is |
| .B not |
| recommended, you should only use it if you know what you are doing and if you |
| feel that the time for verification takes too long. |
| .sp |
| Typical usage is: |
| .B "flashrom \-n \-w <file>" |
| .sp |
| This option is only useful in combination with |
| .BR \-\-write . |
| .TP |
| .B "\-v, \-\-verify <file>" |
| Verify the flash ROM contents against the given |
| .BR <file> . |
| .TP |
| .B "\-E, \-\-erase" |
| Erase the flash ROM chip. |
| .TP |
| .B "\-V, \-\-verbose" |
| More verbose output. This option can be supplied multiple times |
| (max. 3 times, i.e. |
| .BR \-VVV ) |
| for even more debug output. |
| .TP |
| .B "\-c, \-\-chip" <chipname> |
| Probe only for the specified flash ROM chip. This option takes the chip name as |
| printed by |
| .B "flashrom \-L" |
| without the vendor name as parameter. Please note that the chip name is |
| case sensitive. |
| .TP |
| .B "\-f, \-\-force" |
| Force one or more of the following actions: |
| .sp |
| * Force chip read and pretend the chip is there. |
| .sp |
| * Force chip access even if the chip is bigger than the maximum supported \ |
| size for the flash bus. |
| .sp |
| * Force erase even if erase is known bad. |
| .sp |
| * Force write even if write is known bad. |
| .TP |
| .B "\-l, \-\-layout <file>" |
| Read ROM layout from |
| .BR <file> . |
| .sp |
| flashrom supports ROM layouts. This allows you to flash certain parts of |
| the flash chip only. A ROM layout file looks like follows: |
| .sp |
| 00000000:00008fff gfxrom |
| 00009000:0003ffff normal |
| 00040000:0007ffff fallback |
| .sp |
| i.e.: |
| startaddr:endaddr name |
| .sp |
| All addresses are offsets within the file, not absolute addresses! |
| If you only want to update the normal image in a ROM you can say: |
| .sp |
| .B " flashrom \-\-layout rom.layout \-\-image normal \-w agami_aruma.rom" |
| .sp |
| To update normal and fallback but leave the VGA BIOS alone, say: |
| .sp |
| .B " flashrom \-l rom.layout \-i normal \" |
| .br |
| .B " \-i fallback \-w agami_aruma.rom" |
| .sp |
| Currently overlapping sections are not supported. |
| .TP |
| .B "\-i, \-\-image <name>" |
| Only flash image |
| .B <name> |
| from flash layout. |
| .TP |
| .B "\-L, \-\-list\-supported" |
| List the flash chips, chipsets, mainboards, and external programmers |
| (including PCI, USB, parallel port, and serial port based devices) |
| supported by flashrom. |
| .sp |
| There are many unlisted boards which will work out of the box, without |
| special support in flashrom. Please let us know if you can verify that |
| other boards work or do not work out of the box. |
| .sp |
| .B IMPORTANT: |
| For verification you have |
| to test an ERASE and/or WRITE operation, so make sure you only do that |
| if you have proper means to recover from failure! |
| .TP |
| .B "\-z, \-\-list\-supported-wiki" |
| Same as |
| .BR \-\-list\-supported , |
| but outputs the supported hardware in MediaWiki syntax, so that it can be |
| easily pasted into the wiki page at |
| .BR http://www.flashrom.org/ . |
| Please note that MediaWiki output is not compiled in by default. |
| .TP |
| .B "\-p, \-\-programmer <name>[:parameter[,parameter[,parameter]]]" |
| Specify the programmer device. Currently supported are: |
| .sp |
| .BR "* internal" " (default, for in-system flashing in the mainboard)" |
| .sp |
| .BR "* dummy" " (virtual programmer for testing flashrom)" |
| .sp |
| .BR "* nic3com" " (for flash ROMs on 3COM network cards)" |
| .sp |
| .BR "* nicrealtek" " (for flash ROMs on Realtek network cards)" |
| .sp |
| .BR "* nicsmc1211" " (for flash ROMs on RTL8139-compatible SMC2 network cards)" |
| .sp |
| .BR "* nicnatsemi" " (for flash ROMs on National Semiconductor DP838* network \ |
| cards)" |
| .sp |
| .BR "* nicintel" " (for parallel flash ROMs on Intel 10/100Mbit network cards) |
| .sp |
| .BR "* gfxnvidia" " (for flash ROMs on NVIDIA graphics cards)" |
| .sp |
| .BR "* drkaiser" " (for flash ROMs on Dr. Kaiser PC-Waechter PCI cards)" |
| .sp |
| .BR "* satasii" " (for flash ROMs on Silicon Image SATA/IDE controllers)" |
| .sp |
| .BR "* satamv" " (for flash ROMs on Marvell SATA controllers)" |
| .sp |
| .BR "* atahpt" " (for flash ROMs on Highpoint ATA/RAID controllers)" |
| .sp |
| .BR "* ft2232_spi" " (for SPI flash ROMs attached to an FT2232/FT4232H family \ |
| based USB SPI programmer), including the DLP Design DLP-USB1232H, \ |
| FTDI FT2232H Mini-Module, FTDI FT4232H Mini-Module, openbiosprog-spi, Amontec \ |
| JTAGkey/JTAGkey-tiny/JTAGkey-2, Dangerous Prototypes Bus Blaster, \ |
| Olimex ARM-USB-TINY/-H, Olimex ARM-USB-OCD/-H, TIAO/DIYGADGET USB |
| Multi-Protocol Adapter (TUMPA), and GOEPEL PicoTAP. |
| .sp |
| .BR "* serprog" " (for flash ROMs attached to a programmer speaking serprog), \ |
| including AVR flasher by Urja Rannikko, AVR flasher by eightdot, \ |
| Arduino Mega flasher by fritz, InSystemFlasher by Juhana Helovuo, and \ |
| atmegaXXu2-flasher by Stefan Tauner." |
| .sp |
| .BR "* buspirate_spi" " (for SPI flash ROMs attached to a Bus Pirate)" |
| .sp |
| .BR "* dediprog" " (for SPI flash ROMs attached to a Dediprog SF100)" |
| .sp |
| .BR "* rayer_spi" " (for SPI flash ROMs attached to a RayeR parport " |
| or Xilinx DLC5 compatible cable) |
| .sp |
| .BR "* nicintel_spi" " (for SPI flash ROMs on Intel Gigabit network cards)" |
| .sp |
| .BR "* ogp_spi" " (for SPI flash ROMs on Open Graphics Project graphics card)" |
| .sp |
| .BR "* linux_spi" " (for SPI flash ROMs accessible via /dev/spidevX.Y on Linux)" |
| .sp |
| Some programmers have optional or mandatory parameters which are described |
| in detail in the |
| .B PROGRAMMER SPECIFIC INFO |
| section. Support for some programmers can be disabled at compile time. |
| .B "flashrom \-h" |
| lists all supported programmers. |
| .TP |
| .B "\-h, \-\-help" |
| Show a help text and exit. |
| .TP |
| .B "\-R, \-\-version" |
| Show version information and exit. |
| .SH PROGRAMMER SPECIFIC INFO |
| Some programmer drivers accept further parameters to set programmer-specific |
| parameters. These parameters are separated from the programmer name by a |
| colon. While some programmers take arguments at fixed positions, other |
| programmers use a key/value interface in which the key and value is separated |
| by an equal sign and different pairs are separated by a comma or a colon. |
| .SS |
| .BR "internal " programmer |
| .TP |
| .B Board Enables |
| .sp |
| Some mainboards require to run mainboard specific code to enable flash erase |
| and write support (and probe support on old systems with parallel flash). |
| The mainboard brand and model (if it requires specific code) is usually |
| autodetected using one of the following mechanisms: If your system is |
| running coreboot, the mainboard type is determined from the coreboot table. |
| Otherwise, the mainboard is detected by examining the onboard PCI devices |
| and possibly DMI info. If PCI and DMI do not contain information to uniquely |
| identify the mainboard (which is the exception), or if you want to override |
| the detected mainboard model, you can specify the mainboard using the |
| .sp |
| .B " flashrom \-p internal:mainboard=[<vendor>:]<board>" |
| syntax. |
| .sp |
| See the 'Known boards' or 'Known laptops' section in the output |
| of 'flashrom \-L' for a list of boards which require the specification of |
| the board name, if no coreboot table is found. |
| .sp |
| Some of these board-specific flash enabling functions (called |
| .BR "board enables" ) |
| in flashrom have not yet been tested. If your mainboard is detected needing |
| an untested board enable function, a warning message is printed and the |
| board enable is not executed, because a wrong board enable function might |
| cause the system to behave erratically, as board enable functions touch the |
| low-level internals of a mainboard. Not executing a board enable function |
| (if one is needed) might cause detection or erasing failure. If your board |
| protects only part of the flash (commonly the top end, called boot block), |
| flashrom might encounter an error only after erasing the unprotected part, |
| so running without the board-enable function might be dangerous for erase |
| and write (which includes erase). |
| .sp |
| The suggested procedure for a mainboard with untested board specific code is |
| to first try to probe the ROM (just invoke flashrom and check that it |
| detects your flash chip type) without running the board enable code (i.e. |
| without any parameters). If it finds your chip, fine. Otherwise, retry |
| probing your chip with the board-enable code running, using |
| .sp |
| .B " flashrom \-p internal:boardenable=force" |
| .sp |
| If your chip is still not detected, the board enable code seems to be broken |
| or the flash chip unsupported. Otherwise, make a backup of your current ROM |
| contents (using |
| .BR \-r ) |
| and store it to a medium outside of your computer, like |
| a USB drive or a network share. If you needed to run the board enable code |
| already for probing, use it for reading too. Now you can try to write the |
| new image. You should enable the board enable code in any case now, as it |
| has been written because it is known that writing/erasing without the board |
| enable is going to fail. In any case (success or failure), please report to |
| the flashrom mailing list, see below. |
| .sp |
| .TP |
| .B Coreboot |
| .sp |
| On systems running coreboot, flashrom checks whether the desired image matches |
| your mainboard. This needs some special board ID to be present in the image. |
| If flashrom detects that the image you want to write and the current board |
| do not match, it will refuse to write the image unless you specify |
| .sp |
| .B " flashrom \-p internal:boardmismatch=force" |
| .TP |
| .B ITE IT87 Super I/O |
| .sp |
| If your mainboard uses an ITE IT87 series Super I/O for LPC<->SPI flash bus |
| translation, flashrom should autodetect that configuration. If you want to |
| set the I/O base port of the IT87 series SPI controller manually instead of |
| using the value provided by the BIOS, use the |
| .sp |
| .B " flashrom \-p internal:it87spiport=portnum" |
| .sp |
| syntax where |
| .B portnum |
| is the I/O port number (must be a multiple of 8). In the unlikely case |
| flashrom doesn't detect an active IT87 LPC<->SPI bridge, please send a bug |
| report so we can diagnose the problem. |
| .sp |
| .TP |
| .B Intel chipsets |
| .sp |
| If you have an Intel chipset with an ICH8 or later southbridge with SPI flash |
| attached, and if a valid descriptor was written to it (e.g. by the vendor), the |
| chipset provides an alternative way to access the flash chip(s) named |
| .BR "Hardware Sequencing" . |
| It is much simpler than the normal access method (called |
| .BR "Software Sequencing" ")," |
| but does not allow the software to choose the SPI commands to be sent. |
| You can use the |
| .sp |
| .B " flashrom \-p internal:ich_spi_mode=value" |
| .sp |
| syntax where value can be |
| .BR auto ", " swseq " or " hwseq . |
| By default |
| .RB "(or when setting " ich_spi_mode=auto ) |
| the module tries to use swseq and only activates hwseq if need be (e.g. if |
| important opcodes are inaccessible due to lockdown; or if more than one flash |
| chip is attached). The other options (swseq, hwseq) select the respective mode |
| (if possible). |
| .sp |
| ICH8 and later southbridges may also have locked address ranges of different |
| kinds if a valid descriptor was written to it. The flash address space is then |
| partitioned in multiple so called "Flash Regions" containing the host firmware, |
| the ME firmware and so on respectively. The flash descriptor can also specify up |
| to 5 so called "Protected Regions", which are freely chosen address ranges |
| independent from the aforementioned "Flash Regions". All of them can be write |
| and/or read protected individually. If flashrom detects such a lock it will |
| disable write support unless the user forces it with the |
| .sp |
| .B " flashrom \-p internal:ich_spi_force=yes" |
| .sp |
| syntax. If this leads to erase or write accesses to the flash it would most |
| probably bring it into an inconsistent and unbootable state and we will not |
| provide any support in such a case. |
| .sp |
| If you have an Intel chipset with an ICH6 or later southbridge and if you want |
| to set specific IDSEL values for a non-default flash chip or an embedded |
| controller (EC), you can use the |
| .sp |
| .B " flashrom \-p internal:fwh_idsel=value" |
| .sp |
| syntax where value is the 48-bit hexadecimal raw value to be written in the |
| IDSEL registers of the Intel southbridge. The upper 32 bits use one hex digit |
| each per 512 kB range between 0xffc00000 and 0xffffffff, and the lower 16 bits |
| use one hex digit each per 1024 kB range between 0xff400000 and 0xff7fffff. |
| The rightmost hex digit corresponds with the lowest address range. All address |
| ranges have a corresponding sister range 4 MB below with identical IDSEL |
| settings. The default value for ICH7 is given in the example below. |
| .sp |
| Example: |
| .B "flashrom \-p internal:fwh_idsel=0x001122334567" |
| .TP |
| .B Laptops |
| .sp |
| Using flashrom on laptops is dangerous and may easily make your hardware |
| unusable (see also the |
| .B BUGS |
| section). The embedded controller (EC) in these |
| machines often interacts badly with flashing. |
| .B http://www.flashrom.org/Laptops |
| has more information. For example the EC firmware sometimes resides on the same |
| flash chip as the host firmware. While flashrom tries to change the contents of |
| that memory the EC might need to fetch new instructions or data from it and |
| could stop working correctly. Probing for and reading from the chip may also |
| irritate your EC and cause fan failure, backlight failure, sudden poweroff, and |
| other nasty effects. flashrom will attempt to detect if it is running on a |
| laptop and abort immediately for safety reasons if it clearly identifies the |
| host computer as one. If you want to proceed anyway at your own risk, use |
| .sp |
| .B " flashrom \-p internal:laptop=force_I_want_a_brick" |
| .sp |
| We will not help you if you force flashing on a laptop because this is a really |
| dumb idea. |
| .sp |
| You have been warned. |
| .sp |
| Currently we rely on the chassis type encoded in the DMI/SMBIOS data to detect |
| laptops. Some vendors did not implement those bits correctly or set them to |
| generic and/or dummy values. flashrom will then issue a warning and bail out |
| like above. In this case you can use |
| .sp |
| .B " flashrom \-p internal:laptop=this_is_not_a_laptop" |
| .sp |
| to tell flashrom (at your own risk) that it does not running on a laptop. |
| .SS |
| .BR "dummy " programmer |
| The dummy programmer operates on a buffer in memory only. It provides a safe |
| and fast way to test various aspects of flashrom and is mainly used in |
| development and while debugging. |
| .sp |
| It is able to emulate some chips to a certain degree (basic |
| identify/read/erase/write operations work). |
| .sp |
| An optional parameter specifies the bus types it |
| should support. For that you have to use the |
| .sp |
| .B " flashrom \-p dummy:bus=[type[+type[+type]]]" |
| .sp |
| syntax where |
| .B type |
| can be |
| .BR parallel ", " lpc ", " fwh ", " spi |
| in any order. If you specify bus without type, all buses will be disabled. |
| If you do not specify bus, all buses will be enabled. |
| .sp |
| Example: |
| .B "flashrom \-p dummy:bus=lpc+fwh" |
| .sp |
| The dummy programmer supports flash chip emulation for automated self-tests |
| without hardware access. If you want to emulate a flash chip, use the |
| .sp |
| .B " flashrom \-p dummy:emulate=chip" |
| .sp |
| syntax where |
| .B chip |
| is one of the following chips (please specify only the chip name, not the |
| vendor): |
| .sp |
| .RB "* ST " M25P10.RES " SPI flash chip (RES, page write)" |
| .sp |
| .RB "* SST " SST25VF040.REMS " SPI flash chip (REMS, byte write)" |
| .sp |
| .RB "* SST " SST25VF032B " SPI flash chip (RDID, AAI write)" |
| .sp |
| Example: |
| .B "flashrom -p dummy:emulate=SST25VF040.REMS" |
| .TP |
| .B Persistent images |
| .sp |
| If you use flash chip emulation, flash image persistence is available as well |
| by using the |
| .sp |
| .B " flashrom \-p dummy:emulate=chip,image=image.rom" |
| .sp |
| syntax where |
| .B image.rom |
| is the file where the simulated chip contents are read on flashrom startup and |
| where the chip contents on flashrom shutdown are written to. |
| .sp |
| Example: |
| .B "flashrom -p dummy:emulate=M25P10.RES,image=dummy.bin" |
| .TP |
| .B SPI write chunk size |
| .sp |
| If you use SPI flash chip emulation for a chip which supports SPI page write |
| with the default opcode, you can set the maximum allowed write chunk size with |
| the |
| .sp |
| .B " flashrom \-p dummy:emulate=chip,spi_write_256_chunksize=size" |
| .sp |
| syntax where |
| .B size |
| is the number of bytes (min. 1, max. 256). |
| .sp |
| Example: |
| .sp |
| .B " flashrom -p dummy:emulate=M25P10.RES,spi_write_256_chunksize=5" |
| .TP |
| .B SPI blacklist |
| .sp |
| To simulate a programmer which refuses to send certain SPI commands to the |
| flash chip, you can specify a blacklist of SPI commands with the |
| .sp |
| .B " flashrom -p dummy:spi_blacklist=commandlist" |
| .sp |
| syntax where commandlist is a list of two-digit hexadecimal representations of |
| SPI commands. If commandlist is e.g. 0302, flashrom will behave as if the SPI |
| controller refuses to run command 0x03 (READ) and command 0x02 (WRITE). |
| commandlist may be up to 512 characters (256 commands) long. |
| Implementation note: flashrom will detect an error during command execution. |
| .sp |
| .TP |
| .B SPI ignorelist |
| .sp |
| To simulate a flash chip which ignores (doesn't support) certain SPI commands, |
| you can specify an ignorelist of SPI commands with the |
| .sp |
| .B " flashrom -p dummy:spi_ignorelist=commandlist" |
| .sp |
| syntax where commandlist is a list of two-digit hexadecimal representations of |
| SPI commands. If commandlist is e.g. 0302, the emulated flash chip will ignore |
| command 0x03 (READ) and command 0x02 (WRITE). commandlist may be up to 512 |
| characters (256 commands) long. |
| Implementation note: flashrom won't detect an error during command execution. |
| .SS |
| .BR "nic3com" , " nicrealtek" , " nicsmc1211" , " nicnatsemi" , " nicintel\ |
| " , " nicintel_spi" , " gfxnvidia" , " ogp_spi" , " drkaiser" , " satasii\ |
| " , " satamv" ", and " atahpt " programmers |
| These programmers have an option to specify the PCI address of the card |
| your want to use, which must be specified if more than one card supported |
| by the selected programmer is installed in your system. The syntax is |
| .sp |
| .BR " flashrom \-p xxxx:pci=bb:dd.f" , |
| .sp |
| where |
| .B xxxx |
| is the name of the programmer |
| .B bb |
| is the PCI bus number, |
| .B dd |
| is the PCI device number, and |
| .B f |
| is the PCI function number of the desired device. |
| .sp |
| Example: |
| .B "flashrom \-p nic3com:pci=05:04.0" |
| .SS |
| .BR "ft2232_spi " programmer |
| An optional parameter specifies the controller |
| type and interface/port it should support. For that you have to use the |
| .sp |
| .B " flashrom \-p ft2232_spi:type=model,port=interface" |
| .sp |
| syntax where |
| .B model |
| can be |
| .BR 2232H ", " 4232H ", " jtagkey ", " busblaster ", " openmoko ", " \ |
| arm-usb-tiny ", " arm-usb-tiny-h ", " arm-usb-ocd ", " arm-usb-ocd-h \ |
| ", " tumpa ", or " picotap |
| and |
| .B interface |
| can be |
| .BR A ", or " B . |
| The default model is |
| .B 4232H |
| and the default interface is |
| .BR B . |
| .SS |
| .BR "serprog " programmer |
| A mandatory parameter specifies either a serial |
| device/baud combination or an IP/port combination for communication with the |
| programmer. In the device/baud combination, the device has to start with a |
| slash. For serial, you have to use the |
| .sp |
| .B " flashrom \-p serprog:dev=/dev/device:baud" |
| .sp |
| syntax and for IP, you have to use |
| .sp |
| .B " flashrom \-p serprog:ip=ipaddr:port" |
| .sp |
| instead. More information about serprog is available in |
| .B serprog-protocol.txt |
| in the source distribution. |
| .SS |
| .BR "buspirate_spi " programmer |
| A required |
| .B dev |
| parameter specifies the Bus Pirate device node and an optional |
| .B spispeed |
| parameter specifies the frequency of the SPI bus. The parameter |
| delimiter is a comma. Syntax is |
| .sp |
| .B " flashrom \-p buspirate_spi:dev=/dev/device,spispeed=frequency" |
| .sp |
| where |
| .B frequency |
| can be |
| .BR 30k ", " 125k ", " 250k ", " 1M ", " 2M ", " 2.6M ", " 4M " or " 8M |
| (in Hz). The default is the maximum frequency of 8 MHz. |
| .SS |
| .BR "dediprog " programmer |
| An optional |
| .B voltage |
| parameter specifies the voltage the Dediprog should use. The default unit is |
| Volt if no unit is specified. You can use |
| .BR mV ", " milliVolt ", " V " or " Volt |
| as unit specifier. Syntax is |
| .sp |
| .B " flashrom \-p dediprog:voltage=value" |
| .sp |
| where |
| .B value |
| can be |
| .BR 0V ", " 1.8V ", " 2.5V ", " 3.5V |
| or the equivalent in mV. |
| .SS |
| .BR "rayer_spi " programmer |
| The default I/O base address used for the parallel port is 0x378 and you can use |
| the optional |
| .B iobase |
| parameter to specify an alternate base I/O address with the |
| .sp |
| .B " flashrom \-p rayer_spi:iobase=baseaddr" |
| .sp |
| syntax where |
| .B baseaddr |
| is base I/O port address of the parallel port, which must be a multiple of |
| four. Make sure to not forget the "0x" prefix for hexadecimal port addresses. |
| .sp |
| The default cable type is the RayeR cable. You can use the optional |
| .B type |
| parameter to specify the cable type with the |
| .sp |
| .B " flashrom \-p rayer_spi:type=model" |
| .sp |
| syntax where |
| .B model |
| can be |
| .BR rayer " for the RayeR cable or " xilinx " for the Xilinx Parallel Cable III |
| (DLC 5). |
| .sp |
| More information about the RayeR hardware is available at |
| .BR "http://rayer.ic.cz/elektro/spipgm.htm " . |
| The schematic of the Xilinx DLC 5 was published at |
| .BR "http://www.xilinx.com/itp/xilinx4/data/docs/pac/appendixb.html " . |
| .SS |
| .BR "ogp_spi " programmer |
| The flash ROM chip to access must be specified with the |
| .B rom |
| parameter. |
| .sp |
| .B " flashrom \-p ogp_spi:rom=name" |
| .sp |
| Where |
| .B name |
| is either |
| .B cprom |
| or |
| .B s3 |
| for the configuration ROM and |
| .B bprom |
| or |
| .B bios |
| for the BIOS ROM. If more than one card supported by the ogp_spi programmer |
| is installed in your system, you have to specify the PCI address of the card |
| you want to use with the |
| .B pci= |
| parameter as explained in the |
| .B nic3com |
| section above. |
| .sp |
| More information about the hardware is available at |
| .BR http://wiki.opengraphics.org . |
| .SS |
| .BR "linux_spi " programmer |
| You have to specify the SPI controller to use with the |
| .sp |
| .B " flashrom \-p linux_spi:dev=/dev/spidevX.Y" |
| .sp |
| syntax where |
| .B /dev/spidevX.Y |
| is the Linux device node for your SPI controller. |
| .sp |
| Please note that the linux_spi driver only works on Linux. |
| .SH EXIT STATUS |
| flashrom exits with 0 on success, 1 on most failures but with 2 if /dev/mem |
| (/dev/xsvc on Solaris) can not be opened and with 3 if a call to mmap() fails. |
| .SH REQUIREMENTS |
| flashrom needs different access permissions for different programmers. |
| .sp |
| .B internal |
| needs raw memory access, PCI configuration space access, raw I/O port |
| access (x86) and MSR access (x86). |
| .sp |
| .BR nic3com ", " nicrealtek ", " nicsmc1211 " and " nicnatsemi " |
| need PCI configuration space read access and raw I/O port access. |
| .sp |
| .B atahpt |
| needs PCI configuration space access and raw I/O port access. |
| .sp |
| .BR gfxnvidia " and " drkaiser |
| need PCI configuration space access and raw memory access. |
| .sp |
| .B rayer_spi |
| needs raw I/O port access. |
| .sp |
| .B satasii |
| needs PCI configuration space read access and raw memory access. |
| .sp |
| .B satamv |
| needs PCI configuration space read access, raw I/O port access and raw memory |
| access. |
| .sp |
| .B serprog |
| needs TCP access to the network or userspace access to a serial port. |
| .sp |
| .B buspirate_spi |
| needs userspace access to a serial port. |
| .sp |
| .BR dediprog " and " ft2232_spi |
| need access to the USB device via libusb. |
| .sp |
| .B dummy |
| needs no access permissions at all. |
| .sp |
| .BR internal ", " nic3com ", " nicrealtek ", " nicsmc1211 ", " nicnatsemi ", " |
| .BR gfxnvidia ", " drkaiser ", " satasii ", " satamv " and " atahpt |
| have to be run as superuser/root, and need additional raw access permission. |
| .sp |
| .BR serprog ", " buspirate_spi ", " dediprog " and " ft2232_spi |
| can be run as normal user on most operating systems if appropriate device |
| permissions are set. |
| .sp |
| .B ogp |
| needs PCI configuration space read access and raw memory access. |
| .sp |
| On OpenBSD, you can obtain raw access permission by setting |
| .B "securelevel=-1" |
| in |
| .B "/etc/rc.securelevel" |
| and rebooting, or rebooting into single user mode. |
| .SH BUGS |
| Please report any bugs to the flashrom mailing list at |
| .B "<flashrom@flashrom.org>" |
| .sp |
| We recommend to subscribe first at |
| .sp |
| .B " http://www.flashrom.org/mailman/listinfo/flashrom" |
| .sp |
| Many of the developers communicate via the |
| .B "#flashrom" |
| IRC channel on |
| .BR chat.freenode.net . |
| You are welcome to join and ask questions, send us bug and success reports there |
| too. Please provide a way to contact you later (e.g. a mail address) and be |
| patient if there is no immediate reaction. Also, we provide a pastebin service |
| at |
| .B http://paste.flashrom.org |
| that is very useful when you want to share logs etc. without spamming the |
| channel. |
| .SS |
| .B Laptops |
| .sp |
| Using flashrom on laptops is dangerous and may easily make your hardware |
| unusable. flashrom will attempt to detect if it is running on a laptop and abort |
| immediately for safety reasons. Please see the detailed discussion of this topic |
| and associated flashrom options in the |
| .B Laptops |
| paragraph in the |
| .B internal programmer |
| subsection of the |
| .B PROGRAMMER SPECIFIC INFO |
| section. |
| .B " http://www.flashrom.org/Laptops" |
| .SS |
| One-time programmable (OTP) memory and unique IDs |
| .sp |
| Some flash chips contain OTP memory often denoted as "security registers". |
| They usually have a capacity in the range of some bytes to a few hundred |
| bytes and can be used to give devices unique IDs etc. flashrom is not able |
| to read or write these memories and may therefore not be able to duplicate a |
| chip completely. For chip types known to include OTP memories a warning is |
| printed when they are detected. |
| .sp |
| Similar to OTP memories are unique, factory programmed, unforgeable IDs. |
| They are not modifiable by the user at all. |
| .SH LICENSE |
| .B flashrom |
| is covered by the GNU General Public License (GPL), version 2. Some files are |
| additionally available under the GPL (version 2, or any later version). |
| .SH COPYRIGHT |
| .br |
| Please see the individual files. |
| .SH AUTHORS |
| Andrew Morgan |
| .br |
| Carl-Daniel Hailfinger |
| .br |
| Claus Gindhart |
| .br |
| David Borg |
| .br |
| David Hendricks |
| .br |
| Dominik Geyer |
| .br |
| Eric Biederman |
| .br |
| Giampiero Giancipoli |
| .br |
| Helge Wagner |
| .br |
| Idwer Vollering |
| .br |
| Joe Bao |
| .br |
| Joerg Fischer |
| .br |
| Joshua Roys |
| .br |
| Luc Verhaegen |
| .br |
| Li-Ta Lo |
| .br |
| Mark Marshall |
| .br |
| Markus Boas |
| .br |
| Mattias Mattsson |
| .br |
| Michael Karcher |
| .br |
| Nikolay Petukhov |
| .br |
| Patrick Georgi |
| .br |
| Peter Lemenkov |
| .br |
| Peter Stuge |
| .br |
| Reinder E.N. de Haan |
| .br |
| Ronald G. Minnich |
| .br |
| Ronald Hoogenboom |
| .br |
| Sean Nelson |
| .br |
| Stefan Reinauer |
| .br |
| Stefan Tauner |
| .br |
| Stefan Wildemann |
| .br |
| Stephan Guilloux |
| .br |
| Steven James |
| .br |
| Uwe Hermann |
| .br |
| Wang Qingpei |
| .br |
| Yinghai Lu |
| .br |
| some others, please see the flashrom svn changelog for details. |
| .br |
| All authors can be reached via email at <flashrom@flashrom.org>. |
| .PP |
| This manual page was written by Uwe Hermann <uwe@hermann-uwe.de>, |
| Carl-Daniel Hailfinger and others. |
| It is licensed under the terms of the GNU GPL (version 2 or later). |