doc: Fix typos

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>

6 files changed, 28 insertions, 28 deletions

diff --git a/doc/daily_work.inc b/doc/daily_work.inc
index c93ab5b85..47bc987e4 100644
--- a/doc/daily_work.inc
+++ b/doc/daily_work.inc
@@ -89,7 +89,7 @@ missing component is a valid kernel config file now. We can use one of
 the default config files the Linux kernel supports as a starting point.
 To do so, we copy one to the location, where PTXdist expects it in the
 current project. In a multi platform project this location is the
-platform directory usally in ``configs/<platform-directory>``. We must
+platform directory usually in ``configs/<platform-directory>``. We must
 store the file with a name selected in the platform setup menu (**kernel
 config file**).
 
@@ -231,7 +231,7 @@ With this preparation we can run it on our build host:
     |ptxdistPlatformDir|/root$ qemu-<architecture> -cpu <cpu-core> -L . usr/bin/myapp
 
 This command will run the application ``usr/bin/myapp`` built for an
-<cpu-core> CPU on the build host and is using all library compontents
+<cpu-core> CPU on the build host and is using all library components
 from the current directory.
 
 For the stdin and -out QEMU uses the regular mechanism of the build
@@ -256,7 +256,7 @@ the QEMU in the first console as:
     $ cd ptxdistPlatformDir/root
     ptxdistPlatformDir/root$ qemu-<architecture> -g 1234 -cpu <cpu-core> -L . usr/bin/myapp
 
-.. note:: PTXdist always builds a root filesystems ``root/``.
+.. note:: PTXdist always builds a root filesystem ``root/``.
   It contains all components without debug 
   information (all binaries are in the same size as used later on on the
   real target). In addition, each directory that contains binaries also
@@ -320,7 +320,7 @@ Now we can step through our application by using the commands *step*,
   stripped while building the toolchain. There is a switch in the
   OSELAS.Toolchain menu to keep the debug symbols also for the C run-time
   library. But be warned: This will enlarge the OSELAS.Toolchain
-  installation on your harddisk! When the toolchain was built with the
+  installation on your hard disk! When the toolchain was built with the
   debug symbols kept, it will be also possible for GDB to debug C library
   functions our application calls (so it might worth the disk space).
 
@@ -713,7 +713,7 @@ relocation problems or files outside the install directory are needed:
    in an incomplete pre-built archive. Due to this, it cannot be used
    as a pre-built archive.
 
--  a few somehow broken packages that are all explicitely marked with a
+-  a few somehow broken packages that are all explicitly marked with a
    ``<packagename>_DEVPKG := NO`` in their corresponding rule file.
 
 Workflow with Pre-Built Archives
@@ -823,7 +823,7 @@ provide a comfortable buildsystem:
 - a program combined with a library package template
 
 Some template components are shared between all three packages types and described
-here, some other template componente are indvidual to each package type and
+here, some other template components are individual to each package type and
 described later on.
 
 Shared components
@@ -883,7 +883,7 @@ feature to the buildsystem. It handles all the details how to parametrize the
 compiler and linker correctly.
 
 The ``pkg.m4`` must be shipped with a package which uses *pkg-config* to detect
-the existance of external libraries and query details how to use them. If your
+the existence of external libraries and query details how to use them. If your
 package doesn't use *pkg-config*, you can remove this file (and remove it from
 the EXTRA_DIST variable in ``Makefile.am``).
 
@@ -914,7 +914,7 @@ Build system related files
 
 The autotools are using macro files which are easier to read for a
 human. But to work with the autotools these macro files must be
-converted into executabe shell code first. The ``autogen.sh`` script
+converted into executable shell code first. The ``autogen.sh`` script
 does this job for us.
 
 **configure.ac**
@@ -1157,7 +1157,7 @@ file need your attention:
 
 It is not easy to fully automate the adaption of the pc file. At least
 the lines *Requires*, *Requires.private* and *Libs.private* are hardly to fill
