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>
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
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
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
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.
----------------------
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;
.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 .
.
.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.
.
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.
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
------------------------------
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::
};
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::
----------------------------
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/;
};
configurations {
- default = "foo-reva.dtb;
+ default = "foo-reva.dtb";
foo-reva.dtb {
kernel = "kernel";
fdt = "fdt-1", "fdt-2";
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
projects / thirdparty / u-boot.git / commitdiff
