New subject: [v2] r4155 - trunk/coreboot-v2/documentation

21 Apr 2009

On 21.04.2009 23:45, svn@coreboot.org wrote:
...
Author: stepan
Date: 2009-04-21 23:45:11 +0200 (Tue, 21 Apr 2009)
New Revision: 4155
Added:
   trunk/coreboot-v2/documentation/codeflow.svg
   trunk/coreboot-v2/documentation/hypertransport.svg
Removed:
   trunk/coreboot-v2/documentation/codeflow.eps
   trunk/coreboot-v2/documentation/hypertransport.eps
Modified:
   trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex
   trunk/coreboot-v2/documentation/Makefile
Log:
Update to this very old document
Signed-off-by: Stefan Reinauer stepan@coresystems.de
Acked-by: Stefan Reinauer stepan@coresystems.de
Thanks for updating this!
I reviewed the commit and have a few minor comments. Would you mind
addressing them?
Regards,
Carl-Daniel
...
Modified: trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex

--- trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex	2009-04-21 20:34:36 UTC (rev 4154)
+++ trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex	2009-04-21 21:45:11 UTC (rev 4155)
@@ -1,6 +1,6 @@
 %
 % This document is released under the GPL
-% Initially written by Stefan Reinauer, stepan@openbios.org
+% Initially written by Stefan Reinauer, stepan@coresystems.de
 %
\documentclass[titlepage,12pt]{article}
@@ -18,10 +18,10 @@
   colorlinks=false,
   % pdfpagemode=None,  % PDF-Viewer starts without TOC
   % pdfstartview=FitH,

pdftitle={LinuxBIOS on AMD64},


pdftitle={coreboot on AMD64},
pdfauthor={Stefan Reinauer},


pdfsubject={LinuxBIOS configuration and build process},
pdfkeywords={LinuxBIOS, Opteron, AMD64, Athlon64, Build}


pdfsubject={coreboot configuration and build process},
pdfkeywords={coreboot, Opteron, AMD64, configuration, Build}

}
@@ -30,9 +30,9 @@
\setlength{\parindent}{0pt}
-\title{LinuxBIOS on AMD64}
-\author{Stefan Reinauer $<$stepan@openbios.org$>$}
-\date{June 2nd, 2004}
+\title{coreboot on AMD64}
+\author{Stefan Reinauer $<$stepan@coresystems.de$>$}
+\date{April 19th, 2009}
\begin{document}
@@ -50,12 +50,12 @@
\section{Abstract}
-This document targets porting LinuxBIOS to new mainboards and creating
-custom firmware images using LinuxBIOS. It describes how to build
-LinuxBIOS images for the AMD64 platform, including hypertransport
+This document targets porting coreboot to new mainboards and creating
+custom firmware images using coreboot. It describes how to build
+coreboot images for the AMD64 platform, including hypertransport
 configuration and pertinent utilities. If you are missing information or
 find errors in the following descriptions, contact
-\href{mailto:stepan@openbios.org}{\textit{Stefan Reinauer $<$stepan@openbios.org$>$}}
+\href{mailto:stepan@coresystems.de}{\textit{Stefan Reinauer $<$stepan@coresystems.de$>$}}
%
@@ -64,6 +64,7 @@
\section{Changes}
  \begin{itemize}

\item 2009/04/19 replace LinuxBIOS with coreboot
\item 2004/06/02 url and language fixes from Ken Fuchs $<$kfuchs@winternet.com$>$
\item 2004/02/10 acpi and option rom updates
\item 2003/11/18 initial release

@@ -72,22 +73,22 @@
%
-% 3 What is LinuxBIOS
+% 3 What is coreboot
 %
-\section{What is LinuxBIOS?}
+\section{What is coreboot?}
-LinuxBIOS aims to replace the normal BIOS found on PCs, Alphas, and
-other machines with a Linux kernel that can boot Linux from a cold
-start. The startup code of an average LinuxBIOS port is about 500 lines
-of assembly and 5000 lines of C. It executes 16 instructions to get into
-32bit mode and then performs DRAM and other hardware initializations
+coreboot aims to replace the normal BIOS found on x86, AMD64, PPC, 
+Alpha, and other machines with a Linux kernel that can boot Linux from a cold
+start. The startup code of an average coreboot port is about 500 lines of
+assembly and 5000 lines of C. It executes 16 instructions to get into 32bit
+protected mode and then performs DRAM and other hardware initializations
 required before Linux can take over.
The projects primary motivation initially was maintenance of large
 clusters. Not surprisingly interest and contributions have come from
 people with varying backgrounds.  Nowadays a large and growing number of
-Systems can be booted with LinuxBIOS, including embedded systems,
+Systems can be booted with coreboot, including embedded systems,
 Desktop PCs and Servers.
%
@@ -95,7 +96,7 @@
 %
\section{Build Requirements}
-To build LinuxBIOS for AMD64 from the sources you need a recent Linux
+To build coreboot for AMD64 from the sources you need a recent Linux
 system for x86 or AMD64. SUSE Linux 8.2 or 9.0 are known to work fine.
 The following toolchain is recommended:
@@ -116,108 +117,100 @@
\section{Getting the Sources}
-The latest LinuxBIOS sources are available via CVS. The CVS repository
-is maintained at SourceForge.net (the project name is \emph{FreeBIOS}). 
-First you should create a directory for your LinuxBIOS trees:
+The latest coreboot sources are available via subversion. The subversion
+repository is maintained at SourceForge.net (the project name is
+\emph{FreeBIOS}).  First you should create a directory for your
+coreboot trees:
{ \small
 \begin{verbatim}
-$ mkdir linuxbios
-$ cd linuxbios
+$ mkdir coreboot
+$ cd coreboot
 \end{verbatim}
 }
-You can get the entire source tree via CVS:
+You can get the entire source tree via SVN:
{ \small 
 \begin{verbatim}
-$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios login
+$ svn co svn://coreboot.org/repos/trunk/coreboot-v2
 \end{verbatim}
 }
-Hit return when you are asked for a password. Then checkout (or update)
-the freebios source tree as follows:



-{ \small
-\begin{verbatim}
-$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios co freebios2
-\end{verbatim}
-}



Once the source tree is checked out, it can be updated with:
{ \small
 \begin{verbatim}
-% cvs update -Pd
+% svn update
 \end{verbatim}
 }
-Due to recent problems with SourceForge's CVS infrastructure we set up a
-snapshot site that keeps hourly source trees of the last four days. It
-is available at \url{http://snapshots.linuxbios.org/%7D.
-Due to major structural enhancements to \hbox{LinuxBIOS}, AMD64 support
-is only available in the \texttt{freebios2} tree. This tree reflects (as
-of November 2003) LinuxBIOS version 1.1.5 and will lead to LinuxBIOS 2.0
+For the case your corporate firewall blocks port 3690 (subversion) we set up a
+snapshot site that keeps the last few hundred source code revisions. It
+is available at \url{http://qa.coreboot.org/%7D.
+Due to major structural enhancements to \hbox{coreboot}, AMD64 support
+is only available in the \texttt{coreboot-v2} tree. This tree reflects (as
+of November 2003) coreboot version 1.1.5 and will lead to coreboot 2.0
 when finished.  Most x86 hardware is currently only supported by the 
-LinuxBIOS 1.0 tree.
+coreboot 1.0 tree.
%
-% 6 LinuxBIOS configuration overview
+% 6 coreboot configuration overview
 %
-\section{LinuxBIOS configuration overview}
-To support a large variety of existing hardware LinuxBIOS allows for a
+\section{coreboot configuration overview}
+To support a large variety of existing hardware coreboot allows for a
 lot of configuration options that can be tweaked in several ways:
\begin{itemize}
 \item 
 Firmware image specific configuration options can be set in the image
 configuration file which is usually found in
-\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$/}.  Such
+\texttt{coreboot-v2/targets/$<$vendor$>$/$<$mainboard$>$/}.  Such
 options are the default amount of output verbosity during bootup, image
 size, use of fallback mechanisms, firmware image size and payloads
 (Linux Kernel, Bootloader...) The default configuration file name is
-\texttt{Config.lb}, but LinuxBIOS allows multiple configurations to
+\texttt{Config.lb}, but coreboot allows multiple configurations to
 reside in that directory.
\item Mainboard specific configuration options can be set in the
 mainboard configuration file placed in
-\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$}. The
+\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$}. The
 mainboard configuration file is always called \texttt{Config.lb}. It
 contains information on the onboard components of the mainboard like
 CPU type, northbridge, southbridge, hypertransport configuration and
 SuperIO configuration.  This configuration file also allows to include
-addon code to hook into the LinuxBIOS initialization mechanism at
+addon code to hook into the coreboot initialization mechanism at
 basically any point.
\end{itemize}
This document describes different approaches of changing and configuring the
-LinuxBIOS source tree when building for AMD64.
+coreboot source tree when building for AMD64.
%
-% 7 Building LinuxBIOS
+% 7 Building coreboot
 %
-\section{Building LinuxBIOS}
-One of the design goals for building LinuxBIOS was to keep object files
+\section{Building coreboot}
+One of the design goals for building coreboot was to keep object files
 out of the source tree in a separate place. This is mandatory for
-building parallel LinuxBIOS images for several distinct mainboards
-and/or platforms. Therefore building LinuxBIOS consists of two steps:
+building parallel coreboot images for several distinct mainboards
+and/or platforms. Therefore building coreboot consists of two steps:
 \begin{itemize}
 \item
 creating a build tree which holds all files automatically created by the
 configuration utility and the object files
 \item
-compiling the LinuxBIOS code and creating a flashable firmware image.
+compiling the coreboot code and creating a flashable firmware image.
 \end{itemize}
The first of these two steps is accomplished by the \texttt{buildtarget}
-script found in \texttt{freebios2/targets/}. To build LinuxBIOS for
+script found in \texttt{coreboot-v2/targets/}. To build coreboot for
 instance for the AMD Solo Athlon64 mainboard enter:
\begin{verbatim}
-% cd freebios2/targets
+% cd coreboot-v2/targets
 % ./buildtarget amd/solo
 \end{verbatim}
@@ -225,23 +218,23 @@
 components needed for this build. The directory name is defined in the
 firmware image specific configuration file. In the case of AMD's Solo
 mainboard the default directory resides in 
-\texttt{freebios2/targets/amd/solo/solo}. To build the LinuxBIOS image, do
+\texttt{coreboot-v2/targets/amd/solo/solo}. To build the coreboot image, do
\begin{verbatim}
 % cd amd/solo/solo
 % make
 \end{verbatim}
-The LinuxBIOS image filename is specified in the firmware image specific
+The coreboot image filename is specified in the firmware image specific
 configuration file. The default filename for AMD's Solo mainboard is
 \texttt{solo.rom}.
%
-% 8 Programming LinuxBIOS to flash memory
+% 8 Programming coreboot to flash memory
 %
-\section{Programming LinuxBIOS to flash memory}
-The image resulting from a LinuxBIOS build can be directly programmed to
+\section{Programming coreboot to flash memory}
+The image resulting from a coreboot build can be directly programmed to
 a flash device, either using a hardware flash programmer or by using the
 Linux flash driver devbios or mtd. This document assumes that you use a
 hardware flash programmer. If you are interested in doing in-system
@@ -255,15 +248,15 @@
 \newpage
%
-% 9 LinuxBIOS configuration
+% 9 coreboot configuration
 %
-\section{LinuxBIOS configuration}
-The following chapters will cope with configuring LinuxBIOS. All
+\section{coreboot configuration}
+The following chapters will cope with configuring coreboot. All
 configuration files share some basic rules
 \begin{itemize}
 \item
-The default configuration file name in LinuxBIOS is \texttt{Config.lb}.
+The default configuration file name in coreboot is \texttt{Config.lb}.
 \item 
 All variables used in a configuration file have to be declared in this
 file with \texttt{uses VARNAME} before usage.
@@ -271,8 +264,8 @@
 Comments can be added on a new line by using the comment identifier
 \texttt{#} at the beginning of the line.
 \item
-LinuxBIOS distinguishes between statements and options. Statements cause
-the LinuxBIOS configuration mechanism to act, whereas options set
+coreboot distinguishes between statements and options. Statements cause
+the coreboot configuration mechanism to act, whereas options set
 variables that are used by the build scripts or source code.
 \item 
 Default configuration values can be set in the mainboard configuration
@@ -280,7 +273,7 @@
 \item 
 Option overrides to the default configuration can only be specified in
 the build target configuration file
-\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$/Config.lb} 
+\texttt{coreboot-v2/targets/$<$vendor$>$/$<$mainboard$>$/Config.lb} 
 (keyword option)
 \end{itemize}
@@ -297,8 +290,8 @@
 \end{verbatim}
\textbf{NOTE:} Only configuration variables known to the configuration
-system can be used in configuration files. LinuxBIOS checks 
-\texttt{freebios2/src/config/Options.lb} to see whether a configuration
+system can be used in configuration files. coreboot checks 
+\texttt{coreboot-v2/src/config/Options.lb} to see whether a configuration
 variable is known.
\item \begin{verbatim}default\end{verbatim}
@@ -338,7 +331,7 @@
 The \texttt{option} statement basically behaves identically to the
 \texttt{default} statement. But unlike default it can only be used in
 build target configuration files
-(\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$}). The option
+(\texttt{coreboot-v2/targets/$<$vendor$>$/$<$mainboard$>$}). The option
 statement allows either to set new options or to override default values
 set with the default statement in a mainboard configuration file.
 Syntax and application are the same as with default.
@@ -346,12 +339,12 @@
 \end{itemize}
\subsection{Firmware image specific configuration}
-LinuxBIOS allows to create different firmware images for the same
+coreboot allows to create different firmware images for the same
 hardware. Such images can differ in the amount of output they produce,
 the payload, the number of subimages they consist of etc.
The firmware image specific configuration file can be found in \
-\texttt{freebios2/targets/$<$vendor$>$/<mainboard$>$}.
+\texttt{coreboot-v2/targets/$<$vendor$>$/<mainboard$>$}.
\subsubsection{Firmware image specific keywords}
 In addition to the above described keywords the following statements are
@@ -361,13 +354,13 @@
 \item \begin{verbatim}romimage\end{verbatim}
The \texttt{romimage} definition describes a single rom build within the
-final LinuxBIOS image. Normally there are two romimage definitions per
-LinuxBIOS build: \texttt{normal} and \texttt{fallback}.
+final coreboot image. Normally there are two romimage definitions per
+coreboot build: \texttt{normal} and \texttt{fallback}.
Each \texttt{romimage} section needs to specify a mainboard directory and a
 payload. The mainboard directory contains the mainboard specific
 configuration file and source code. It is specified relatively to
