doc: Fix typos

Fix typos/wording in various files in doc/.

Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: E Shattow <e@freeshell.de>

diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index c25b986..634114a 100644 (file)
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -288,7 +288,7 @@ The full devicetree is available to U-Boot proper, but normally only a subset
 Using several DTBs in the SPL (SPL_MULTI_DTB_FIT Kconfig option)
 ----------------------------------------------------------------
 In some rare cases it is desirable to let SPL be able to select one DTB among
-many. This usually not very useful as the DTB for the SPL is small and usually
+many. This is usually not very useful as the DTB for the SPL is small and usually
 fits several platforms. However the DTB sometimes include information that do
 work on several platforms (like IO tuning parameters).
 In this case it is possible to use SPL_MULTI_DTB_FIT Kconfig option. This option

diff --git a/doc/develop/driver-model/fdt-fixup.rst b/doc/develop/driver-model/fdt-fixup.rst
index 974c090..b547daf 100644 (file)
--- a/doc/develop/driver-model/fdt-fixup.rst
+++ b/doc/develop/driver-model/fdt-fixup.rst
@@ -45,7 +45,7 @@ An additional problem with the device tree in U-Boot is that it is read-only,
 and the current mechanisms don't allow easy manipulation of the device tree
 after the driver model has been initialized. While migrating to a live device
 tree (at least after the relocation) would greatly simplify the solution of
-this problem, it is a non-negligible task to implement it, an a interim
+this problem, it is a non-negligible task to implement it, an ad interim
 solution is needed to address the problem at least in the medium-term.
 
 Hence, we propose a solution to this problem by offering a board-specific

diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
index aa7786c..3a2b496 100644 (file)
--- a/doc/develop/testing.rst
+++ b/doc/develop/testing.rst
@@ -28,7 +28,7 @@ run. Type this::
 
     make tcheck
 
-You can also run a selection tests in parallel with::
+You can also run a selection of tests in parallel with::
 
     make pcheck
 
@@ -39,7 +39,7 @@ are run. See :doc:`pytest/usage` for more information.
 Sandbox
 -------
 U-Boot can be built as a user-space application (e.g. for Linux). This
-allows test to be executed without needing target hardware. The 'sandbox'
+allows tests to be executed without needing target hardware. The 'sandbox'
 target provides this feature and it is widely used in tests.
 
 See :doc:`tests_sandbox` for more information.

diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst
index d3c8628..16635d6 100644 (file)
--- a/doc/develop/trace.rst
+++ b/doc/develop/trace.rst
@@ -354,7 +354,7 @@ Writing Out Trace Data
 ----------------------
 
 Once the trace data is in an output buffer in memory there are various ways
-to transmit it to the host. Notably you can use tftput to send the data
+to transmit it to the host. Notably you can use tftpput to send the data
 over a network link::
 
     fakegocmd=trace pause; usb start; set autoload n; bootp;

diff --git a/doc/mkimage.1 b/doc/mkimage.1
index 75b6b48..c705218 100644 (file)
--- a/doc/mkimage.1
+++ b/doc/mkimage.1
@@ -208,7 +208,7 @@ option and the format of their configuration are listed in
 .TQ
 .BI \-\-secondary\-config " secondary-configuration"
 Some image types support a second set of configuration data. The image types
-which support secondary configuration and the formap of their configuration are
+which support secondary configuration and the format of their configuration are
 listed in
 .BR CONFIGURATION .
 .
@@ -396,7 +396,7 @@ when used together with -K and/or -k options.
 .BI \-\-key\-dest " key-destination"
 Specifies a compiled device tree binary file (typically .dtb) to write
 public key information into. When a private key is used to sign an image,
-the corresponding public key is written into this file for for run-time
+the corresponding public key is written into this file for run-time
 verification. Typically the file here is the device tree binary used by
 CONFIG_OF_CONTROL in U-Boot.
 .

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 5553a62..0143f81 100644 (file)
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -213,7 +213,7 @@ updatefile
 
 autoload
     if set to "no" (any string beginning with 'n'),
-    "bootp" and "dhcp" will just load perform a lookup of the
+    "bootp" and "dhcp" will just perform a lookup of the
     configuration from the BOOTP server, but not try to
     load any image.
 

diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst
index 1298ba1..b153994 100644 (file)
--- a/doc/usage/fit/beaglebone_vboot.rst
+++ b/doc/usage/fit/beaglebone_vboot.rst
@@ -473,7 +473,7 @@ you sign::
 Here we are overriding the normal device tree file with our one, which
 contains the public key.
 
-Now you have a special U-Boot image with the public key. It can verify can
+Now you have a special U-Boot image with the public key. It can verify any
 kernel that you sign with the private key as in step 5.
 
 If you like you can take a look at the public key information that mkimage

diff --git a/doc/usage/fit/overlay-fdt-boot.rst b/doc/usage/fit/overlay-fdt-boot.rst
index d687e98..f5af6d9 100644 (file)
--- a/doc/usage/fit/overlay-fdt-boot.rst
+++ b/doc/usage/fit/overlay-fdt-boot.rst
@@ -19,7 +19,7 @@ Configuration without overlays
 ------------------------------
 
 Take a hypothetical board named 'foo' where there are different supported
-revisions, reva and revb. Assume that both board revisions can use add a bar
+revisions, reva and revb. Assume that both board revisions can add a bar
 add-on board, while only the revb board can use a baz add-on board.
 
 Without using overlays the configuration would be as follows for every case::
@@ -97,7 +97,7 @@ Without using overlays the configuration would be as follows for every case::
        };
 
 Note the blob needs to be compiled for each case and the combinatorial explosion of
-configurations. A typical device tree blob is in the low hunderds of kbytes so a
+configurations. A typical device tree blob is in the low hundreds of kbytes so a
 multitude of configuration grows the image quite a bit.
 
 Booting this image is done by using::
@@ -117,7 +117,7 @@ Configuration using overlays
 ----------------------------
 
 Device tree overlays can be applied to a base DT and result in the same blob
-being passed to the booting kernel. This saves on space and avoid the combinatorial
+being passed to the booting kernel. This saves on space and avoids the combinatorial
 explosion problem::
 
     /dts-v1/;
@@ -164,7 +164,7 @@ explosion problem::
         };
 
         configurations {
-            default = "foo-reva.dtb;
+            default = "foo-reva.dtb";
             foo-reva.dtb {
                 kernel = "kernel";
                 fdt = "fdt-1", "fdt-2";
@@ -209,9 +209,9 @@ to be writeable.
 Configuration using overlays and feature selection
 --------------------------------------------------
 
-Although the configuration in the previous section works is a bit inflexible
-since it requires all possible configuration options to be laid out before
-hand in the FIT image. For the add-on boards the extra config selection method
+Although the configuration in the previous section works, it is a bit inflexible
+since it requires all possible configuration options to be laid out beforehand
+in the FIT image. For the add-on boards the extra config selection method
 might make sense.
 
 Note the two bar & baz configuration nodes. To boot a reva board with