michael/u-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: Fix typos

Browse Source 
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>
This commit is contained in:
Wolfgang Wallner
2025-10-24 17:11:59 +02:00
committed by Tom Rini
parent 66f7574ddd
commit ed00d12c01
8 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/develop/devicetree/control.rst
View File

@@ -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

2
doc/develop/driver-model/fdt-fixup.rst
View File

@@ -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

4
doc/develop/testing.rst
View File

@@ -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.

2
doc/develop/trace.rst
View File

@@ -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;

4
doc/mkimage.1
View File

@@ -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.
.

2
doc/usage/environment.rst
View File

@@ -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.

2
doc/usage/fit/beaglebone_vboot.rst
View File

@@ -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

14
doc/usage/fit/overlay-fdt-boot.rst
View File

@@ -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