[v2] r4627 - trunk/coreboot-v2/documentation

Author: uwe
Date: 2009-09-04 21:25:51 +0200 (Fri, 04 Sep 2009)
New Revision: 4627

Modified:
   trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex
Log:
Fix various build issues and errors in LinuxBIOS-AMD64.tex.

Signed-off-by: Uwe Hermann 
Acked-by: Uwe Hermann

Modified: trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex
===================================================================
--- trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex	2009-09-04 16:30:31 UTC (rev 4626)
+++ trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex	2009-09-04 19:25:51 UTC (rev 4627)
@@ -1234,7 +1234,7 @@
 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\CONFIG_RESET} and add an object file specifying the
+option \texttt{CONFIG_HAVE_HARD_RESET} and add an object file specifying the
 reset code in your mainboard specific configuration file
 \texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/Config.lb}:

@@ -1552,7 +1552,7 @@
 ROMCC images are so-called because C code for the ROM part is compiled with romcc. romcc is an optimizing C compiler which compiles one, and only 
 one file; to get more than one file, one must include the C code via include statements. The main ROM code .c file is usually called auto.c. 
 \subsubsection{How it is built}
-Romcc compiles auto.c to produce auto.inc. auto.inc is included in the main crt0.S, which is then preprocessed to produce crt0.s. The inclusion of files into crt0.S is controlled by the CONFIG_CRT0_INCLUDES variable. crt0.s is then assembled. 
+Romcc compiles auto.c to produce auto.inc. auto.inc is included in the main crt0.S, which is then preprocessed to produce crt0.s. The inclusion of files into crt0.S is controlled by the CONFIG_CRT0_INCLUDES variable. crt0.s is then assembled.

File for the ram part are compiled in a conventional manner.

@@ -1574,17 +1574,17 @@
 As we mentioned, the ROM file consists of multiple images. In the basic file, there are two full coreboot rom images. The build sequence for each is the same, and in fact the ldscript.ld files are almost identical. The only difference is in a few makefile variables, generated by the config tool.

\begin{itemize}
-\item PAYLOAD_SIZE. Each image may have a different payload size. 
-\item \CONFIG_ROMBASE Each image must have a different base in rom. 
-\item \CONFIG_RESET Unclear what this is used for. 
-\item _EXCEPTION_VECTORS where an optional IDT might go.
-\item USE_OPTION_TABLE if set, an option table section will be linked in. 
+\item CONFIG_PAYLOAD_SIZE. Each image may have a different payload size. 
+\item CONFIG_ROMBASE Each image must have a different base in rom. 
+\item CONFIG_RESET Unclear what this is used for. 
+\item CONFIG_EXCEPTION_VECTORS where an optional IDT might go.
+\item CONFIG_USE_OPTION_TABLE if set, an option table section will be linked in. 
 \item CONFIG_ROM_PAYLOAD_START This is the soon-to-be-deprecated way of locating a payload. cbfs eliminates this. 
-\item USE_FALLBACK_IMAGE Whether this is a fallback or normal image
-\item ROM_SECTION_SIZE Essentially, the payload size. Soon to be deprecated. 
-\item ROM_IMAGE_SIZE Size of this image (i.e. fallback or normal image)
-\item ROM_SIZE Total size of the ROM
-\item XIP_RAM_BASE The start of eXecute In Place code. XIP allows for not copying code to ram, but just running it from ROM. 
+\item CONFIG_USE_FALLBACK_IMAGE Whether this is a fallback or normal image
+\item CONFIG_ROM_SECTION_SIZE Essentially, the payload size. Soon to be deprecated. 
+\item CONFIG_ROM_IMAGE_SIZE Size of this image (i.e. fallback or normal image)
+\item CONFIG_ROM_SIZE Total size of the ROM
+\item CONFIG_XIP_RAM_BASE The start of eXecute In Place code. XIP allows for not copying code to ram, but just running it from ROM. 
 \end{itemize}

Each image (normal or fallback) is built completely independently and does not get linked to the other. They are assembled into one ROM image by the (soon to be deprecated) buildrom tool, or by the cbfs tool.