From: Antonio Borneo <borneo.antonio@gmail.com>
Date: Sat, 25 Apr 2020 23:39:16 +0000 (+0200)
Subject: doc: fix typo and spelling
X-Git-Tag: v0.11.0-rc1~302
X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=commitdiff_plain;h=3a28cdc7cb790e388f0e142510858bee0b642597

doc: fix typo and spelling

Identified by checkpatch script from Linux kernel v5.7-rc1 using
the command
	find doc/ -type f -exec ./tools/scripts/checkpatch.pl \
	-q --types TYPO_SPELLING --strict -f {} \;

Change-Id: I1269ac966027439e16eb6e63179e43925bec37fa
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5614
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Tested-by: jenkins
---

diff --git a/doc/manual/target/mips.txt b/doc/manual/target/mips.txt
index 5121d12765..25978a3d52 100644
--- a/doc/manual/target/mips.txt
+++ b/doc/manual/target/mips.txt
@@ -395,7 +395,7 @@ for (i = 0; i < count; i++)
 
 Each time when OpenOCD fills data to CPU (via dongle, via dmseg), CPU takes it and proceeds in executing the handler. However, since handler is in a assembly loop,
 CPU comes to next instruction which also fetches data from FASTDATA area. So it stalls.
-Then OpenOCD fills the data again, from it's (OpenOCD's) loop. And this game continues untill all the data has been filled.
+Then OpenOCD fills the data again, from it's (OpenOCD's) loop. And this game continues until all the data has been filled.
 
 After the last data has been given to CPU it sees that it reached the end address, so it proceeds with next instruction. However, this instruction do not point into dmseg, so
 CPU executes bunch of handler instructions (all prologue) and in the end jumps to MIPS32_PRACC_TEXT address.
diff --git a/doc/openocd.texi b/doc/openocd.texi
index f3f963ecdf..ef77993ec8 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1474,7 +1474,7 @@ While the default is normally provided by the chip manufacturer,
 board files may need to distinguish between instances of a chip.
 @item @code{ENDIAN} ...
 By default @option{little} - although chips may hard-wire @option{big}.
-Chips that can't change endianess don't need to use this variable.
+Chips that can't change endianness don't need to use this variable.
 @item @code{CPUTAPID} ...
 When OpenOCD examines the JTAG chain, it can be told verify the
 chips against the JTAG IDCODE register.
@@ -6459,7 +6459,7 @@ code.
 @end deffn
 
 @deffn Command {nrf5 info}
-Decodes and shows informations from FICR and UICR registers.
+Decodes and shows information from FICR and UICR registers.
 @end deffn
 
 @end deffn
@@ -9774,7 +9774,7 @@ or a custom types described with @command{arc add-reg-type-[flags|struct]}.
 @item @code{-g}
 @* If specified then this is a "general" register. General registers are always
 read by OpenOCD on context save (when core has just been halted) and is always
-transfered to GDB client in a response to g-packet. Contrary to this,
+transferred to GDB client in a response to g-packet. Contrary to this,
 non-general registers are read and sent to GDB client on-demand. In general it
 is not recommended to apply this option to custom registers.
 
@@ -9815,7 +9815,7 @@ therefore it is unsafe to use if that register can be operated by other means.
 @end deffn
 
 @deffn {Command} {arc jtag set-core-reg} regnum value
-This command is similiar to @command{arc jtag set-aux-reg} but is for core
+This command is similar to @command{arc jtag set-aux-reg} but is for core
 registers.
 @end deffn
 
@@ -9827,7 +9827,7 @@ therefore it is unsafe to use if that register can be operated by other means.
 @end deffn
 
 @deffn {Command} {arc jtag get-core-reg} regnum
-This command is similiar to @command{arc jtag get-aux-reg} but is for core
+This command is similar to @command{arc jtag get-aux-reg} but is for core
 registers.
 @end deffn