-for packages which are highly configureable.
+for packages which are highly configurable.
 
 I nice and helpful description about this kind of configuration file can be
 found here:
@@ -1181,7 +1181,7 @@ your library.
 
 The main source file of your library. Keep in mind to mark all functions
 with the DSO_VISIBLE macro you want to export. All other functions are
-kept internaly and you cannot link against them from an external
+kept internally and you cannot link against them from an external
 application.
 
 Note: debugging is hard when all internal functions are hidden. For this
diff --git a/doc/dev_manual.rst b/doc/dev_manual.rst
index f3dc00e9e..a14e64b0f 100644
--- a/doc/dev_manual.rst
+++ b/doc/dev_manual.rst
@@ -1635,7 +1635,7 @@ build directory are created here. The layer below is defined by the
 subdirectory or symlink named ``base/``. More can be stacked the same
 way, so ``base/base/`` is the third layer and so on.
 In many ways, PTXdist itself can be considered as the bottom layer. This is
-either implicit or explicit with on last ``base/`` symlink.
+either implicit or explicit with one last ``base/`` symlink.
 
 A project can overwrite files provided by PTXdist in many different ways,
 e.g. rule files or files installed with :ref:`install_alternative` etc.
diff --git a/doc/faq.rst b/doc/faq.rst
index e05287815..f85f6e336 100644
--- a/doc/faq.rst
+++ b/doc/faq.rst
@@ -64,7 +64,7 @@ Answer:
 I want to backup all source archives for my BSP
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Question:
-  I want to backup the source archives my PTXdist project relys on.
+  I want to backup the source archives my PTXdist project relies on.
   How can I find out what packages my project requires to build?
 
 Answer:
@@ -160,14 +160,14 @@ Answer:
 I get the error “cannot run '/etc/init.d/rcS': No such file or directory”
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Question:
-  I made a new project and everythings seems fine. But when I start my
+  I made a new project and everything seems fine. But when I start my
   target with the root filesystem generated by PTXdist, it fails with::
 
       cannot run '/etc/init.d/rcS': No such file or directory
 
 Answer:
   The error message is confusing. But this script needs ``/bin/sh`` to
-  run. Most of the time this message occures when ``/bin/sh`` does not
+  run. Most of the time this message occurs when ``/bin/sh`` does not
   exists. Did you enable it in your busybox configuration?
 
 I get the error “ptxdist: archives: command not found”
diff --git a/doc/ref_manual.rst b/doc/ref_manual.rst
index 2391982d2..74bf84b5c 100644
--- a/doc/ref_manual.rst
+++ b/doc/ref_manual.rst
@@ -437,7 +437,7 @@ Whenever one of these macros installs something to the target's root filesystem,
 it also accepts user and group IDs which are common in all filesystems Linux
 supports. These IDs can be given as numerical values and as text strings.
 In the case text strings are given PTXdist converts them into the
-coresponding numerical value based on the BSP local files :file:`passwd` and :file:`group`.
+corresponding numerical value based on the BSP local files :file:`passwd` and :file:`group`.
 If more than one file with these names are present in the BSP PTXdist follows
 its regular rules which one it prefers.
 
@@ -467,7 +467,7 @@ Usage:
 
  $(call targetinfo)
 
-Gives a feedback, what build *stage* is just started. Thats why it
+Gives a feedback, what build *stage* is just started. That's why it
 should always be the first call for each *stage*. For the package
 *foo* and the *compile stage* it will output:
 
@@ -486,7 +486,7 @@ Usage:
 
  $(call touch)
 
-Gives a feedback, what build *stage* is just finished. Thats why it
+Gives a feedback, what build *stage* is just finished. That's why it
 should always be the last call for each *stage*. For the package
 *foo* and the *compile stage* it will output:
 
@@ -555,7 +555,7 @@ The ``<dest>`` parameter can be:
 
 * omitted if a directory in target's root filesystem should be created.
   For this case the directory to be created is in the <source> parameter.