-\texttt{freebios2/src/mainboard}. The payload definition is an absolute
+\texttt{coreboot-v2/src/mainboard}. The payload definition is an absolute
 path to a static elf binary (i.e Linux kernel or etherboot)
\begin{verbatim}
@@ -384,8 +377,8 @@
 \item \begin{verbatim}buildrom\end{verbatim}
The \texttt{buildrom} statement is used to determine which of the
-LinuxBIOS image builds (created using \texttt{romimage}) are packed
-together to the final LinuxBIOS image. It also specifies the order of
+coreboot image builds (created using \texttt{romimage}) are packed
+together to the final coreboot image. It also specifies the order of
 the images and the final image size:
\begin{verbatim}
@@ -407,7 +400,7 @@
 \item \begin{verbatim}CC\end{verbatim}
Target C Compiler. Default is \texttt{$(CROSS_COMPILE)gcc}. Set to
-\texttt{gcc -m32} for compiling AMD64 LinuxBIOS images on an AMD64 
+\texttt{gcc -m32} for compiling AMD64 coreboot images on an AMD64 
 machine.
\item \begin{verbatim}CONFIG_CHIP_CONFIGURE \end{verbatim}
@@ -444,7 +437,7 @@
Export CMOS option table. Default is \texttt{0}. Set to \texttt{1} if
 your mainboard has CMOS memory and you want to use it to store
-LinuxBIOS parameters (Loglevel, serial line speed, ...)
+coreboot parameters (Loglevel, serial line speed, ...)
\item \begin{verbatim}CONFIG_ROM_PAYLOAD\end{verbatim}
@@ -473,8 +466,8 @@
\item \begin{verbatim}COREBOOT_EXTRA_VERSION\end{verbatim}
-LinuxBIOS extra version. This option has an empty string as default. Set
-to any string to add an extra version string to your LinuxBIOS build.
+coreboot extra version. This option has an empty string as default. Set
+to any string to add an extra version string to your coreboot build.
\end{itemize}
@@ -521,7 +514,7 @@
 \item \begin{verbatim}driver\end{verbatim}
The \texttt{driver} keyword adds an object file to the driver section of a
-LinuxBIOS image.  This means it can be used by the PCI device
+coreboot�image.  This means it can be used by the PCI device
The character after coreboot looks strange. Intentional?
...
initialization code. Example:
\begin{verbatim}
@@ -530,7 +523,7 @@
\item \begin{verbatim}object\end{verbatim}
-The \texttt{object} keyword adds an object file to the LinuxBIOS image.
+The \texttt{object} keyword adds an object file to the coreboot image.
 Per default the object file will be compiled from a \texttt{.c} file
 with the same name. Symbols defined in such an object file can be used
 in other object files and drivers. Example:
@@ -543,7 +536,7 @@
This keyword can be used to extend the existing file creation rules
 during the build process. This is useful if external utilities have to
-be used for the build. LinuxBIOS on AMD64 uses romcc for it's early
+be used for the build. coreboot on AMD64 uses romcc for it's early
 startup code placed in auto.c.
To tell the configuration mechanism how to build \texttt{romcc} files, 
@@ -569,7 +562,7 @@
 \item \begin{verbatim}mainboardinit\end{verbatim}
With the mainboardinit keyword it's possible to include assembler code
-directly into the LinuxBIOS image. This is used for early infrastructure
+directly into the coreboot image. This is used for early infrastructure
 initialization, i.e. to switch to protected mode. Example:
\begin{verbatim}
@@ -578,12 +571,12 @@
\item \begin{verbatim}ldscript\end{verbatim}
-The GNU linker ld is used to link object files together to a LinuxBIOS
+The GNU linker ld is used to link object files together to a coreboot
 ROM image.
Since it is a lot more comfortable and flexible to use the GNU linker
 with linker scripts (ldscripts) than to create complex command line
-calls, LinuxBIOS features including linker scripts to control image
+calls, coreboot features including linker scripts to control image
 creation. Example:
\begin{verbatim}
@@ -593,12 +586,12 @@
\item \begin{verbatim}dir\end{verbatim}
-LinuxBIOS reuses as much code between the different ports as possible.
+coreboot reuses as much code between the different ports as possible.
 To achieve this, commonly used code can be stored in a separate
 directory. For a new mainboard, it is enough to know that the code in
 that directory can be used as is.
-LinuxBIOS will also read a \texttt{Config.lb} file stored in that
+coreboot will also read a \texttt{Config.lb} file stored in that
 directory. This happens with:
\begin{verbatim}
@@ -630,7 +623,7 @@
 The \texttt{northbridge} keyword describes a system northbridge. Some
 systems, like AMD64, can have more than one northbridge, i.e. one per
 CPU node. Each northbridge is described by the path to the northbridge
-code in LinuxBIOS (relative to \texttt{freebios2/src/northbridge}), i.e.
+code in coreboot (relative to \texttt{coreboot-v2/src/northbridge}), i.e.
 \texttt{amd/amdk8} and a unique name (i.e \texttt{mc0}) \
 Example:
