From f1ca2420a503c47e5fadae6f7431634797bc0cf8 Mon Sep 17 00:00:00 2001 From: Ahmad Fatoum Date: Thu, 4 Oct 2018 15:55:14 +0200 Subject: doc: Fix typos Signed-off-by: Ahmad Fatoum Signed-off-by: Michael Olbrich --- doc/daily_work.inc | 20 ++++++++++---------- doc/dev_manual.rst | 2 +- doc/faq.rst | 6 +++--- doc/ref_manual.rst | 10 +++++----- doc/user_manual.inc | 14 +++++++------- doc/welcome.rst | 4 ++-- 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/``. We must +platform directory usually in ``configs/``. 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- -cpu -L . usr/bin/myapp This command will run the application ``usr/bin/myapp`` built for an - CPU on the build host and is using all library compontents + 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- -g 1234 -cpu -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 ``_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 ```` 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 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 parameter was given, the file can be renamed while copying. If the parameter was given as a minus @@ -1443,7 +1443,7 @@ Replace the 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 -- cgit v1.2.3