-* an absolute path and filename with its root in target's root filesysem.
+* an absolute path and filename with its root in target's root filesystem.
   It must start with a slash (``//``). If also the <source>
   parameter was given, the file can be renamed while copying.
   If the <source> parameter was given as a minus
@@ -1443,7 +1443,7 @@ Replace the <stage_to_skip> by ``get``, ``extract``, ``prepare``,
 PTXdist parameter reference
 ---------------------------
 
-PTXdist is a command line tool, which is basicly called as:
+PTXdist is a command line tool, which is basically called as:
 
 .. code-block:: bash
 
diff --git a/doc/user_manual.inc b/doc/user_manual.inc
index f4acd7a4b..e41995782 100644
--- a/doc/user_manual.inc
+++ b/doc/user_manual.inc
@@ -60,7 +60,7 @@ A different use case for collections could be the security of an
 application. While the development is ongoing all kind of debugging and
 logging helpers are part of the root filesystem. But the final
 production root filesystem uses collections to omit all these helpers
-and to reduce the risc of security vulnerability.
+and to reduce the risk of security vulnerability.
 
 PTXdist can handle the following project variations:
 
@@ -146,7 +146,7 @@ function, we run it with the parameter *help*.
 
     $ ptxdist help
 
-This will output all possible parameters ans subcommands and their
+This will output all possible parameters and subcommands and their
 meaning.
 
 As the list we see is very long, let’s explain the major parameters
@@ -282,7 +282,7 @@ Notes about some of the files and directories listed above:
 
 **documentation**
     If this BSP is one of our OSELAS BSPs, this directory contains the
-    Quickstart you are currenly reading in.
+    Quickstart you are currently reading in.
 
 **configs**
     A multiplatform BSP contains configurations for more than one
@@ -386,24 +386,24 @@ project.
 
 ``|ptxdistPlatformDir|/build-cross``
     Contains all packages sources compiled to run on the host and handle
-    target architecture dependend things.
+    target architecture dependent things.
 
 ``|ptxdistPlatformDir|/build-host``
     Contains all packages sources compiled to run on the host and handle
     architecture independend things.
 
 ``|ptxdistPlatformDir|/build-target``
-    Contains all package sources compiled for the target architecure.
+    Contains all package sources compiled for the target architecture.
 
 ``|ptxdistPlatformDir|/images``
     Generated files for the target can be found here: Kernel image and
     root filesystem image.
 
 ``|ptxdistPlatformDir|/packages``
-    Location for alle individual packages in ipk format.
+    Location for all individual packages in ipk format.
 
 ``|ptxdistPlatformDir|/sysroot-target``
-    Contains everything target architecture dependend (libraries, header
+    Contains everything target architecture dependent (libraries, header
     files and so on).
 
 ``|ptxdistPlatformDir|/sysroot-cross``
diff --git a/doc/welcome.rst b/doc/welcome.rst
index cf0327369..58d3a4146 100644
--- a/doc/welcome.rst
+++ b/doc/welcome.rst
@@ -20,7 +20,7 @@ developed and our brave developer was able to do his project with the
 more and more well-known system. The controllers had legacy interfaces
 like RS232, i2c or SPI which connected them to the outside world and the
 main difference between the controllers available on the market was the
-number of GPIO pins, UARTS and memory resources.
+number of GPIO pins, UARTs and memory resources.
 
 Things have changed. Hardware manufacturers have weakened the border
 between deeply embedded microcontrollers – headless devices with just a
@@ -60,7 +60,7 @@ embedded operating system suppliers will survive that development.
 
 Only the largest commercial...? There is one exception: when the same
 situation came up in the “mainstream” computer market at the beginning
-of the 1990ies, people started to develop an alternative to the large
+of the 1990es, people started to develop an alternative to the large
 commercial operating systems: Linux. Linux did never start with a
 ready-to-use solution: people had a problem, searched for a solution but
 didn’t find one. Then they started to develop one themselves, often