docs: Typo fixes

Signed-off-by: Atish Patra <atish.patra@wdc.com>

4 files changed, 10 insertions, 9 deletions

diff --git a/docs/firmware/fw_jump.md b/docs/firmware/fw_jump.md
index 39d3f74..da21cda 100644
--- a/docs/firmware/fw_jump.md
+++ b/docs/firmware/fw_jump.md
@@ -14,7 +14,7 @@ the booting stage binary to follow OpenSBI firmware.
 
 A platform *FW_JUMP* firmware can be enabled by any of the following methods.
 
-1. Spedifying `FW_JUMP=y` on the top level `make` command line.
+1. Specifying `FW_JUMP=y` on the top level `make` command line.
 2. Specifying `FW_JUMP=y` in the target platform *config.mk* configuration file.
 
 The compiled *FW_JUMP* firmware ELF file is named *fw_jump.elf*. Its expanded
@@ -37,7 +37,7 @@ follows.
 
 * **FW_JUMP_FDT_ADDR** - Address where the *flattened device tree (FDT file)*
   passed by the prior booting stage will be placed in memory before executing
-  the booting stage following OpenSBI firmware. If this option is not provided
+  the booting stage following OpenSBI firmware. If this option is not provided,
   then OpenSBI firmware will pass zero as the FDT address to the following
   booting stage.
 
diff --git a/docs/firmware/fw_payload.md b/docs/firmware/fw_payload.md
index 15edac7..72ea9bb 100644
--- a/docs/firmware/fw_payload.md
+++ b/docs/firmware/fw_payload.md
@@ -72,7 +72,7 @@ file. The parameters currently defined are as   follows.
 * **FW_PAYLOAD_FDT_ADDR** - Address where the FDT passed by the prior booting
   stage or specified by the *FW_PAYLOAD_FDT_PATH* parameter and embedded in
   the *.text* section will be placed before executing the next booting stage,
-  that is, the payload firmware. If this option is not provided then the
+  that is, the payload firmware. If this option is not provided, then the
   firmware will pass zero as the FDT address to the next booting stage.
 
 *FW_PAYLOAD* Example
diff --git a/docs/platform/platform.md b/docs/platform/platform.md
index 15764e2..12efa81 100644
--- a/docs/platform/platform.md
+++ b/docs/platform/platform.md
@@ -8,13 +8,14 @@ OpenSBI currently supports the following virtual and hardware platforms.
   test. More details on this platform can be found in the file *[qemu_virt.md]*.
 
 * **QEMU SiFive Unleashed Machine**: Platform support for the *sifive_u* QEMU
-  virtual RISC-V machine. This is an emulation machine of the SiFive Unleashed
-  board. More details on this platform can be found in the file
+  virtual RISC-V machine. This is an emulation machine of the HiFive Unleashed
+  board by SiFive. More details on this platform can be found in the file
   *[qemu_sifive_u.md]*.
 
 * **SiFive FU540 SoC**: Platform support for SiFive FU540 SoC used on the
-  SiFive Unleashed board. This platform is very similar to the *QEMU sifive_u*
-  platform.
+  HiFive Unleashed board. This platform is very similar to the *QEMU sifive_u*
+  platform. More details on this platform can be found in the file
+  *[sifive_fu540.md]*.
 
 * **Kendryte K210 SoC**: Platform support for the Kendryte K210 SoC used on
   boards such as the Kendryte KD233 and Sipeed MAIX Dock boards.
@@ -22,7 +23,7 @@ OpenSBI currently supports the following virtual and hardware platforms.
 The code for these supported platforms can be used as example to implement
 support for other platforms. The *platform/template* directory also provides
 template files for implementing support for a new platform. The *object.mk*,
-*config.mk* and *platform.c* template files provided are commented to facilitate
+*config.mk* and *platform.c* template files provides enough comments to facilitate
 the implementation.
 
 [qemu_virt.md]: qemu_virt.md
diff --git a/docs/platform/qemu_virt.md b/docs/platform/qemu_virt.md
index 5478ce7..bab046e 100644
--- a/docs/platform/qemu_virt.md
+++ b/docs/platform/qemu_virt.md
@@ -2,7 +2,7 @@ QEMU RISC-V Virt Machine Platform
 =================================
 
 The **QEMU RISC-V Virt Machine** is virtual platform created for RISC-V
-software development and test. It is also referred to as
+software development and testing. It is also referred as
 *QEMU RISC-V VirtIO machine* because it uses VirtIO devices for network,
 storage, and other types of IO.