[PATCH 3/9] doc: Fix typos
E Shattow
e at freeshell.de
Fri Oct 24 22:43:13 CEST 2025
On 10/24/25 08:11, Wolfgang Wallner wrote:
> Fix typos/wording in various files in doc/.
>
> Signed-off-by: Wolfgang Wallner <wolfgang.wallner at 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 at freeshell.de>
More information about the U-Boot
mailing list