@@ -642,7 +635,7 @@
\item \begin{verbatim}southbridge\end{verbatim}
-To simplify the handling of bus bridges in a LinuxBIOS system, all
+To simplify the handling of bus bridges in a coreboot system, all
 bridges available in a system that are not northbridges (i.e AGP, IO,
 PCIX) are seen as southbridges.
@@ -672,7 +665,7 @@
 that are provided by the bridge.  Generally all bridge sections have a
 couple of \texttt{pci} keywords.
-The first occurrence of the \texttt{pci} keyword tells LinuxBIOS where
+The first occurrence of the \texttt{pci} keyword tells coreboot where
 the bridge devices start, relative to the PCI configuration space used
 by the bridge. The following occurences of the \texttt{pci} keyword
 describe the provided devices. 
@@ -716,7 +709,7 @@
 \item \begin{verbatim}superio\end{verbatim}
SuperIO devices are basically handled like brigdes. They are taking
-their driver code from \texttt{freebios2/src/superio/}. They don't
+their driver code from \texttt{coreboot-v2/src/superio/}. They don't
 provide a PCI compatible configuration interface, but instead are ISA
 PnP devices. Normally they are connected to a southbridge. If this is
 the case, the \texttt{superio} section will be a subsection of the
@@ -796,23 +789,23 @@
\item \begin{verbatim}STACK_SIZE\end{verbatim}
-LinuxBIOS stack size. The size of the function call stack defaults to
+coreboot stack size. The size of the function call stack defaults to
 \texttt{0x2000} (8k).
\item \begin{verbatim}HEAP_SIZE\end{verbatim}
-LinuxBIOS heap size. The heap is used when LinuxBIOS allocates memory
+coreboot heap size. The heap is used when coreboot allocates memory
 with malloc(). The default heap size is \texttt{0x2000}, but AMD64 boards
 generally set it to \texttt{0x4000} (16k)
\item \begin{verbatim}XIP_ROM_BASE\end{verbatim}
-Start address of area to cache during LinuxBIOS execution directly from
+Start address of area to cache during coreboot execution directly from
 ROM.
\item \begin{verbatim}XIP_ROM_SIZE\end{verbatim}
-Size of area to cache during LinuxBIOS execution directly from ROM
+Size of area to cache during coreboot execution directly from ROM
\item \begin{verbatim}CONFIG_COMPRESS\end{verbatim}
@@ -831,19 +824,19 @@
\section{Tweaking the source code}
 Besides configuring the existing code it is sometimes necessary or
-desirable to tweak certain parts of LinuxBIOS by direct changes to the
+desirable to tweak certain parts of coreboot by direct changes to the
 code. This chapter covers some possible enhancements and changes that
-are needed when porting LinuxBIOS to a new mainboard or just come
+are needed when porting coreboot to a new mainboard or just come
 handy now and then.
\subsection{Hypertransport configuration}
-Before LinuxBIOS is able to activate all CPUs and detect bridges
+Before coreboot is able to activate all CPUs and detect bridges
 attached to these CPUs (and thus, see all devices attached to the
 system) it has to initialize the coherent hypertransport devices.
The current algorithms to do coherent hypertransport initialization are
 not fully, automatically evaluating the hypertransport chain graph.
-Therefore the code needs to be adapted when porting LinuxBIOS to a new
+Therefore the code needs to be adapted when porting coreboot to a new
 AMD64 mainboard. An example arrangement of hypertransport devices
 looks like this:
@@ -867,7 +860,7 @@
 \item Setting outgoing connections
 The algorithm needs to know which outgoing port of a CPU node is
 connected to the directly succeeding node. This is done in
-\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/auto.c}
+\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/auto.c}
 with a number of preprocessor defines (one define for two-node systems,
 three defines for four-node systems).
@@ -895,7 +888,7 @@
 ports. The routing information is written to the AMD K8 routing table.
 In an Nnode system this routing table consists of 3*N*N entries , one
 for each message type and for each possible CPU --> CPU communication. For
-simplicity LinuxBIOS keeps the 3 routing entries for each CPU --> CPU
+simplicity coreboot keeps the 3 routing entries for each CPU --> CPU
 communication in one machine word.  The routing table of each node looks
 like this:
@@ -996,7 +989,7 @@
\subsection{DRAM configuration}
 Setting up the RAM controller(s) is probably the most complex part of
-LinuxBIOS.  Basically LinuxBIOS serially initializes all RAM controllers
+coreboot.  Basically coreboot serially initializes all RAM controllers
 in the system, using SPDROM (serial presence detect) data to set
 timings, size and other properties.  The SPD data is usually read
 utilizing the I2C SMBUS interface of the southbridge.
@@ -1015,7 +1008,7 @@
Available mainboard implementations and CPUs create the need to add
 special setup code to RAM initialization in a number of places.
-LinuxBIOS provides hooks to easily add code in these places without
+coreboot provides hooks to easily add code in these places without
 having to change the generic code.  Whether these hooks have to be used
 depends on the mainboard design. In many cases the functions executed
 by the hooks just carry out trivial default settings or they are even
