diff --git a/Documentation/AMD-S3.txt b/Documentation/AMD-S3.txt index 48d4c8f3e7..bfabcbe29d 100644 --- a/Documentation/AMD-S3.txt +++ b/Documentation/AMD-S3.txt @@ -13,7 +13,7 @@ /_/ \_\_| |_|_____/ |_____/ |____/ - S3 in Coreboot (V 1.2) + S3 in coreboot (V 1.2) ---------------------------------------- Zheng Bao @@ -78,7 +78,7 @@ as reserved in e820, or BIOS saves the content into reserved space. Here is the address Map for S3 Resume. Assumingly the total memory is 1GB. 00000000 --- 00100000 BIOS Reserved area. 00100000 --- 00200000 Free -00200000 --- 01000000 Coreboot ramstage area. +00200000 --- 01000000 coreboot ramstage area. 01000000 --- 2e160000 Free 2e160000 --- 2e170000 ACPI table 2e170000 --- 2ef70000 OSRAM @@ -99,7 +99,7 @@ board.[2] Provided by Southbridge vendor code. Early is called before PCI enumeration, and Late is called after that. -Lifecycle of booting, sleeping and waking Coreboot and Ubuntu +Lifecycle of booting, sleeping and waking coreboot and Ubuntu ============================================================= 1. Cold boot. For a system with S3 feature, the BIOS needs to save some data to @@ -130,7 +130,7 @@ when system wakeups. As we mentioned, Firmware detects the SLP_TYPx to find out if the board wakes up. In romstage.c, AmdInitReset and AmdInitEarly are called as they are during cold boot. AmdInitResume and AmdS3LateRestore are -called only during resume. For whole ramstage, Coreboot goes through +called only during resume. For whole ramstage, coreboot goes through almost the same way as cold boot, other than not calling the AmdInitMid, AmdInitLate and AmdS3Save, and restoring all the MTRRs. At last step of coreboot stage, coreboot finds out the wakeup vector in FADT, @@ -141,13 +141,13 @@ When Linux resumes, all the sleeping scripts call their resume hooks. If we are more lucky, all the scripts can go through. More chances that the 99video hangs or fails to get the display back. Sometimes it can fixed if CONFIG_S3_VGA_ROM_RUN is unset in -Coreboot/Kconfig. That needs more troubleshooting. +coreboot/Kconfig. That needs more troubleshooting. Reference ========= [1] ACPI40a, http://www.acpi.info/spec40a.htm -[2] Coreboot Vendorcode, {top}/src/vendorcode/amd/agesa/{family}/Proc/Common/ -[3] Coreboot AGESA wrapper, {top}/src/mainboard/amd/parmer/agesawrapper.c -[4] Coreboot AGESA wrapper, {top}/src/cpu/amd/agesa/s3_resume.c -[5] Coreboot Southbridge, {top}/src/southbridge/amd/agesa/hudson/spi.c +[2] coreboot Vendorcode, {top}/src/vendorcode/amd/agesa/{family}/Proc/Common/ +[3] coreboot AGESA wrapper, {top}/src/mainboard/amd/parmer/agesawrapper.c +[4] coreboot AGESA wrapper, {top}/src/cpu/amd/agesa/s3_resume.c +[5] coreboot Southbridge, {top}/src/southbridge/amd/agesa/hudson/spi.c diff --git a/Documentation/Intel/SoC/soc.html b/Documentation/Intel/SoC/soc.html index 6f6d6308ab..147b0a1a8e 100644 --- a/Documentation/Intel/SoC/soc.html +++ b/Documentation/Intel/SoC/soc.html @@ -588,7 +588,7 @@ Use the following steps to debug the call to TempRamInit:

- +
Coreboot Fieldcoreboot Field EDK2 Field gUefiAcpiBoardInfoGuid Use diff --git a/Documentation/Makefile b/Documentation/Makefile index 96b66a998b..ecfbdb4c59 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -7,7 +7,7 @@ PDFLATEX=pdflatex -t a4 FIGS=codeflow.pdf hypertransport.pdf -all: CorebootPortingGuide.pdf Kconfig.pdf +all: corebootPortingGuide.pdf Kconfig.pdf SVG2PDF=$(shell which svg2pdf) INKSCAPE=$(shell which inkscape) @@ -31,13 +31,13 @@ else ifneq ($(strip $(CONVERT)),) convert $< $@ endif -CorebootPortingGuide.toc: $(FIGS) CorebootBuildingGuide.tex +corebootPortingGuide.toc: $(FIGS) corebootBuildingGuide.tex # 2 times to make sure we have a current toc. - $(PDFLATEX) CorebootBuildingGuide.tex - $(PDFLATEX) CorebootBuildingGuide.tex + $(PDFLATEX) corebootBuildingGuide.tex + $(PDFLATEX) corebootBuildingGuide.tex -CorebootPortingGuide.pdf: $(FIGS) CorebootBuildingGuide.tex CorebootPortingGuide.toc - $(PDFLATEX) CorebootBuildingGuide.tex +corebootPortingGuide.pdf: $(FIGS) corebootBuildingGuide.tex corebootPortingGuide.toc + $(PDFLATEX) corebootBuildingGuide.tex Kconfig.pdf: Kconfig.tex mainboardkconfig.tex cpukconfig.tex socketfkconfig.tex $(PDFLATEX) $< @@ -67,4 +67,4 @@ clean: rm -f *.aux *.idx *.log *.toc *.out $(FIGS) mainboardkconfig.tex skconfig.tex cpukconfig.tex socketfkconfig.tex distclean: clean - rm -f CorebootPortingGuide.pdf Kconfig.pdf + rm -f corebootPortingGuide.pdf Kconfig.pdf diff --git a/Documentation/acpi/gpio.md b/Documentation/acpi/gpio.md index 2fb2d1d5a0..344e2ee3f4 100644 --- a/Documentation/acpi/gpio.md +++ b/Documentation/acpi/gpio.md @@ -157,7 +157,7 @@ for the GPIO. These are reference implementations and the platforms are free to -implement these functions in any way they like. Coreboot driver can +implement these functions in any way they like. coreboot driver can then simply call into these functions to generate ACPI AML code to get/set/clear any GPIO. In order to decide whether GPIO operations are required, driver code can rely either on some config option or read diff --git a/Documentation/cbfs.txt b/Documentation/cbfs.txt index 7ecc9014a1..a190da1ff1 100644 --- a/Documentation/cbfs.txt +++ b/Documentation/cbfs.txt @@ -19,7 +19,7 @@ scheme. Over time, the scheme evolved slightly, but I think you'll find that it remains true to the original idea. Below is the beginnings of an architecture document - I did it in text form, but if met with aclaim, it should be wikified. This presents what I call CBFS - the -next generation LAR for next generation Coreboot. Its easier to +next generation LAR for next generation coreboot. Its easier to describe what it is by describing what changed: A header has been added somewhere in the bootblock similar to Carl @@ -73,7 +73,7 @@ bucks, will you? Jordan -Coreboot CBFS Specification +coreboot CBFS Specification Jordan Crouse = Introduction = @@ -163,7 +163,7 @@ number is 0x4F524243, which is 'ORBC' in ASCII. 'version' is a version number for CBFS header. cbfs_header structure may be different if version is not matched. -'romsize' is the size of the ROM in bytes. Coreboot will subtract 'size' from +'romsize' is the size of the ROM in bytes. coreboot will subtract 'size' from 0xFFFFFFFF to locate the beginning of the ROM in memory. 'bootblocksize' is the size of bootblock reserved in firmware image. diff --git a/Documentation/CorebootBuildingGuide.tex b/Documentation/corebootBuildingGuide.tex similarity index 98% rename from Documentation/CorebootBuildingGuide.tex rename to Documentation/corebootBuildingGuide.tex index f18cc18719..867891b431 100644 --- a/Documentation/CorebootBuildingGuide.tex +++ b/Documentation/corebootBuildingGuide.tex @@ -23,7 +23,7 @@ colorlinks=false, % pdfpagemode=None, % PDF-Viewer starts without TOC % pdfstartview=FitH, - pdftitle={Coreboot Porting Guide}, + pdftitle={coreboot Porting Guide}, pdfauthor={Zheng Bao}, pdfsubject={coreboot configuration and build process}, pdfkeywords={coreboot, AMD, configuration, Build} @@ -32,7 +32,7 @@ \setlength{\parindent}{0pt} \setlength{\hoffset}{0pt} -\title{Coreboot from Scratch} +\title{coreboot from Scratch} \author{Stefan Reinauer $<$stepan@coresystems.de$>$\and Zheng Bao $<$zheng.bao@amd.com$>$} \date{Dec 4th, 2013} @@ -46,7 +46,7 @@ \newpage -\section{What is Coreboot} +\section{What is coreboot} 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 @@ -60,7 +60,7 @@ people with varying backgrounds. Nowadays a large and growing number of Systems can be booted with coreboot, including embedded systems, Desktop PCs and Servers. -This document is used to build, modify, and port the CoreBoot code +This document is used to build, modify, and port the coreboot code base on the AMD platform. @@ -108,10 +108,10 @@ tools to build the source. \end{itemize} % -% Getting Coreboot +% Getting coreboot % -\section{Getting Coreboot} +\section{Getting coreboot} The latest coreboot sources are available via GIT. For users who doesn't need to change and commit the code: { \small @@ -140,8 +140,8 @@ $ git submodule update --init --checkout % \section{Building the toolchain} -Coreboot recommends and guarantees the toolchain integrated with Coreboot. -Linux distributions usually modify their compilers in ways incompatible with Coreboot. +coreboot recommends and guarantees the toolchain integrated with coreboot. +Linux distributions usually modify their compilers in ways incompatible with coreboot. { \small \begin{verbatim} @@ -236,11 +236,11 @@ Cleaning up... \textcolor {green}{ok} If you are lucky, you can get toolchains located in util/crossgcc/xgcc. % -% Build Coreboot +% Build coreboot % -\section{Building Coreboot} -\subsection{Build main module of Coreboot} +\section{Building coreboot} +\subsection{Build main module of coreboot} { \small \begin{verbatim} $ cd coreboot