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 <[email protected]> Acked-by: Uwe Hermann <[email protected]> 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. -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