@@ -1024,7 +1017,7 @@
 Some mainboard/CPU combinations need to trigger an additional memory
 controller reset before the memory can be initialized properly. This is,
 for example, used to get memory working on preC stepping AMD64
-processors. LinuxBIOS provides two hooks for triggering onboard memory
+processors. coreboot provides two hooks for triggering onboard memory
 reset logic:
\begin{itemize}
@@ -1046,10 +1039,10 @@
The way SMBUS hub information is coded into the \texttt{mem_controller}
 structure is mainboard implementation specific and not
-described here.  See \texttt{freebios2/src/mainboard/amd/quartet/auto.c}
+described here.  See \texttt{coreboot-v2/src/mainboard/amd/quartet/auto.c}
 for an example.
-LinuxBIOS folks have agreed on SPD data being the central information
+coreboot folks have agreed on SPD data being the central information
 source for RAM specific information. But not all mainboards/RAM
 modules feature a physical SPD ROM. To still allow an easy to use SPD
 driven setup, there is a hook that abstracts reading the SPD ROM
@@ -1086,9 +1079,9 @@
 default IRQ_SLOT_COUNT=7
 \end{verbatim}
-This will make LinuxBIOS look for the file \
-\texttt{freebios2/src/mainboard/<vendor>/<mainboard>/irq_tables.c} which
-contains the source code definition of the IRQ table. LinuxBIOS corrects
+This will make coreboot look for the file \
+\texttt{coreboot-v2/src/mainboard/<vendor>/<mainboard>/irq_tables.c} which
+contains the source code definition of the IRQ table. coreboot corrects
 small inconsistencies in the IRQ table during startup (checksum and
 number of entries), but it is not yet writing IRQ tables in a completely 
 dynamic way.
@@ -1104,11 +1097,11 @@
\subsection {MP Tables}
-LinuxBIOS contains code to create MP tables conforming the
-Multiprocessor Specification V1.4. To include an MP Table in a LinuxBIOS
+coreboot contains code to create MP tables conforming the
+Multiprocessor Specification V1.4. To include an MP Table in a coreboot
 image, the following configuration variables have to be set (in the
 mainboard specific configuration file
-\texttt{freebios2/src/mainboard/<vendor><mainboard>/Config.lb}):
+\texttt{coreboot-v2/src/mainboard/<vendor><mainboard>/Config.lb}):
\begin{verbatim}
 default CONFIG_SMP=1
@@ -1116,8 +1109,8 @@
 default HAVE_MP_TABLE=1
 \end{verbatim}
-LinuxBIOS will then look for a function for setting up the MP table in
-the file \texttt{freebios2/src/mainboard<vendor>/<mainboard>/mptable.c}:
+coreboot will then look for a function for setting up the MP table in
+the file \texttt{coreboot-v2/src/mainboard<vendor>/<mainboard>/mptable.c}:
\begin{verbatim}
 void *smp_write_config_table(void *v, unsigned long * processor_map)
@@ -1130,7 +1123,7 @@
\subsection {ACPI Tables}
-There is initial ACPI support in LinuxBIOS now. Currently the only gain with
+There is initial ACPI support in coreboot now. Currently the only gain with
 this is the ability to use HPET timers in Linux. To achieve this, there is a
 framework that can generate the following tables: 
 \begin{itemize}
@@ -1140,7 +1133,7 @@
 \item HPET
 \end{itemize}
-To enable ACPI in your LinuxBIOS build, add the following lines to your
+To enable ACPI in your coreboot build, add the following lines to your
 configuration files:
 \begin{verbatim}
 uses HAVE_ACPI_TABLES
@@ -1155,16 +1148,16 @@
 features.
\subsection{POST}
-LinuxBIOS has three different methods of handling POST codes. They can
+coreboot has three different methods of handling POST codes. They can
 be triggered using configuration file options.
 \begin{itemize}
 \item
 \emph{Ignore POST completely}. No early code debugging is possible with
 this setting.  Set the configuration variable \texttt{NO_POST} to
-\texttt{1} to switch off all POST handling in LinuxBIOS.
+\texttt{1} to switch off all POST handling in coreboot.
 \item
 \emph{Normal IO port 80 POST}. This is the default behavior of
-LinuxBIOS. No configuration variables have to be set. To be able to see
+coreboot. No configuration variables have to be set. To be able to see
 port 80 POST output, you need a POST expansion card for ISA or PCI. Port
 80 POST allows simple debugging without any other output method
 available (serial interface or VGA display)
@@ -1178,7 +1171,7 @@
\subsection{HDT Debugging}
-If you are debugging your LinuxBIOS code with a Hardware Debug Tool
+If you are debugging your coreboot code with a Hardware Debug Tool
 (HDT), you can find the source code line for a given physical EIP
 address as follows: Look the address up in the file linuxbios.map. Then
 search the label Lxx in the file auto.inc created by romcc. The original
