Firmware/opensbi
8
0
Fork 0
forked from Mirrors/opensbi
Code Pull Requests Activity

docs: Typo fixes.

Browse Source 
Signed-off-by: Atish Patra <atish.patra@wdc.com>
This commit is contained in:
Atish Patra
2019-01-21 00:01:23 -08:00
committed by Anup Patel
parent d9c06d0a8d
commit f293d21863
4 changed files with 22 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/contributing.md
View File

@@ -1,13 +1,13 @@
OpenSBI Contributing Guidelines
===============================
All contributions to OpenSBI should be sent as GitHub Pull Requests (PRs) to the main repo avaliable at: https://github.com/riscv/opensbi
All contributions to OpenSBI should be sent as GitHub Pull Requests (PRs) to the main repository avaliable at: https://github.com/riscv/opensbi
As well as that all work must follow the following rules:
1. We follow the [Linux coding style](https://www.kernel.org/doc/html/v4.10/process/coding-style.html). This means that ALL patches must include the Signed-off-by line.
2. Commit subject must have atleast one ":" prefix. Common ones are "lib:", "platform:", "firmware:", "docs:" and "top:".
3. Maintainer should prefer "Rebase and Merge" when using GitHub to merge pull requests. Avoid create extra merge commits.
4. Maintainer should avoid creating branches directly in main riscv/opensbi repo. Instead prefer fork of GitHub riscv/opensbi repo and create branches in your own fork for pull requests.
2. Commit subject must have at least one ":" prefix. Common ones are "lib:", "platform:", "firmware:", "docs:" and "top:".
3. Maintainer should use "Rebase and Merge" when using GitHub to merge pull requests to avoid unnecessary merge commits.
4. Maintainer should avoid creating branches directly in main riscv/opensbi repository. Instead prefer fork of GitHub riscv/opensbi repository and create branches in your own fork for pull requests.
5. Maintainer cannot merge his own pull requests on GitHub.
6. A pull request must get atleast one review from relevant maintainer.
7. A pull request must spend atleast 24 hours in review so that everyone gets a chance to review.
6. A pull request must get at least one review from relevant maintainer.
7. A pull request must spend at least 24 hours in review so that everyone gets a chance to review.

14
docs/firmware/fw_jump.md
View File

@@ -23,15 +23,17 @@ Config Options
--------------
We need more config details for **FW_JUMP** firmware to work
correctly. These config details can be passed as paramter to
correctly. These configuration details can be passed as parameters to
top-level `make` or can be set in platform `config.mk`.
Following are the config options for **FW_JUMP** firmware:
Following are the configuration options for a **FW_JUMP** firmware:
* **FW_JUMP_ADDR** - Address where next booting stage is
located. This is a mandatory config option and will result
in compile error if not provided.
* **FW_JUMP_FDT_ADDR** - Address where FDT passed by prior
booting stage will be placed before passing to next booting
stage. If this option is not provided then firmware will pass
zero as FDT address to next booting stage.
* **FW_JUMP_FDT_ADDR** - Address where the FDT passed by the prior
booting stage will be placed before passing to the next booting
stage. If this option is not provided then the firmware will pass
zero as the FDT address to the next booting stage.
>>>>>>> 2c0dc4dc... docs: Typo fixes.

8
docs/firmware/fw_payload.md
View File

@@ -26,8 +26,8 @@ Configuration Options
---------------------
A *FW_PAYLOAD* firmware needs to be built according to some predefined
configuation options to work correctly. These configuration details can
be passed as paramters to the top-level `make` command or can be defined
configuration options to work correctly. These configuration details can
be passed as parameters to the top-level `make` command or can be defined
in a platform *config.mk* build configuration file.
The following are the build configuration parameters for a *FW_PAYLOAD*
@@ -39,10 +39,10 @@ binary will be linked in the final *FW_PAYLOAD* firmware binary image.
This configuration parameter is mandatory if *FW_PAYLOAD_ALIGN* is not
defined. Compilation errors will result from an incorrect definition
of *FW_PAYLOAD_OFFSET* or *FW_PAYLOAD_ALIGN*, or if neither of these
paramreters are defined.
parameters are defined.
* **FW_PAYLOAD_ALIGN** - Address alignment constraint where the payload
binary will be linked after the end of the base firmaware binary in the
binary will be linked after the end of the base firmware binary in the
final *FW_PAYLOAD* firmware binary image. This configuration parameter
is mandatory if *FW_PAYLOAD_OFFSET* is not defined and should not be
defined otherwise.