Re: [PATCH 3/9] doc: Fix typos

[E Shattow <e@freeshell.de>]

On 10/24/25 08:11, Wolfgang Wallner wrote:
> Fix typos/wording in various files in doc/.
> 
> Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> ---
> 
>  doc/develop/devicetree/control.rst     |  2 +-
>  doc/develop/driver-model/fdt-fixup.rst |  2 +-
>  doc/develop/testing.rst                |  4 ++--
>  doc/develop/trace.rst                  |  2 +-
>  doc/mkimage.1                          |  4 ++--
>  doc/usage/environment.rst              |  2 +-
>  doc/usage/fit/beaglebone_vboot.rst     |  2 +-
>  doc/usage/fit/overlay-fdt-boot.rst     | 14 +++++++-------
>  8 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
> index c25b98683f8..634114af59a 100644
> --- 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 974c09031ed..b547daf79ff 100644
> --- 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 aa7786c99fd..3a2b496fa00 100644
> --- 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 d3c8628d124..16635d6d238 100644
> --- 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 75b6b48a0cf..c705218d345 100644
> --- 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 5553a629e42..0143f81f2c0 100644
> --- 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 1298ba1ae08..b15399441ee 100644
> --- 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 d687e98ea2a..f5af6d9df05 100644
> --- 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

Thanks for doing this work,

Reviewed-by: E Shattow <e@freeshell.de>