@@ -1186,7 +1179,7 @@
\subsection{Device Drivers}
-With only a few data structures LinuxBIOS features a simple but flexible
+With only a few data structures coreboot features a simple but flexible
 device driver interface. This interface is not intended for autonomously
 driving the devices but to initialize all system components so that they
 can be used by the booted operating system.
@@ -1220,9 +1213,9 @@
By separating the two structures above, M:N relations between compatible
 devices and drivers can be described. The driver source code containing
-above data structures and code have to be added to a LinuxBIOS image
+above data structures and code have to be added to a coreboot image
 using the driver keyword in the mainboard specific configuration file \
-\texttt{freebios2/src/mainboard/<vendor>/<mainboard>/Config.lb}:
+\texttt{coreboot-v2/src/mainboard/<vendor>/<mainboard>/Config.lb}:
\begin{verbatim}
         driver lsi_scsi.o
@@ -1230,20 +1223,20 @@
\subsection{Bus Bridges}
-Currently all bridges supported in the LinuxBIOS2 tree are transparent
+Currently all bridges supported in the coreboot-v2 tree are transparent
 bridges. This means, once the bridge is initialized, it's remote devices
-are visible on one of the PCI buses without special probing. LinuxBIOS
+are visible on one of the PCI buses without special probing. coreboot
 supports also bridges that are nontransparent.  The driver support code
 can provide a \texttt{scan_bus} function to scan devices behind the bridge.
\subsection{CPU Reset}
 When changing speed and width of hypertransport chain connections
-LinuxBIOS has to either assert an LDTSTOP or a reset to make the changes
-become active.  Additionally Linux can do a firmware reset, if LinuxBIOS
+coreboot has to either assert an LDTSTOP or a reset to make the changes
+become active.  Additionally Linux can do a firmware reset, if coreboot
 provides the needed infrastructure. To use this capability, define the
 option \texttt{HAVE_HARD_RESET} and add an object file specifying the
 reset code in your mainboard specific configuration file
-\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/Config.lb}:
+\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/Config.lb}:
\begin{verbatim}
         default HAVE_HARD_RESET=1
@@ -1258,41 +1251,41 @@
         void hard_reset(void);
 \end{verbatim}
-See \texttt{freebios2/src/mainboard/arima/hdama/reset.c} for an example
+See \texttt{coreboot-v2/src/mainboard/arima/hdama/reset.c} for an example
 implementation.
\newpage
%
-% 11. LinuxBIOS Internals
+% 11. coreboot Internals
 %
-\section{LinuxBIOS Internals}
+\section{coreboot Internals}
 This chapter covers some of the internal structures and algorithms of
-LinuxBIOS that have not been mentioned so far.
+coreboot that have not been mentioned so far.
\subsection{Code Flow}
\begin{figure}[htb]
 \centering
 \includegraphics[scale=0.7]{codeflow.pdf}
-\caption{LinuxBIOS rough Code Flow}
+\caption{coreboot rough Code Flow}
 \label{fix:codeflow}
 \end{figure}
\newpage
\subsection{Fallback mechanism}
-LinuxBIOS provides a mechanism to pack two different LinuxBIOS builds
-within one LinuxBIOS ROM image. Using the system CMOS memory LinuxBIOS
+coreboot provides a mechanism to pack two different coreboot builds
+within one coreboot ROM image. Using the system CMOS memory coreboot
 determines whether the last boot with a default image succeeded and
 boots a failsafe image on failure. This allows insystem testing without
 the risk to render the system unusable. See
-\texttt{freebios2/src/mainboard/arima/hdama/failover.c} for example
+\texttt{coreboot-v2/src/mainboard/arima/hdama/failover.c} for example
 code. The fallback mechanism can be used with the \texttt{cmos_util}.
\subsection{(Un) Supported Standards}
-LinuxBIOS supports the following standards
+coreboot supports the following standards
 \begin{itemize}
 \item Multiprocessing Specification (MPSPEC) 1.4
 \item IRQ Tables (PIRQ)
@@ -1305,18 +1298,18 @@
 \item APM
 \end{itemize}
-\subsection{LinuxBIOS table}
-LinuxBIOS stores information about the system in a data structure called
-the LinuxBIOS table. This table can be read under Linux using the tool
-lxbios from the Lawrence Livermore National Laboratory.
+\subsection{coreboot table}
+coreboot stores information about the system in a data structure called
+the coreboot table. This table can be read under Linux using the tool
+nvramtool from the Lawrence Livermore National Laboratory.
Get more information about lxbios and the utility itself at
 \url{http://www.llnl.gov/linux/lxbios/lxbios.html%7D
\subsection{ROMCC limitations}
-ROMCC, part of the LinuxBIOS project, is a C compiler that translates to
+ROMCC, part of the coreboot project, is a C compiler that translates to
 completely rommable code. This means the resulting code does not need
-any memory to work. This is one of the major improvements in LinuxBIOS
+any memory to work. This is one of the major improvements in coreboot
 V2, since it allows almost all code to be written in C. DRAM
 initialization can be factored and reused more easily among mainboards
 and platforms.
@@ -1331,12 +1324,12 @@
 your code.
\subsection{CMOS handling}
-LinuxBIOS can use the mainboard's CMOS memory to store information
+coreboot can use the mainboard's CMOS memory to store information
 defined in a data structure called the CMOS table . This information
 contains serial line speed, fallback boot control, output verbosity,
 default boot device, ECC control, and more. It can be easily enhanced by
 enhancing the CMOS table. This table, if present, is found at
-\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/cmos.layout}.
+\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/cmos.layout}.
 It describes the available options, their possible values and their
 position within the CMOS memory. The layout file looks as follows:
 \begin{verbatim}
