Merge pull request #83 from OnkelUlla/fix_docu_typos

docs: fix typos

docs/checklist.rst

@@ -17,7 +17,7 @@ Configuration
 -------------
 
 Most systems require a location for storing configuration data. Unlike for
-example the root or application filesystems which are often mounted as
+example the root or application filesystems which are often mounted
 read-only, a configuration partition would be writable to allow modifying
 configuration data.
 

docs/integration.rst

@@ -18,7 +18,7 @@ Slot configuration
 
 The most important step is to describe the slots that rauc should use
 when performing updates. Which slots are required and what you have to take
-care of when designing you system will be covered in the chapter :ref:`todo`.
+care of when designing your system will be covered in the chapter :ref:`todo`.
 This section assumes, you have already decided on a setup and want to describe
 it for rauc.
 
@@ -33,8 +33,8 @@ class names used in the system config match those in the update manifests.
 
 The mandatory settings for each slot are, the ``device`` that holds the
 (device) path describing *where* the slot is located, the ``type`` that
-provides defines *how* to update the target device, and the ``bootname``
-which is the name the bootloader uses to refer to this slot device.
+defines *how* to update the target device, and the ``bootname`` which is
+the name the bootloader uses to refer to this slot device.
 
 Type
 ^^^^
@@ -47,7 +47,7 @@ A list of common types supported by rauc:
 | raw      | A partition holding no (known) file system. Only raw image copies |
 |          | may be performed.                                                 |
 +----------+-------------------------------------------------------------------+
-| ext4     | A partition holing an ext4 filesystem.                            |
+| ext4     | A partition holding an ext4 filesystem.                           |
 +----------+-------------------------------------------------------------------+
 | nand     | A NAND partition.                                                 |
 +----------+-------------------------------------------------------------------+
