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:
parent
7fa9f73ac7
commit
8ee93ae267
|
@ -966,7 +966,7 @@ Please handle with care !
|
||||||
|
|
||||||
*Width:* 24 Bit
|
*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 |
|
|Bit| Description |
|
||||||
|---|-------------|
|
|---|-------------|
|
||||||
|
|
|
@ -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)>
|
<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.
|
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
|
an ssh-agent, which may be particularly helpful for those who anticipate
|
||||||
frequently uploading changes.
|
frequently uploading changes.
|
||||||
|
|
||||||
|
@ -110,7 +110,7 @@ To commit the change, run
|
||||||
|
|
||||||
git commit -s
|
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
|
signed off with your name and email (i.e. **Your Name** **<Your Email>**, based on
|
||||||
what you set with git config earlier).
|
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
|
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
|
**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:
|
Finally, open the ~/.bashrc file and append the following two lines:
|
||||||
|
|
||||||
|
|
|
@ -14,7 +14,7 @@ as southbridges. Multiple chips of same or different type are supported.
|
||||||
\section{Goals}
|
\section{Goals}
|
||||||
The goals of the new chip architecture are these:
|
The goals of the new chip architecture are these:
|
||||||
\begin{itemize}
|
\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)
|
(translation: no more C code in Config files)
|
||||||
\item make the specification easier for people to use and understand
|
\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
|
\item remove private details of a given chip to the chip file as much
|
||||||
|
@ -223,7 +223,7 @@ struct configuration {
|
||||||
const char *value;
|
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.
|
then provide a generic parsing function for the superios to use.
|
||||||
|
|
||||||
The remaining question is how should the superio command look in
|
The remaining question is how should the superio command look in
|
||||||
|
|
|
@ -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
|
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,
|
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
|
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 component itself (see below).
|
||||||
|
|
||||||
The components are arranged in the ROM aligned along the specified
|
The components are arranged in the ROM aligned along the specified
|
||||||
|
@ -245,7 +245,7 @@ structure of the header:
|
||||||
| ... |
|
| ... |
|
||||||
\--------/ <- start + 'offset' + 'len'
|
\--------/ <- start + 'offset' + 'len'
|
||||||
|
|
||||||
== Searching Alogrithm ==
|
== Searching Algorithm ==
|
||||||
|
|
||||||
To locate a specific component in the ROM, one starts at the 'offset'
|
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
|
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_CODE 0x45444F43 The segment contains executable code
|
||||||
PAYLOAD_SEGMENT_DATA 0x41544144 The segment contains data
|
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
|
should be zeroed
|
||||||
PAYLOAD_SEGMENT_PARAMS 0x41524150 The segment contains information for
|
PAYLOAD_SEGMENT_PARAMS 0x41524150 The segment contains information for
|
||||||
the payload
|
the payload
|
||||||
|
|
|
@ -413,8 +413,8 @@ $ git commit -m "my first change."
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
}
|
}
|
||||||
|
|
||||||
% Does anyone have a better word to describe the phylosophy of spliting changes to patches?
|
% 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 devided into
|
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
|
several commits. Each of them has one and only one meaning. You could use git rebase -i to
|
||||||
split, squash, remove, rewrite you comment.
|
split, squash, remove, rewrite you comment.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue