[meta-freescale] [Documentation][PATCH] UG: some grammar edits
Bob Cochran
yocto at mindchasers.com
Mon Nov 10 09:31:56 PST 2014
Signed-off-by: Bob Cochran <yocto at mindchasers.com>
---
user-guide/source/devtasks.rst | 62 ++++++++++++++++++++--------------------
user-guide/source/folders.rst | 12 ++++----
user-guide/source/index.rst | 4 +--
user-guide/source/machines.rst | 2 +-
user-guide/source/metadata.rst | 37 ++++++++++++------------
user-guide/source/nsteps.rst | 6 ++--
user-guide/source/weston.rst | 4 +--
7 files changed, 63 insertions(+), 64 deletions(-)
diff --git a/user-guide/source/devtasks.rst b/user-guide/source/devtasks.rst
index 1080d3e..b9f75d3 100644
--- a/user-guide/source/devtasks.rst
+++ b/user-guide/source/devtasks.rst
@@ -6,8 +6,8 @@ Common Development Tasks
Creating a new layer
---------------------
-It is suggested to create a layer when creating or modifying any metadata file (recipe,
-configuration file or class). The main reason **modularity**. In the other hand,
+Use a custom layer when creating or modifying any metadata file (recipe,
+configuration file, or class). The main reason is **modularity**. On the other hand,
make sure your new metadata has not already be implemented (layer, recipe or machine), so
before proceeding check the main `Layer Index`_.
@@ -18,12 +18,12 @@ before proceeding check the main `Layer Index`_.
fsl-community-bsp $ . setup-environment build
2. Move to the place you want to create your layer and choose a name
- (e.g. ``fsl-custom``)
+ (e.g. ``fsl-custom``)::
sources $ yocto-layer create fsl-custom
# Answer the questions. Make sure the priority is set correctly (higher numbers,
# higher priorities). Set the priority equal to the lowest already present, except
- # when you have introduce a new recipe with the same name as other and want to shadow
+ # when you create a new recipe with the same name as another recipe and want to shadow
# the original one.
3. Add any metadata content. Suggestion: Version the layer with GIT
@@ -35,8 +35,8 @@ before proceeding check the main `Layer Index`_.
build $ bitbake-layers show-layers
-6. You can then include any new image/machine define on your layer. In case
- you create a recipe and you want to include it on your next build, add it into your
+6. You can now include any new image/machine definitions in your layer. If you
+ created a new recipe and want to include it on your next build, add it to your
``build/conf/local.conf`` file through the ``CORE_IMAGE_EXTRA_INSTALL`` variable.
.. _patching-kernel:
@@ -44,28 +44,28 @@ before proceeding check the main `Layer Index`_.
Patching the Linux Kernel
-------------------------
-The Linux Kernel is just another recipe for Yocto, so learning to patch it, you learn
-to patch any other package. In the other hand, Yocto **should not** be used for
-package development, but in those rare cases follow the below steps. It is assumed
-that you have already build the package you want to patch.
+The Linux Kernel is just another Yocto recipe, so by learning to patch it, you learn
+to patch any other package. On the other hand, Yocto **should not** be used for
+package development. However, if the need does arise, follow the steps listed below. It is assumed
+that you have already built the package you want to patch.
* Create the patch or patches. In this example we are patching the
Linux kernel for `wandboard-dual machine <http://www.wandboard.org/>`_;
- in other words, the value of ``MACHINE`` on ``build/conf/local.conf`` is
+ in other words, the value of ``MACHINE`` in ``build/conf/local.conf`` is
``MACHINE ??= 'wandboard-dual'``
-* In case you already have the patches, make sure these can be nicely applied with
- the commands ``git apply --check <PATCH_NAME>``, and jump this step::
+* If you already have the patches available, make sure they can be applied cleanly with
+ the commands ``git apply --check <PATCH_NAME>``. To create new or additional patches::
build $ cd tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git
- build $ # Edit any files you want to change
- build $ git add <modified file 1> <modified file 2> ..
- build $ git commit -s -m '<your commit's title>' # Create the commit
- build $ git format-patch -1 # Create the patch
+ # Edit any files you want to change
+ $ git add <modified file 1> <modified file 2> ..
+ $ git commit -s -m '<your commit's title>' # Create the commit
+ $ git format-patch -1 # Create the patch
* Create a new layer (see :ref:`new-layer`)
-* On the new layer (e.g ``meta-fsl-custom``) , create the corresponding sub-directories
+* In the new layer (e.g ``meta-fsl-custom``), create the corresponding sub-directories
and the ```.bbfile``::
sources $ mkdir -p \
@@ -103,7 +103,7 @@ that you have already build the package you want to patch.
Building the Kernel Manually
----------------------------
-* Prepare the Yocto/Bitbake environment::
+* Prepare the Yocto/BitBake environment::
fsl-community-bsp $ . setup-environment build
@@ -122,7 +122,7 @@ Building the Kernel Manually
build $ source /opt/poky/<version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi
-* Get the Linux Kernel's source code::
+* Get the Linux Kernel source code::
$ git clone git://git.freescale.com/imx/linux-2.6-imx.git linux-imx
$ cd linux-imx
@@ -139,7 +139,7 @@ Building the Kernel Manually
linux-imx $ export CROSS_COMPILE=arm-poky-linux-gnueabi-
linux-imx $ unset LDFLAGS
-* Choose configuration and compile::
+* Choose a configuration and compile::
linux-imx $ make imx6_defconfig
linux-imx $ make uImage
@@ -148,7 +148,7 @@ Building the Kernel Manually
linux-imx $ sudo cp arch/arm/boot/uImage /media/Boot
-* If case you want your changes to be reflected on your Yocto Framework,
+* If you want your changes to be reflected in your Yocto Framework,
create the patches following the subsection :ref:`patching-kernel`
.. _contributing:
@@ -157,9 +157,9 @@ Contributing
------------
The Yocto Project is open-source, so anyone can contribute. No matter
-what your contribution is (bug fixing or new metadata), contributions are sent
-through patches to a community list. Many eyes will look into your patch and
-at some point it is either rejected or accepted.
+what your contributions are (bug fixes or new metadata), they should be sent
+as patches to the community list. Many eyes will look at your patch, and
+at some point it will either be accepted or rejected.
Follow these steps to contribute:
@@ -168,7 +168,7 @@ Follow these steps to contribute:
$ git config --global user.name "Your Name Here"
$ git config --global user.email "your_email at example.com"
-* Subscribed to the `meta-freescale Mailing List`_
+* Subscribe to the `meta-freescale Mailing List`_
* Always base your work on **master** branches::
@@ -193,17 +193,17 @@ Where ``<branch name>`` is any name you want to give to your local branch (e.g.
sources/meta-fsl-arm $ git add <file 1> <file 2>
sources/meta-fsl-arm $ git commit
-On the commit's log, the title must start with the filename change or introduced,
-then a brief description of the patch's goal, following with a long description.
+In the commit's log, the title must start with the filename that was changed or created,
+followed by a brief description of the patch's goal. On subsequent lines, provide a thorough description of the changes.
Make sure you follow the standards (type ` git log --pretty=oneline` to see previous commits)
* Create a patch::
sources/meta-fsl-arm $ git format-patch -s --subject-prefix='<meta-fsl-arm][PATCH' -1
-Where the last parameter (``-1``) indicate to patch last commit.
+Where the last parameter (``-1``) indicate to patch the last commit.
In case you want to create patches for older commits, just indicate the correct index.
-If your patch is done in other folder, just make sure you change the `--subject-prefix` value.
+If your patch is done in another folder, just make sure you change the `--subject-prefix` value.
* Send your patch or patches with::
@@ -212,7 +212,7 @@ If your patch is done in other folder, just make sure you change the `--subject-
where ``<patch>`` is the file created by ``git format-patch``.
* Keep track of patch responses on the mailing list. In case you need to rework your patch,
- repeat the steps but this time the patch's subject changes to
+ repeat the steps but this time change the patch's subject to
``--subject-prefix='<meta-fsl-*][PATCH v2'``
* Once your patch has been approved, you can delete your working branches::
diff --git a/user-guide/source/folders.rst b/user-guide/source/folders.rst
index 69c48fd..29afaf1 100644
--- a/user-guide/source/folders.rst
+++ b/user-guide/source/folders.rst
@@ -1,16 +1,16 @@
Folders
=======
-* **fsl-community-bsp**: Base (``BASE``) directory where all Yocto data resides (recipes, source code, built packages, images, etc)
+* **fsl-community-bsp**: Base (``BASE``) directory where all Yocto data reside (recipes, source code, built packages, images, etc.)
-* **BASE/sources**: Source (``SOURCE``) directory where metadata (layers) resides
+* **BASE/sources**: Source directory where metadata (layers) reside
-* **BASE/build**: Build (``BUILD``) directory where ``bitbake`` commands are executed
+* **BASE/build**: Build directory where ``bitbake`` commands are executed
-* **BASE/build/tmp**: Target (``TMP``) directory for all bitbake commands
+* **BASE/build/tmp**: Target directory for all bitbake commands
-* **BASE/build/tmp/work**: Working (``WORKING``) directory for recipes tasks
+* **BASE/build/tmp/work**: Working directory that holds the task output and source from each recipe
-* **BASE/build/tmp/deploy**: Deploy (``DEPLOY``) directory where bitbake's output data is found
+* **BASE/build/tmp/deploy**: Deploy directory where bitbake's deployable output files are copied
* **BASE/build/tmp/deploy/images**: Complete and partial images are found under this folder
diff --git a/user-guide/source/index.rst b/user-guide/source/index.rst
index 414cd10..04f44f9 100644
--- a/user-guide/source/index.rst
+++ b/user-guide/source/index.rst
@@ -3,8 +3,8 @@
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
-Welcome to Freescale Community BSP User Guide's documentation!
-==============================================================
+Welcome to the Freescale Community's BSP User Guide!
+====================================================
Contents:
diff --git a/user-guide/source/machines.rst b/user-guide/source/machines.rst
index 7a0b437..55311d2 100644
--- a/user-guide/source/machines.rst
+++ b/user-guide/source/machines.rst
@@ -4,7 +4,7 @@ Machines
========
The scope of this release includes both meta-fsl-arm and meta-fsl-arm-extra.
-Please, see in next table the complete supported board list.
+Please refer to the table below for the complete list of supported boards.
.. include:: machine-list.inc
diff --git a/user-guide/source/metadata.rst b/user-guide/source/metadata.rst
index 9fa07fa..f31590e 100644
--- a/user-guide/source/metadata.rst
+++ b/user-guide/source/metadata.rst
@@ -1,11 +1,10 @@
Metadata
========
-BitBake handles the parsing and execution of the data files. The data itself is of
-various types:
+BitBake handles the parsing and execution of the data files, which consist of various types:
-* **Recipes**: Provides details about particular pieces of software.
-* **Class Data**: Abstracts common build information (e.g. how to build a Linux kernel).
+* **Recipes**: Provides details and build information about particular pieces of software
+* **Classes**: Abstracts common build subroutines and information (e.g. how to build a Linux kernel)
* **Configuration Data**: Defines machine-specific settings, policy decisions, and so forth.
Configuration data acts as the glue to bind everything together.
@@ -15,14 +14,14 @@ Layers
* Metadata is organized into multiple ``layers``.
* Layers allow you to isolate different types of customizations from each other.
* DO NOT do your modifications in existing layers, instead create a layer and
- create recipes (``.bb`` files) or modified existing ones (``.bbappend`` files)
+ create recipes (``.bb`` files) or modify existing ones (``.bbappend`` files)
Configuration Data
------------------
-* ``build/conf/local.conf``: Local User Configuration for your build environment
-* ``build/conf/bblayers.conf``: Define layers, which are directory trees,
+* ``build/conf/local.conf``: Local user configuration for your build environment
+* ``build/conf/bblayers.conf``: Defines layers, which are directory trees,
traversed by BitBake.
* ``sources/meta-*/conf/layer.conf``: Layer configuration file
* ``sources/meta-*/conf/machine/*.conf``: Machine configuration files
@@ -60,8 +59,8 @@ By default, the ``setup-enviroment`` script creates a ``local.conf`` like this::
Important variables:
-* ``MACHINE``: Indicates the machine, ``imx6qsabresd`` is the default
-* ``BB_NUMBER_THREADS`` and ``PARALLEL_MAKE``: Indicate the max number of threads when
+* ``MACHINE``: Specifies the machine, ``imx6qsabresd`` is the default
+* ``BB_NUMBER_THREADS`` and ``PARALLEL_MAKE``: Specifies the max number of threads when
baking and compiling
* ``DL_DIR``: Tarball repository. Several users can share the same folder, so data can
be reused.
@@ -71,7 +70,7 @@ Build's layer configuration file ``build/conf/bblayers.conf``
* Also created by the ``setup-environment`` script
-* In case you need to add a layer, append it to ``BBLAYERS``::
+* In case you need to add a layer, add it to ``BBLAYERS``::
LCONF_VERSION = "6"
@@ -93,7 +92,7 @@ Build's layer configuration file ``build/conf/bblayers.conf``
Layer configuration file ``meta-fsl-arm/conf/layer.conf``
---------------------------------------------------------
-This is basically a template, what it changes is the layer's name::
+This is basically a template that specifies the layer's name and structure::
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
@@ -116,9 +115,9 @@ This is basically a template, what it changes is the layer's name::
Important variables:
-* ``BBFILES``: Indicates where to look for ``.bb*`` files
-* ``BBFILE_PRIORITY_fsl-arm``: Indicates layer's priority
-* ``MIRRORS``: Indicates where to get the source code
+* ``BBFILES``: Specifies where BitBake looks for ``.bb*`` files
+* ``BBFILE_PRIORITY_fsl-arm``: Specifies priority for recipes in the meta-fsl-arm layer
+* ``MIRRORS``: Specifies additional paths where the build system can find source code
Machine configuration file: ``meta-fsl-arm/conf/imx6qsabresd.conf``
@@ -145,10 +144,10 @@ Machine configurations look like this::
Important variables:
-* ``IMAGE_FSTYPES``: Located on `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
- Defines the type of outputs for the Root Filesystem. Default is: ``"tar.bz2 ext3 sdcard"``
-* ``UBOOT_ENTRYPOINT_*``: Located on `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
+* ``IMAGE_FSTYPES``: Located in `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
+ Defines the type of outputs for the root filesystem. Default is: ``"tar.bz2 ext3 sdcard"``
+* ``UBOOT_ENTRYPOINT_*``: Located in `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
Defines where the Kernel is loaded by U-boot
-* ``SOC_FAMILY``: Defines machine's family. Only recipes with the same ``SOC_FAMILY`` (defined with the recipe's variable ``COMPATIBLE_MACHINE``)
+* ``SOC_FAMILY``: Defines the machine's family. Only recipes with the same ``SOC_FAMILY`` (defined with the recipe's variable ``COMPATIBLE_MACHINE``)
are taken into account when baking for a particular machine.
-* ``UBOOT_MACHINE``: Define the u-boot configuration file
+* ``UBOOT_MACHINE``: Defines the u-boot configuration file
diff --git a/user-guide/source/nsteps.rst b/user-guide/source/nsteps.rst
index c1dbabe..5a7c302 100644
--- a/user-guide/source/nsteps.rst
+++ b/user-guide/source/nsteps.rst
@@ -1,7 +1,7 @@
Build and boot in *N*-steps
===========================
-1. Check `required host packages`_ packages for your Linux Distribution
+1. Check `required host packages`_ for your Linux Distribution
2. Download the `repo`_ tool::
@@ -16,7 +16,7 @@ Build and boot in *N*-steps
$ cd fsl-community-bsp
fsl-community-bsp $ repo init \
-u https://github.com/Freescale/fsl-community-bsp-platform \
- -b dora
+ -b dizzy
fsl-community-bsp $ repo sync
4. Select your machine (:ref:`machines`) and prepare the environment for bitbake::
@@ -45,7 +45,7 @@ Build and boot in *N*-steps
7. Place your SD Card in the correct board's slot and boot!
-Found Errors? Subscribe and report it to `meta-freescale list`_
+Found errors? Subscribe and report it to `meta-freescale list`_
.. links
.. _required host packages: https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html#packages
diff --git a/user-guide/source/weston.rst b/user-guide/source/weston.rst
index 325bda7..562c4f7 100644
--- a/user-guide/source/weston.rst
+++ b/user-guide/source/weston.rst
@@ -1,7 +1,7 @@
Weston
======
-In order to test Weston the reference implementation of a Wayland compositor use the image *core-image-weston*
+In order to test Weston, the reference implementation of a Wayland compositor, use the image *core-image-weston*
Add the following to conf/local.conf::
@@ -17,7 +17,7 @@ Remember to use a clean build-dir when changing `DISTRO_FEATURES`
Simple tests
------------
-In order to access Weston examples via console::
+In order to access Weston examples via a console::
$ export XDG_RUNTIME_DIR=/var/run/user/root
$ weston-simple-shm => basic wayland example
--
1.7.9.5
More information about the meta-freescale
mailing list