@@ -64,7 +64,7 @@ Yocto support for using rauc is provided by the `meta-ptx
 
 The layer supports building rauc both for the target as well as a host tool.
 With the `bundle.bbclass` it provides a mechanism to specify and build bundles
-directly with of Yocto.
+directly with the help of Yocto.
 
 Target system setup
 ~~~~~~~~~~~~~~~~~~~
@@ -119,7 +119,7 @@ tool, or by using the ``bundle.bbclass`` that handles most of the basic steps,
 automatically.
 
 First, create a bundle recipe in your BSP layer. A possible location for this
-could be ``meta-your-pbsp/recipes/core/bundles/update-bundle.bb``.
+could be ``meta-your-pbsp/recipes-core/bundles/update-bundle.bb``.
 
 To create your bundle you first have to inherit the bundle class::
 
@@ -136,13 +136,13 @@ For using the built-in bundle generation, you need to specify some variables:
   target platform you intend to install this bundle on.
 
 ``RAUC_BUNDLE_SLOTS``
-  Use this to list all slot classes for which bundle should contain images. A
-  value of ``"rootfs appfs"`` for example will create a manifest with images
+  Use this to list all slot classes for which the bundle should contain images.
+  A value of ``"rootfs appfs"`` for example will create a manifest with images
   for two slot classes; rootfs and appfs.
 
 ``RAUC_SLOT_<slotclass>``
-  For each slot class, set this to the image (recipe) name which build artifact
-  you intend to place in it.
+  For each slot class, set this to the image (recipe) name which builds the
+  artifact you intend to place in the slot class.
 
 ``RAUC_SLOT_<slotclass>[type]``
   For each slot class, set this to the *type* of image you intend to place in

docs/overview.rst

@@ -8,8 +8,8 @@ Updating an embedded system is always a crucial step during the life cycle of
 an embedded hardware product. Updates are important to either fix system bugs,
 solve security problems or simply for adding new features to a platform.
 
-As embedded hardware often is placed in location that make it difficult or
-costly to gain access the board itself, an update must be performed unattended;
+As embedded hardware often is placed in locations that make it difficult or
+costly to gain access to the board itself, an update must be performed unattended;
 for example either by plugging in a special USB stick or by some network
 roll-out strategy.
 
@@ -18,18 +18,18 @@ procedure crashes, the underlying storage fails with a write error, or someone
 accidentally switches the power off, etc. All this may occur but should not
 lead to having an unbootable hardware at the end.
 
-Another point beside safe upgrades are security considerations. You would like
+Another point besides safe upgrades are security considerations. You would like
 to prevent that someone unauthorized is able to load modified firmware onto the
 system.
 
-When designing the rauc update tool, all of this requirements were taken into
+When designing the rauc update tool, all of these requirements were taken into
 consideration. In the following, we provide a short overview of basic concepts,
 principles and solutions rauc provides for updating an embedded system.
 
 Features
 --------
 
-* Supports whole-system updates using at least two redundant installations
+* Supports whole-system updates using at least two redundant installations:
 
   * Symmetric: Root-FS A & Root-FS B
   * Asymmetric: recovery & normal
@@ -76,15 +76,15 @@ Slots
 
 Rauc's view of the target system it is running on is described using so-called
 slots. Slots are possible targets for (parts of) updates. Usually, they are
-partitions on a SD/eMMC, UBI volumes on NAND/NOR flash or raw block devices.
+partitions on an SD/eMMC, UBI volumes on NAND/NOR flash or raw block devices.
 The system designer must provide a configuration file that lists all slots that
 rauc should use and describe which device they are stored on, how the
 bootloader may detect them, etc.
 
 Bundles
 -------
 
-A update bundle is a squashfs-packed set of config files, scripts, and disk
+An update bundle is a squashfs-packed set of config files, scripts, and disk
 images with an appended signature that allows verifying the bundle's origin and
 integrity.
 
@@ -103,7 +103,7 @@ system) fails for e.g. 3 times, the next lower priority boot source is chosen
 As updates are always installed in a currently inactive slot, the boot priority
 must be changed after a successful update.
 
-Basic update procedure
+Basic Update Procedure
 ----------------------
 
 The rauc service that runs on the target will perform an update when being
@@ -113,34 +113,34 @@ by a script that checks for example for insertion of an USB stick containing a
 firmware bundle. Then the default (and simplified) update behavior will be the
 following:
 
-1. Rauc verifies the bundles by checking its signature against the keyring
+1. Rauc verifies the bundle by checking its signature against the keyring
    located in the root file system. A bundle with an invalid signature will be
    rejected.
 
 2. Rauc mounts the bundle (which simply is a squashfs image)
 
-3. Verification of bundle compatibility
+3. Verify bundle compatibility:
 
-   - the compatible string in the manifest is compared against the compatible
-     string stored in the system configuration file
-   - if the strings are different, the bundle will be rejected to prevent
-     installing an incompatible bundle
+   - The compatible string in the manifest is compared against the compatible
+     string stored in the system configuration file.
+   - If the strings are different, the bundle will be rejected to prevent
+     installing an incompatible bundle.
 
 4. Determine the target *install group*, i.e. which slots an update will be
-   installed to
+   installed to.
 
-7. Mark target slots as non-bootable for bootloader
+7. Mark target slots as non-bootable for bootloader.
 
 6. Iterate over each image specified in the manifest
 
-   * Try to read slot status informations
+   * Try to read slot status informations.
    * If the provided slot image is different from the installed one:
-     Update slot with a method determined by the type of slot and the image type
-   * Try to write slot status informations
+     Update slot with a method determined by the type of slot and the image type.
+   * Try to write slot status informations.
 
-7. Mark target slots as new primary boot source for the bootloader
+7. Mark target slots as new primary boot source for the bootloader.
 
-8. Terminate successfully if no error occurred
+8. Terminate successfully if no error occurred.
 
 Once the update controller receives an update request instruction containing
 the file path of a firmware bundle it verifies its signature based on a public

docs/reference.rst

@@ -42,7 +42,7 @@ Example configuration:
 ``compatible``
   A user-defined compatible string that describes the target hardware as
   specific enough as required to prevent faulty updating systems with the wrong
-  firmware. It will be matched again the ``compatible`` string defined in the
+  firmware. It will be matched against the ``compatible`` string defined in the
   update manifest.
 
 ``bootloader``
@@ -67,7 +67,7 @@ call for different purposes. All parameters expect pathnames to the script to
 be executed. Path names are either absolute or relative to the system.conf file
 location.
 
-Rauc passes a set of environment variables to handler script. See details about
+Rauc passes a set of environment variables to handler scripts. See details about
 using handlers in :ref:`Custom Handlers (Interface)`.
 
 ``system-info``
@@ -88,7 +88,7 @@ The *slot class* name is used in the *update manifest* to target the correct
 set of slots.
 
 ``device``
-  The slots device path.
+  The slot's device path.
 
 ``type``
   The type describing the slot. Currently supported values are ``raw``,
@@ -97,17 +97,17 @@ set of slots.
 
 ``bootname``
   For bootable slots, the name the bootloader uses to identify it. The real
-  meaning of this depends on the bootloader implemenation used.
+  meaning of this depends on the bootloader implementation used.
 
 ``parent``
   The ``parent`` entry is used to bind additional slots to a bootable root
   file system slot.
-  This is used together with the ``bootname`` to identify the set currently
+  This is used together with the ``bootname`` to identify the set of currently
   active slots, so that the inactive one can be selected as the update target.
   The parent slot is referenced using the form ``<slot-class>.<idx>``.
 
 ``readonly``
-  Marks the slot as existing but not updateable. Maybe used for sanity checking
+  Marks the slot as existing but not updatable. Maybe used for sanity checking
   or informative purpose. A ``readonly`` slot cannot be a target slot.
 
 
@@ -160,7 +160,7 @@ A valid manifest file must have the file extension ``.raucm``.
   Hook script path name, relative to the bundle content.
 
 ``hooks``
-  List of hook enabled for this bundle.
+  List of hooks enabled for this bundle.
 
 
 **[image.<slot-class>] section**
@@ -169,11 +169,11 @@ A valid manifest file must have the file extension ``.raucm``.
   Name of the image file (relative to bundle content).
 
 ``sha256``
-  sha256 of image file. rauc Determines this value automatically when creating
+  sha256 of image file. rauc determines this value automatically when creating
   a bundle, thus it is not required to set this by hand.
 
 ``size``
-  size of image file. rauc Determines this value automatically when creating a
+  size of image file. rauc determines this value automatically when creating a
   bundle, thus it is not required to set this by hand.
 
 ``hooks``
@@ -186,9 +186,9 @@ Slot Status File
 ----------------
 
 A slot status file is generated by rauc after having updated a slot. If the
-slot is writeable for rauc (because it contains a filesystem), it will place a
-small file named ``slot.raucs`` in its root directory, containing the sha25 of
-the installed image.
+slot is writeable for rauc (because it contains a writable filesystem), it will
+place a small file named ``slot.raucs`` in its root directory, containing the
+sha25 of the installed image.
 
 .. code-block:: cfg
 
@@ -315,15 +315,15 @@ Method Details
 
 .. _gdbus-method-de-pengutronix-rauc-Installer.Install:
 
-The Install() method
+The Install() Method
 ^^^^^^^^^^^^^^^^^^^^
 
 .. code::
 
   de.pengutronix.rauc.Installer.Install()
   Install (IN  s source);
 
-Triggers an installation.
+Triggers the installation of a bundle.
 
 IN s *source*:
     Path to bundle to be installed
@@ -333,15 +333,15 @@ Signal Details
 
 .. _gdbus-signal-de-pengutronix-rauc-Installer.Completed:
 
-The "Completed" signal
+The "Completed" Signal
 ^^^^^^^^^^^^^^^^^^^^^^
 
 .. code::
 
   de.pengutronix.rauc.Installer::Completed
   Completed (i result);
 
-This signal is emitted when installation completed, either
+This signal is emitted when an installation completed, either
 successfully or with an error.
 
 i *result*:
@@ -352,31 +352,31 @@ Property Details
 
 .. _gdbus-property-de-pengutronix-rauc-Installer.Operation:
 
-The "Operation" property
+The "Operation" Property
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. code::
 
   de.pengutronix.rauc.Installer:Operation
   Operation  readable   s
 
-Represents the current (global) operation rauc performs
+Represents the current (global) operation rauc performs.
 
 .. _gdbus-property-de-pengutronix-rauc-Installer.LastError:
 
-The "LastError" property
+The "LastError" Property
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. code::
 
   de.pengutronix.rauc.Installer:LastError
   LastError  readable   s
 
-Holds the last message of the last error that occured
+Holds the last message of the last error that occured.
 
 .. _gdbus-property-de-pengutronix-rauc-Installer.Progress:
 
-The "Progress" property
+The "Progress" Property
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 .. code::