254 lines
7.5 KiB
Groff
254 lines
7.5 KiB
Groff
.\"***************************************************************************\
|
|
.\" nvramtool.8
|
|
.\"***************************************************************************
|
|
.\" Copyright (C) 2002, 2003 The Regents of the University of California.
|
|
.\" Produced at the Lawrence Livermore National Laboratory.
|
|
.\" Written by David S. Peterson <dsp@llnl.gov> <dave_peterson@pobox.com>.
|
|
.\" UCRL-CODE-2003-012
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" This file is part of nvramtool, a utility for reading/writing coreboot
|
|
.\" parameters and displaying information from the coreboot table.
|
|
.\" For details, see http://coreboot.org/nvramtool.
|
|
.\"
|
|
.\" Please also read the file DISCLAIMER which is included in this software
|
|
.\" distribution.
|
|
.\"
|
|
.\" This program is free software; you can redistribute it and/or modify it
|
|
.\" under the terms of the GNU General Public License (as published by the
|
|
.\" Free Software Foundation) version 2, dated June 1991.
|
|
.\"
|
|
.\" This program is distributed in the hope that it will be useful, but
|
|
.\" WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY OF
|
|
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the terms and
|
|
.\" conditions of the GNU General Public License for more details.
|
|
.\"
|
|
.\" You should have received a copy of the GNU General Public License along
|
|
.\" with this program; if not, write to the Free Software Foundation, Inc.
|
|
.\"***************************************************************************/
|
|
.TH NVRAMTOOL 8 "September 2008"
|
|
.SH NAME
|
|
nvramtool \- read/write coreboot-related information
|
|
.SH SYNOPSIS
|
|
.B "nvramtool [OPTS] [-n] -r NAME"
|
|
.br
|
|
.B "nvramtool [OPTS] -e NAME"
|
|
.br
|
|
.B "nvramtool [OPTS] -a"
|
|
.br
|
|
.B "nvramtool [OPTS] -w NAME=VALUE"
|
|
.br
|
|
.B "nvramtool [OPTS] -p INPUT_FILE"
|
|
.br
|
|
.B "nvramtool [OPTS] -i"
|
|
.br
|
|
.B "nvramtool [OPTS] -c [VALUE]"
|
|
.br
|
|
.B "nvramtool [OPTS] -l [ARG]"
|
|
.br
|
|
.B "nvramtool [OPTS] -d"
|
|
.br
|
|
.B "nvramtool [OPTS] -Y"
|
|
.br
|
|
.B "nvramtool [OPTS] -b OUTPUT_FILE"
|
|
.br
|
|
.B "nvramtool [OPTS] -B INPUT_FILE"
|
|
.br
|
|
.B "nvramtool [OPTS] -x"
|
|
.br
|
|
.B "nvramtool [OPTS] -X DUMPFILE"
|
|
.br
|
|
.B "nvramtool [OPTS] -v"
|
|
.br
|
|
.B "nvramtool [OPTS] -h"
|
|
.SH DESCRIPTION
|
|
.B "nvramtool"
|
|
is a utility for reading/writing coreboot parameters and displaying
|
|
information from the coreboot table.
|
|
|
|
The coreboot table resides in low physical memory. It is created at boot
|
|
time by coreboot, and contains various system information such as the type
|
|
of mainboard in use. It specifies locations in the CMOS (nonvolatile RAM)
|
|
where the coreboot parameters are stored.
|
|
|
|
This program is intended for (x86-based) systems that use coreboot. For
|
|
information about coreboot, see
|
|
.br
|
|
http://www.coreboot.org/.
|
|
.SH PARAMETERS
|
|
.TP
|
|
.B "[-n] -r NAME"
|
|
Show the value of the coreboot parameter given by
|
|
.B "NAME."
|
|
If
|
|
.B "-n"
|
|
is specified, show only the value. Otherwise show both parameter name and
|
|
value.
|
|
.TP
|
|
.B "-e NAME"
|
|
Show all possible values for parameter given by
|
|
.B "NAME."
|
|
.TP
|
|
.B "-a"
|
|
Show the names and values for all coreboot parameters.
|
|
.TP
|
|
.B "-w NAME=VALUE"
|
|
Assign
|
|
.B "VALUE"
|
|
to coreboot parameter given by
|
|
.B "NAME."
|
|
.TP
|
|
.B "-p INPUT_FILE"
|
|
Assign values to coreboot parameters according to the contents of
|
|
.B "INPUT_FILE."
|
|
The format of this file is described below.
|
|
.TP
|
|
.B "-i"
|
|
This is similar to the
|
|
.B "-p"
|
|
option, except that the contents of the input file are taken from standard
|
|
input.
|
|
.TP
|
|
.B "-c [VALUE]"
|
|
If
|
|
.B "VALUE"
|
|
is present then set the CMOS checksum for the coreboot parameters to
|
|
.B "VALUE."
|
|
Otherwise, show the checksum value.
|
|
.TP
|
|
.B "-l [ARG]"
|
|
If
|
|
.B "ARG"
|
|
is present then show information from the coreboot table as specified by
|
|
.B "ARG."
|
|
Otherwise show all possible values for
|
|
.B "ARG."
|
|
.TP
|
|
.B "-d"
|
|
Do a low-level dump of the coreboot table.
|
|
.TP
|
|
.B "-Y"
|
|
Write CMOS layout information to standard output. If redirected to a file,
|
|
the layout information may be used as input for the
|
|
.B "'-y LAYOUT_FILE'"
|
|
option (see below).
|
|
.TP
|
|
.B "-b OUTPUT_FILE"
|
|
Write the contents of CMOS memory to the binary file
|
|
.B "OUTPUT_FILE."
|
|
The first 14 bytes of
|
|
.B "OUTPUT_FILE"
|
|
do not contain actual CMOS data, and are always written as zeros. This is
|
|
because the first 14 bytes of the CMOS area do not contain CMOS memory. These
|
|
bytes are involved with the functioning of the real time clock.
|
|
.TP
|
|
.B "-B INPUT_FILE"
|
|
Read binary data from
|
|
.B "INPUT_FILE"
|
|
and write the data to CMOS memory. The first 14 bytes of
|
|
.B "INPUT_FILE"
|
|
are skipped and data is written to CMOS starting at the 15th byte of the CMOS
|
|
area. This is because the first 14 bytes of the CMOS area do not contain CMOS
|
|
memory. These bytes are involved with the functioning of the real time clock.
|
|
.TP
|
|
.B "-x"
|
|
Show a hex dump of all CMOS data. The first 14 bytes of the dump do not
|
|
contain actual CMOS data, and are always shown as zeros. This is because the
|
|
first 14 bytes of the CMOS area do not contain CMOS memory. These bytes are
|
|
involved with the functioning of the real time clock.
|
|
.TP
|
|
.B "-X DUMPFILE"
|
|
Read binary data from
|
|
.B "DUMPFILE"
|
|
(presumably a CMOS dumpfile created using the
|
|
.B "-b OUTPUT_FILE"
|
|
option) and show a hex dump of the data.
|
|
.TP
|
|
.B "-v"
|
|
Show version information for this program.
|
|
.TP
|
|
.B "-h"
|
|
Show a help message for this program.
|
|
.SH "OPTIONS"
|
|
In all cases above,
|
|
.B "[OPTS]"
|
|
evaluates to the following:
|
|
|
|
.B " [-y LAYOUT_FILE | -t]"
|
|
|
|
The
|
|
.B "'-y LAYOUT_FILE'"
|
|
option tells nvramtool to obtain CMOS layout information from the contents of
|
|
.B "LAYOUT_FILE."
|
|
Likewise, the
|
|
.B "'-t'"
|
|
option tells nvramtool to obtain CMOS layout information from the CMOS option
|
|
table (contained within the coreboot table). If neither option is
|
|
specified, the CMOS option table is used by default.
|
|
.B "LAYOUT_FILE"
|
|
follows the format of the
|
|
.B "cmos.layout"
|
|
files provided by coreboot.
|
|
|
|
If the coreboot installed on your system was built without specifying
|
|
.B "CONFIG_HAVE_OPTION_TABLE,"
|
|
then the coreboot table will not contain a CMOS option table. In this case,
|
|
the
|
|
.B "'-y LAYOUT_FILE'"
|
|
option must be used.
|
|
|
|
These two options are silently ignored when used in combination with other
|
|
options (such as
|
|
.B "-h,"
|
|
for instance) for which they are not applicable.
|
|
.SH FILE FORMAT
|
|
For the
|
|
.B "-p"
|
|
option,
|
|
.B "INPUT_FILE"
|
|
must consist of a sequence of lines such that each line is either a blank
|
|
line, a comment, or an assignment. A blank line consists only of zero or
|
|
more whitespace characters (spaces and tabs). A comment is constructed as
|
|
follows:
|
|
|
|
.B " [ws]#[text]"
|
|
|
|
Here,
|
|
.B "[ws]"
|
|
indicates optional whitespace characters and
|
|
.B "[text]"
|
|
indicates optional text. Blank lines and comments are both ignored. An
|
|
assignment is constructed as follows:
|
|
|
|
.B " [ws]NAME[ws]=[ws]VALUE[ws]"
|
|
|
|
Here,
|
|
.B "NAME"
|
|
is the name of a coreboot parameter and
|
|
.B "VALUE"
|
|
is the value that will be assigned to
|
|
.B "NAME."
|
|
.B "VALUE"
|
|
is allowed to contain whitespace characters, but it must begin and end with
|
|
nonwhitespace characters. Note that each comment must appear on a line by
|
|
itself. If you attempt to add a comment to the end of an assignment, then the
|
|
comment will be interpreted as part of
|
|
.B "VALUE."
|
|
It is useful to observe that the output produced by both the
|
|
.B "-a"
|
|
and the
|
|
.B "'[-n] NAME'"
|
|
options (without
|
|
.B "-n"
|
|
specified) adheres to this file format.
|
|
.SH BUGS
|
|
This program does not implement any type of synchronization to ensure that
|
|
different processes don't stomp on each other when trying to access the
|
|
nonvolatile RAM simultaneously. Therefore, corruption of the BIOS parameter
|
|
values may occur if multiple instances of this program are executed
|
|
concurrently.
|
|
.SH AUTHORS
|
|
David S. Peterson <dsp@llnl.gov> <dave_peterson@pobox.com>
|
|
.br
|
|
Stefan Reinauer <stepan@coresystems.de>
|