GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: Fix a bunch of typos 

Change-Id: I25dca2e231343cfdad61a638f0302726a6aa3f8b
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This commit is contained in:
Jonathan Neuschäfer 2018-04-09 13:05:29 +02:00 committed by Patrick Georgi
parent 7fa9f73ac7
commit 8ee93ae267
5 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/Intel/NativeRaminit/SandyBridge_registers.md
View File

@ -966,7 +966,7 @@ Please handle with care !
*Width:* 24 Bit
*Desc:* TC_DBP - Timming of DDR - Bin Parameter Register, Channel 0
*Desc:* TC_DBP - Timing of DDR - Bin Parameter Register, Channel 0
|Bit| Description |
|---|-------------|

6
Documentation/Lesson2.md
View File

@ -20,7 +20,7 @@ For the most up-to-date instructions on how to set up SSH keys with Gerrit go to
<https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.2/user-upload.html#configure_ssh)>
and follow the instructions there. Then, skip to Part 3.
Additonally, that section of the Web site provides explanation on starting
Additionally, that section of the Web site provides explanation on starting
an ssh-agent, which may be particularly helpful for those who anticipate
frequently uploading changes.
@ -110,7 +110,7 @@ To commit the change, run
git commit -s
**Note:** The -s adds a signed-off-by line by the commiter. Your commit should be
**Note:** The -s adds a signed-off-by line by the committer. Your commit should be
signed off with your name and email (i.e. **Your Name** **<Your Email>**, based on
what you set with git config earlier).
@ -236,7 +236,7 @@ Run the following two commands in the command line:
git clone https://github.com/magicmonty/bash-git-prompt.git .bash-git-prompt --depth=1
**Note:** cd will change your directory to your home directory, so the
git clone commmand will be run there.
git clone command will be run there.
Finally, open the ~/.bashrc file and append the following two lines:

4
Documentation/RFC/chip.tex
View File

@ -14,7 +14,7 @@ as southbridges. Multiple chips of same or different type are supported.
\section{Goals}
The goals of the new chip architecture are these:
\begin{itemize}
\item seperate implementation details from specification in the Config file
\item separate implementation details from specification in the Config file
(translation: no more C code in Config files)
\item make the specification easier for people to use and understand
\item remove private details of a given chip to the chip file as much
@ -223,7 +223,7 @@ struct configuration {
const char *value;
};
These get filled in by the config tool as before. The linuxbios libary can
These get filled in by the config tool as before. The linuxbios library can
then provide a generic parsing function for the superios to use.
The remaining question is how should the superio command look in

6
Documentation/cbfs.txt
View File

@ -36,7 +36,7 @@ CBFS by type (i.e - bayou can ask for all components that are payloads).
The header on each "file" (or component, as I like to style them) has
been simplified - We now only store the length, the type, the checksum,
and the offset to the data. The name scheme remains the same. The
addtional information, which is component specific, has been moved to
additional information, which is component specific, has been moved to
the component itself (see below).
The components are arranged in the ROM aligned along the specified
@ -245,7 +245,7 @@ structure of the header:
| ... |
\--------/ <- start + 'offset' + 'len'
== Searching Alogrithm ==
== Searching Algorithm ==
To locate a specific component in the ROM, one starts at the 'offset'
specified in the CBFS master header. For this example, the offset will
@ -379,7 +379,7 @@ struct cbfs_payload_segment {
PAYLOAD_SEGMENT_CODE 0x45444F43 The segment contains executable code
PAYLOAD_SEGMENT_DATA 0x41544144 The segment contains data
PAYLOAD_SEGMENT_BSS 0x20535342 The memory speicfied by the segment
PAYLOAD_SEGMENT_BSS 0x20535342 The memory specified by the segment
should be zeroed
PAYLOAD_SEGMENT_PARAMS 0x41524150 The segment contains information for
the payload

4
Documentation/corebootBuildingGuide.tex
View File

@ -413,8 +413,8 @@ $ git commit -m "my first change."
\end{verbatim}
}
% Does anyone have a better word to describe the phylosophy of spliting changes to patches?
You need to realize that the changes you have made should be well devided into
% Does anyone have a better word to describe the philosophy of splitting changes to patches?
You need to realize that the changes you have made should be well divided into
several commits. Each of them has one and only one meaning. You could use git rebase -i to
split, squash, remove, rewrite you comment.