@@ -1358,16 +1351,16 @@
 \end{verbatim}
To change CMOS values from a running Linux system, use the
-\texttt{cmos_util}, provided by Linux Networks as part of the LinuxBIOS
+\texttt{cmos_util}, provided by Linux Networks as part of the coreboot
 utilities suite. Get it at
 \textit{ftp://ftp.lnxi.com/pub/linuxbios/utilities/}
\subsection {Booting Payloads}
-LinuxBIOS can load a payload binary from a Flash device or IDE. This
+coreboot can load a payload binary from a Flash device or IDE. This
 payload can be a boot loader, like FILO or Etherboot, a kernel image, or
 any other static ELF binary.
-To create a Linux kernel image, that is bootable in LinuxBIOS, you have
+To create a Linux kernel image, that is bootable in coreboot, you have
 to use mkelfImage. The command line I used, looks like follows:
\begin{verbatim}
@@ -1436,9 +1429,9 @@
 operating system can not take advantage of the hardware, so there needs
 to be a way to address this issue. There are several alternatives:
-\subsection{Native LinuxBIOS Support}
+\subsection{Native coreboot Support}
-For some devices (ie Trident Cyberblade 3d) there is native LinuxBIOS
+For some devices (ie Trident Cyberblade 3d) there is native coreboot
 support This means there is a small driver bound to the PCI id of the
 device that is called after PCI device ressources are allotted.
@@ -1458,7 +1451,7 @@
\subsection{Using Native Linux Support}
-A simple way of getting a whole lot of drivers available for LinuxBIOS
+A simple way of getting a whole lot of drivers available for coreboot
 is to reuse Linux drivers by putting a Linux kernel to flash. This
 works, because no drivers are needed to get the Linux kernel (as opposed
 to store the kernel on a harddisk connected to isa/scsi/raid storage)
@@ -1510,7 +1503,7 @@
 an Open Firmware implementation.
There is a free Open Firmware implementation available, called OpenBIOS,
-that runs on top of LinuxBIOS. See www.openbios.org
+that runs on top of coreboot. See www.openbios.org
PROs:
  \begin{itemize}
@@ -1529,7 +1522,7 @@
 %
\section{Image types}
-There used to be one image type for LinuxBIOS, as described above. Since this paper was written (2004) there have been many changes. First, the name 
+There used to be one image type for coreboot, as described above. Since this paper was written (2004) there have been many changes. First, the name 
 was changed to coreboot, for many reasons. Second, Ying-Hai Liu, then of AMD, now of Sun, added Cache As Ram support (CAR) for many AMD CPUs, which both simplified and complicated things. Simplification came with the removal of romcc; complication came with the addition of new ways to build.
I thought his name is Yinghai Lu, not Ying-Hai Liu.
...
There are two big additions to the build process and, furthermore, more than two new CONFIG variables to control them. 
@@ -1702,7 +1695,7 @@
 \begin{itemize}
 \item payload
-LinuxBIOS only cares about low level machine initialization, but also has
+coreboot only cares about low level machine initialization, but also has
 very simple mechanisms to boot a file either from FLASHROM or IDE. That
 file, possibly a Linux Kernel, a boot loader or Etherboot, are called
 payload, since it is the first software executed that does not cope with
@@ -1721,14 +1714,11 @@
 %
\section{Bibliography}
-\subsection{Additional Papers on LinuxBIOS}
+\subsection{Additional Papers on coreboot}
\begin{itemize}

\item { \small
\textit{\url{http://www.linuxnetworx.com/products/linuxbios_white_paper.pdf%7D%7D

Do we have a copy of that doc anywhere?
...

}
\item
\textit{\url{http://www.linuxbios.org/papers/%7D%7D


\textit{\url{http://www.coreboot.org/Documentation%7D%7D
\item 
\textit{\url{http://www.lysator.liu.se/upplysning/fa/linuxbios.pdf%7D%7D
\item

@@ -1739,7 +1729,7 @@
\begin{itemize}
  \item Etherboot: \textit{\url{http://www.etherboot.org/%7D%7D

\item Filo: \textit{\url{http://te.to/~ts1/filo/%7D%7D


\item Filo: \textit{\url{http://www.coreboot.org/FILO%7D%7D
\item OpenBIOS: \textit{\url{http://www.openbios.org/%7D%7D

\end{itemize}
-- 
http://www.hailfinger.org/



    

Re: [coreboot] [v2] r4155 - trunk/coreboot-v2/documentation

Modified: trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex