This fixes four small typos in the README file.

Signed-off-by: Michael Heimpold mhei@heimpold.de Cc: Simon Glass sjg@chromium.org --- tools/binman/README | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/binman/README b/tools/binman/README index cb34171e5f..9d9d1832ee 100644 --- a/tools/binman/README +++ b/tools/binman/README @@ -130,9 +130,9 @@ called from the U-Boot build system for this reason.

Binman considers the output files created by mkimage to be binary blobs which it can place in an image. Binman does not replace the mkimage tool or -this purpose. It would be possible in some situtions to create a new entry +this purpose. It would be possible in some situations to create a new entry type for the images in mkimage, but this would not add functionality. It -seems better to use the mkiamge tool to generate binaries and avoid blurring +seems better to use the mkimage tool to generate binaries and avoid blurring the boundaries between building input files (mkimage) and packaging then into a final image (binman).

@@ -169,7 +169,7 @@ Example use of binman for x86 In most cases x86 images have a lot of binary blobs, 'black-box' code provided by Intel which must be run for the platform to work. Typically these blobs are not relocatable and must be placed at fixed areas in the -firmare image. +firmware image.

Currently this is handled by ifdtool, which places microcode, FSP, MRC, VGA BIOS, reference code and Intel ME binaries into a u-boot.rom file. @@ -406,7 +406,7 @@ either by using a unit number suffix (u-boot@0, u-boot@1) or by using a different name for each and specifying the type with the 'type' attribute.

-Sections and hiearchical images +Sections and hierachical images -------------------------------

Sometimes it is convenient to split an image into several pieces, each of which