diff options
Diffstat (limited to 'flashrom.8.tmpl')
| -rw-r--r-- | flashrom.8.tmpl | 1046 |
1 files changed, 1046 insertions, 0 deletions
diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl new file mode 100644 index 0000000..5ede423 --- /dev/null +++ b/flashrom.8.tmpl @@ -0,0 +1,1046 @@ +.TH FLASHROM 8 "" "" +.SH NAME +flashrom \- detect, read, write, verify and erase flash chips +.SH SYNOPSIS +.B flashrom \fR[\fB\-h\fR|\fB\-R\fR|\fB\-L\fR|\fB\-z\fR|\ +\fB\-p\fR <programmername>[:<parameters>] + [\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\-n\fR] [\fB\-f\fR]] + [\fB\-V\fR[\fBV\fR[\fBV\fR]]] [\fB-o\fR <logfile>] +.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/FT232H 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. All operations involving any chip access (probe/read/write/...) require the +.B -p/--programmer +option to be used (please see below). +.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 \-p prog \-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 contains multiple lines with the +following syntax: +.sp +.B " startaddr:endaddr imagename" +.sp +.BR "startaddr " "and " "endaddr " +are hexadecimal addresses within the ROM file and do not refer to any +physical address. Please note that using a 0x prefix for those hexadecimal +numbers is not necessary, but you can't specify decimal/octal numbers. +.BR "imagename " "is an arbitrary name for the region/image from" +.BR " startaddr " "to " "endaddr " "(both addresses included)." +.sp +Example: +.sp + 00000000:00008fff gfxrom + 00009000:0003ffff normal + 00040000:0007ffff fallback +.sp +If you only want to update the image named +.BR "normal " "in a ROM based on the layout above, run" +.sp +.B " flashrom \-p prog \-\-layout rom.layout \-\-image normal \-w some.rom" +.sp +To update only the images named +.BR "normal " "and " "fallback" ", run:" +.sp +.B " flashrom \-p prog \-l rom.layout \-i normal -i fallback \-w some.rom" +.sp +Overlapping sections are not supported. +.TP +.B "\-i, \-\-image <imagename>" +Only flash region/image +.B <imagename> +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 +.nh +.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. This is mandatory for all operations +involving any chip access (probe/read/write/...). 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 and SMC 1211 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/FT232H 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 "* pony_spi" " (for SPI flash ROMs attached to a SI-Prog serial port " +bitbanging adapter) +.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 +.BR "* usbblaster_spi" " (for SPI flash ROMs attached to an Altera USB-Blaster compatible cable)" +.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 "\-o, \-\-output <logfile>" +Save the full debug log to +.BR <logfile> . +If the file already exists, it will be overwritten. This is the recommended +way to gather logs from flashrom because they will be verbose even if the +on-screen messages are not verbose. +.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. +If reading succeeds and the contens of the read file look legit 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 is manufactured by GIGABYTE and supports DualBIOS it is very likely that it uses an +ITE IT87 series Super I/O to switch between the two flash chips. Only one of them can be accessed at a time +and you can manually select which one to use with the +.sp +.B " flashrom \-p internal:dualbiosindex=chip" +.sp +syntax where +.B chip +is the index of the chip to use (0 = main, 1 = backup). You can check which one is currently selected by +leaving out the +.B chip +parameter. +.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 AMD chipsets +.sp +Beginning with the SB700 chipset there is an integrated microcontroller (IMC) based on the 8051 embedded in +every AMD southbridge. Its firmware resides in the same flash chip as the host's which makes writing to the +flash risky if the IMC is active. Flashrom tries to temporarily disable the IMC but even then changing the +contents of the flash can have unwanted effects: when the IMC continues (at the latest after a reboot) it will +continue executing code from the flash. If the code was removed or changed in an unfortunate way it is +unpredictable what the IMC will do. Therefore, if flashrom detects an active IMC it will disable write support +unless the user forces it with the +.sp +.B " flashrom \-p internal:amd_imc_force=yes" +.sp +syntax. The user is responsible for supplying a suitable image or leaving out the IMC region with the help of +a layout file. This limitation might be removed in the future when we understand the details better and have +received enough feedback from users. Please report the outcome if you had to use this option to write a chip. +.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 +.BR "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 +.B 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. +.nh +.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 +.RB "* Macronix " MX25L6436 " SPI flash chip (RDID, SFDP)" +.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 +.B 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 +.B 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. +.sp +.TP +.B SPI status register +.sp +You can specify the initial content of the chip's status register with the +.sp +.B " flashrom -p dummy:spi_status=content" +.sp +syntax where +.B content +is an 8-bit hexadecimal value. +.SS +.BR "nic3com" , " nicrealtek" , " 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 channel/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 ", " 232H ", " 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 ", " B ", " C ", or " D . +The default model is +.B 4232H +and the default interface is +.BR A . +.sp +If there is more than one ft2232_spi-compatible device connected, you can select which one should be used by +specifying its serial number with the +.sp +.B " flashrom \-p ft2232_spi:serial=number" +.sp +syntax where +.B number +is the serial number of the device (which can be found for example in the output of lsusb -v). +.sp +All models supported by the ft2232_spi driver can configure the SPI clock rate by setting a divisor. The +expressible divisors are all +.B even +numbers between 2 and 2^17 (=131072) resulting in SPI clock frequencies of +6 MHz down to about 92 Hz for 12 MHz inputs. The default divisor is set to 2, but you can use another one by +specifying the optional +.B divisor +parameter with the +.sp +.B " flashrom \-p ft2232_spi:divisor=div" +.sp +syntax. +.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. In case the device supports it, you can set the SPI clock frequency +with the optional +.B spispeed +parameter. The frequency is parsed as hertz, unless an +.BR M ", or " k +suffix is given, then megahertz or kilohertz are used respectively. +Example that sets the frequency to 2 MHz: +.sp +.B " flashrom \-p serprog:dev=/dev/device:baud,spispeed=2M" +.sp +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. +.sp +An optional pullups parameter specifies the use of the Bus Pirate internal pull-up resistors. This may be +needed if you are working with a flash ROM chip that you have physically removed from the board. Syntax is +.sp +.B " flashrom -p buspirate_spi:pullups=state" +.sp +where +.B state +can be +.BR on " or " off . +More information about the Bus Pirate pull-up resistors and their purpose is available at +.nh +.BR "http://dangerousprototypes.com/docs/Practical_guide_to_Bus_Pirate_pull-up_resistors " . +Only the external supply voltage (Vpu) is supported as of this writing. +.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. +.sp +An optional +.B device +parameter specifies which of multiple connected Dediprog devices should be used. +Please be aware that the order depends on libusb's usb_get_busses() function and that the numbering starts +at 0. +Usage example to select the second device: +.sp +.B " flashrom \-p dediprog:device=1" +.sp +An optional +.B spispeed +parameter specifies the frequency of the SPI bus. The firmware on the device needs to be 5.0.0 or newer. +Syntax is +.sp +.B " flashrom \-p dediprog:spispeed=frequency" +.sp +where +.B frequency +can be +.BR 375k ", " 750k ", " 1.5M ", " 2.18M ", " 3M ", " 8M ", " 12M " or " 24M +(in Hz). The default is a frequency of 12 MHz. +.sp +An optional +.B target +parameter specifies which target chip should be used. Syntax is +.sp +.B " flashrom \-p dediprog:target=value" +.sp +where +.B value +can be +.BR 1 " or " 2 +to select target chip 1 or 2 repectively. The default is target chip 1. +.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 +.nh +.BR "http://rayer.ic.cz/elektro/spipgm.htm " . +The schematic of the Xilinx DLC 5 was published at +.nh +.BR "http://www.xilinx.com/itp/xilinx4/data/docs/pac/appendixb.html " . +.SS +.BR "pony_spi " programmer +The serial port (like /dev/ttyS0, /dev/ttyUSB0 on Linux or COM3 on windows) is +specified using the mandatory +.B dev +parameter. The adapter type is selectable between SI-Prog (used for +SPI devices with PonyProg 2000) or a custom made serial bitbanging programmer +named "serbang". The optional +.B type +parameter accepts the values "si_prog" (default) or "serbang". +.sp +Information about the SI-Prog adapter can be found at +.nh +.BR "http://www.lancos.com/siprogsch.html " . +.sp +An example call to flashrom is +.sp +.B " flashrom \-p pony_spi:dev=/dev/ttyS0,type=serbang" +.sp +Please note that while USB-to-serial adapters work under certain circumstances, +this slows down operation considerably. +.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 et al.\& +section above. +.sp +More information about the hardware is available at +.nh +.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 +In case the device supports it, you can set the SPI clock frequency with the optional +.B spispeed +parameter. The frequency is parsed as kilohertz. +Example that sets the frequency to 8 MHz: +.sp +.B " flashrom \-p linux_spi:dev=/dev/spidevX.Y,spispeed=8000" +.sp +Please note that the linux_spi driver only works on Linux. +.SH EXAMPLES +To back up and update your BIOS, run +.sp +.B flashrom -p internal -r backup.rom -o backuplog.txt +.br +.B flashrom -p internal -w newbios.rom -o writelog.txt +.sp +Please make sure to copy backup.rom to some external media before you try +to write. That makes offline recovery easier. +.br +If writing fails and flashrom complains about the chip being in an unknown +state, you can try to restore the backup by running +.sp +.B flashrom -p internal -w backup.rom -o restorelog.txt +.sp +If you encounter any problems, please contact us and supply +backuplog.txt, writelog.txt and restorelog.txt. See section +.B BUGS +for contact info. +.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 " 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 ", " ft2232_spi " and " usbblaster_spi +need access to the USB device via libusb. +.sp +.B dummy +needs no access permissions at all. +.sp +.BR internal ", " nic3com ", " nicrealtek ", " 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 ", " usbblaster_spi " 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 +.nh +.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 and the information in our wiki at +.BR "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). |
