Fix various build issues and errors in LinuxBIOS-AMD64.tex.

Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>



git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4627 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1

1 files changed, 12 insertions, 12 deletions

diff --git a/documentation/LinuxBIOS-AMD64.tex b/documentation/LinuxBIOS-AMD64.tex
index 94fd8d7..e8687ce 100644
--- a/documentation/LinuxBIOS-AMD64.tex
+++ b/documentation/LinuxBIOS-AMD64.tex
@@ -1234,7 +1234,7 @@ When changing speed and width of hypertransport chain connections
 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 @@ A coreboot rom file consists of one or more \textit{images}. All images consist
 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 @@ The only sections that get loaded into a ROM are the Allocated ones. We can see
 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.