On 21.04.2009 23:45, [email protected] 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 <[email protected]> > Acked-by: Stefan Reinauer <[email protected]> >
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, <[email protected]> > +% Initially written by Stefan Reinauer, <[email protected]> > % > > \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 $<[email protected]$>$} > -\date{June 2nd, 2004} > +\title{coreboot on AMD64} > +\author{Stefan Reinauer $<[email protected]$>$} > +\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:[email protected]}{\textit{stefan Reinauer > $<[email protected]$>$}} > +\href{mailto:[email protected]}{\textit{stefan Reinauer > $<[email protected]$>$}} > > > % > @@ -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 > $<[email protected]$>$ > \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:[email protected]:/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:[email protected]:/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/}. > -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/}. > +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} > > \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}} > Do we have a copy of that doc anywhere? > - } > \item > - \textit{\url{http://www.linuxbios.org/papers/}} > + \textit{\url{http://www.coreboot.org/Documentation}} > \item > \textit{\url{http://www.lysator.liu.se/upplysning/fa/linuxbios.pdf}} > \item > @@ -1739,7 +1729,7 @@ > > \begin{itemize} > \item Etherboot: \textit{\url{http://www.etherboot.org/}} > - \item Filo: \textit{\url{http://te.to/~ts1/filo/}} > + \item Filo: \textit{\url{http://www.coreboot.org/FILO}} > \item OpenBIOS: \textit{\url{http://www.openbios.org/}} > \end{itemize} > > > -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
