diff options
author | Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de> | 2010-03-07 22:29:28 +0000 |
---|---|---|
committer | Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de> | 2010-03-07 22:29:28 +0000 |
commit | a96c1f6d26dbed25d976f593bb19792116687f29 (patch) | |
tree | 392e8bff1f5e9887921d44a62a063ef0672be340 /flashrom.8 | |
parent | bf4b575efd19215fcd0e09fc3ce4fd8b7a656d59 (diff) | |
download | flashrom-a96c1f6d26dbed25d976f593bb19792116687f29.zip flashrom-a96c1f6d26dbed25d976f593bb19792116687f29.tar.gz |
Move untested board enable documentation to manpage
This also checks the testedness of boards in all cases, not just for
PCI/DMI detection.
Corresponding to flashrom svn r926.
Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Diffstat (limited to 'flashrom.8')
-rw-r--r-- | flashrom.8 | 41 |
1 files changed, 41 insertions, 0 deletions
@@ -175,6 +175,47 @@ 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. .TP +.BR "internal " programmer +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), it might be necessary to +specify the mainboard using the \-m switch (see above). +.sp +Some of these board-specific flash enabling functions (called 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 \-r) and store it to a medium outside of your computer, like +an 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 .BR "dummy " programmer An optional parameter specifies the bus types it should support. For that you have to use the |