Documentation: change coreboot to lowercase
The word 'coreboot' should always be written in lowercase, even at the start of a sentence. Unfortunately, some external websites and projects are spelling coreboot with an uppercase C, so references to those pages can't be changed without breaking the link. Change-Id: I79824da8a9ed36a1e4fe23a1711a89535267bf5f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/20031 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This commit is contained in:
Martin Roth
parent
1318ea600b
commit
4b18a922f0
|
|
@ -13,7 +13,7 @@
|
|||
/_/ \_\_| |_|_____/ |_____/ |____/
|
||||
|
||||
|
||||
S3 in Coreboot (V 1.2)
|
||||
S3 in coreboot (V 1.2)
|
||||
----------------------------------------
|
||||
Zheng Bao
|
||||
<zheng.bao@amd.com>
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -588,7 +588,7 @@ Use the following steps to debug the call to TempRamInit:
|
|||
</p>
|
||||
<table border="1">
|
||||
<tr bgcolor="#c0ffc0">
|
||||
<td>Coreboot Field</td>
|
||||
<td>coreboot Field</td>
|
||||
<td>EDK2 Field</td>
|
||||
<td>gUefiAcpiBoardInfoGuid</td>
|
||||
<td>Use</li>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 <jordan@cosmicpenguin.net>
|
||||
|
||||
= 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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
Loading…
Reference in New Issue