On 10/24/25 08:11, Wolfgang Wallner wrote: > Fix typos/wording in various files in doc/. > > Signed-off-by: Wolfgang Wallner <[email protected]> > --- > > 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 <[email protected]>
