Index: user/start/basics.rst
===================================================================
--- user/start/basics.rst	(revision c075916ddc1ea463e0fad2c0264cc49073b7b984)
+++ user/start/basics.rst	(revision dc234b58f42fda847cbeac5bb59a93a152234de9)
@@ -31,5 +31,5 @@
 development versions under a different *prefix* away from the production
 versions. Under this top level *prefix* we place the various versions we need
-for development, for example the version 4.11.0 the *prefix* would be
+for development, for example the version 4.11.0 *prefix* would be
 :file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released the *prefix*
 would be :file:`/opt/rtems/4.11.1`. These are recommendations and the choice of
@@ -37,6 +37,6 @@
 RTEMS 4.11 releases of :file:`/opt/rtems/4.11`.
 
-For Windows a typical prefix is :file:`C:\\opt` and as an MSYS2 path this is
-:file:`/c/opt`.
+For Windows a typical prefix is :file:`C:\\opt\\rtems` and as an MSYS2 path
+this is :file:`/c/opt/rtems`.
 
 .. _project_sandboxing:
@@ -58,16 +58,6 @@
 can follow the :ref:`released-version` procedure to build a tool set using the
 prefix of :file:`/bd/projects/box-sorter/rtems/4.11.0`. You are free to create
-your project specific directories under :file:`/bd/projects/box-sorter`.
-
-A variation of this is to have a single set of *production* tools and RTEMS
-BSPs on the disk under :file:`/bd/rtems` you can share between your
-projects. The top level directories would be:
-
-:file:`/bd/rtems`
-  The top path to production tools and kernels.
-
-:file:`/bd/rtems/4.11.0`
-  Production prefix for RTEMS 4.11.0 compiler, debuggers, tools and Board
-  Support Packages (BSPs).
+your project specific directories under :file:`/bd/projects/box-sorter`. The
+top level directories would be:
 
 :file:`/bd/projects`
@@ -77,15 +67,16 @@
   Box Sorter project sandbox.
 
-A further variation is to use the ``--without-rtems`` option with the RSB to
-not build the BSPs when building the tools and to buld RTEMS specifically for
-each project. This lets you have a production tools installed at a top level on
-your disk and each project can have a specific and possibly customised version
-of RTEMS. The top level directories would be:
+:file:`/bd/projects/box-sorter/rtems/4.11.0`
+  Project prefix for RTEMS 4.11.0 compiler, debuggers, tools and installed
+  Board Support Package (BSP).
+
+A variation is to use the ``--without-rtems`` option with the RSB to not build
+the BSPs when building the tools and to build RTEMS specifically for each
+project. This lets you have a production tools installed at a top level on your
+disk and each project can have a specific and possibly customised version of
+RTEMS. The top level directories would be:
 
 :file:`/bd/rtems`
-  The top path to production tools and kernels.
-
-:file:`/bd/rtems/4.11.0`
-  Production prefix for RTEMS 4.11.0.
+  The top path to production tools.
 
 :file:`/bd/rtems/4.11.0`
@@ -101,6 +92,7 @@
   Box Sorter project's custom RTEMS kernel source and installed BSP.
 
-If there is an RTEMS kernel you to share between projects you can move this to
-a top level and share. In this case you will end up with:
+A further varation if there is an RTEMS kernel you want to share between
+projects is it to move this to a top level and share. In this case you will end
+up with:
 
 :file:`/bd/rtems`
@@ -122,7 +114,24 @@
   Box Sorter project sandbox.
 
+Finally you can have a single set of *production* tools and RTEMS BSPs on the
+disk under :file:`/bd/rtems` you can share between your projects. The top level
+directories would be:
+
+:file:`/bd/rtems`
+  The top path to production tools and kernels.
+
+:file:`/bd/rtems/4.11.0`
+  Production prefix for RTEMS 4.11.0 compiler, debuggers, tools and Board
+  Support Packages (BSPs).
+
+:file:`/bd/projects`
+  Project specific development trees.
+
+:file:`/bd/projects/box-sorter`
+  Box Sorter project sandbox.
+
 The project sandoxing approach allows you move a specific production part into
 the project's sandbox to allow you to customise it. This is useful if you are
-testing new relesaes. The typical dependency is the order listed above. You can
+testing new releases. The typical dependency is the order listed above. You can
 test new RTEMS kernels with production tools but new tools will require you
 build the kernel with them. Release notes with each release will let know
Index: user/start/depend.rst
===================================================================
--- user/start/depend.rst	(revision c075916ddc1ea463e0fad2c0264cc49073b7b984)
+++ user/start/depend.rst	(revision dc234b58f42fda847cbeac5bb59a93a152234de9)
@@ -15,7 +15,7 @@
 it is, however this approach works well. RTEMS is not a host operating system
 and it is not a distrbution. Providing binary packages for every possible host
-operating system is to big a task for the RTEMS Project and it is not a good
-use of the core developer's time. Their time is better spent making RTEMS
-better and faster.
+operating system is too big a task for the RTEMS Project and it is not a good
+use of core developer time. Their time is better spent making RTEMS better and
+faster.
 
 Developer Computer
@@ -208,5 +208,5 @@
 We need Python to build the tools as the RSB is written in Python and we need
 suitable Python libraries to link to GDB as RTEMS makes use of GDB's Python
-support. This place specific demands on the Python we need installed and
+support. This places specific demands on the Python we need installed and
 available and MSYS2 provides suitable Python versions we can use. You need to
 make sure you have the correct type and version of Python installed.
@@ -215,67 +215,67 @@
 as they are built by Microsoft's C (MSC) compiler. Linking the MSC Python
 libraries with the MinGW64 executables is not easy and MSYS provided us with a
-simple solution so we do not support this.
-
-MSYS2 provides two types and versions of Python executables, MinGW and MSYS and
-Python version 2 and 3. For Windows we need the MinGW executable so we have
-suitables libraries and we have to have Python version 2 because on Windows GDB
-only builds with Python2.
-
-You also need to install the MSYS version of Python along with the MinGW64
-Python2 package. The MSYS Python is version 3 and the RSB can support version 2
-and 3 of Python and it helps handle some of the long paths building GCC can
-generate.
-
-Installing MSYS2
-~~~~~~~~~~~~~~~~
-
-MSYS2 is installed on a new machine using the MSYS2 installer found on
-https://msys2.github.io/. Please select the ``x86_64`` variant for 64bit
-support. Run the installer followin the 7 steps listed on the page.
-
-MSYS2 uses the ``pacman`` package manager. The Arch Linux project has detailed
-documentation on how to use ``pacman``. What is shown here is a just few
-examples of what you can do.
-
-.. sidebar:: **Pin MSYS2 Shell to Taskbar**
-
-   Pin the MSYS2 64bit Shell to the Taskbar so you always use it rather than
-   the 32bit Shell.
-
-Open a 64bit MSYS shell from the Start Menu:
-
-.. figure:: msys2-minw64-start-menu.png
-   :width: 50%
-   :align: center
-   :alt: MSYS2 64bit Shell Start Menu
-
-The packages we require are:
-
- * python
- * mingw-w64-x86_64-python2
- * mingw-w64-x86_64-gcc
- * git
- * bison
- * cvs
- * diffutils
- * make
- * patch
- * tar
- * texinfo
- * unzip
-
-.. note::
-
-   The actual output provided may vary due to changes in the dependent packages
-   or newer package versions.
-
-Install the packages using ``pacman``:
-
-.. code-block:: shell
-
-   ~
-  $ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
-  >           bison cvs diffutils git make patch tar texinfo unzip
-  resolving dependencies...
+| simple solution so we do not support linking MSC libraries.
+
+| MSYS2 provides two types and versions of Python executables, MinGW and MSYS and
+| Python version 2 and 3. For Windows we need the MinGW executable so we have
+| suitables libraries and we have to have Python version 2 because on Windows GDB
+| only builds with Python2.
+
+| You also need to install the MSYS version of Python along with the MinGW64
+| Python2 package. The MSYS Python is version 3 and the RSB can support version 2
+| and 3 of Python and it helps handle some of the long paths building GCC can
+| generate.
+
+| Installing MSYS2
+| ~~~~~~~~~~~~~~~~
+
+| MSYS2 is installed on a new machine using the MSYS2 installer found on
+| https://msys2.github.io/. Please select the ``x86_64`` variant for 64bit
+| support. Run the installer following the 7 steps listed on the page.
+
+| MSYS2 uses the ``pacman`` package manager. The Arch Linux project has detailed
+| documentation on how to use ``pacman``. What is shown here is a just few
+| examples of what you can do.
+
+| .. sidebar:: **Pin MSYS2 Shell to Taskbar**
+
+| Pin the MSYS2 64bit Shell to the Taskbar so you always use it rather than
+| the 32bit Shell.
+
+| Open a 64bit MSYS shell from the Start Menu:
+
+| .. figure:: msys2-minw64-start-menu.png
+| :width: 50%
+| :align: center
+| :alt: MSYS2 64bit Shell Start Menu
+
+| The packages we require are:
+
+| * python
+| * mingw-w64-x86_64-python2
+| * mingw-w64-x86_64-gcc
+| * git
+| * bison
+| * cvs
+| * diffutils
+| * make
+| * patch
+| * tar
+| * texinfo
+| * unzip
+
+| .. note::
+
+| The actual output provided may vary due to changes in the dependent packages
+| or newer package versions.
+
+| Install the packages using ``pacman``:
+
+| .. code-block:: shell
+
+| ~
+| $ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
+| bison cvs diffutils git make patch tar texinfo unzip
+| resolving dependencies...
   looking for conflicting packages...
 
Index: user/start/releases.rst
===================================================================
--- user/start/releases.rst	(revision c075916ddc1ea463e0fad2c0264cc49073b7b984)
+++ user/start/releases.rst	(revision dc234b58f42fda847cbeac5bb59a93a152234de9)
@@ -26,12 +26,12 @@
 use a home directory, :ref:`development-version` has more details about
 this. If building on Windows use :file:`/c/opt/rtems` to keep the top level
-paths as sohrt as possible. :ref:`microsoft-windows-installation` provides more
+paths as short as possible. :ref:`microsoft-windows-installation` provides more
 detail about path lengths on Windows.
 
-The location used to install the tools and kernel is called the `prefix`. It is
-best to have a `prefix` for each different version of RTEMS you are using. If
-you are using RTEMS 4.11 in production it is not a good to install a
-development version of 4.12 over the top. A separate `prefix` for each version
-avoids this.
+The location used to install the tools and kernel is called the
+`prefix`. :ref:`prefixes` explains prefixes and how to use them. It is best to
+have a `prefix` for each different version of RTEMS you are using. If you are
+using RTEMS 4.11 in production it is not a good to install a development
+version of 4.12 over the top. A separate `prefix` for each version avoids this.
 
 Releases download all source packages from the RTEMS FTP server. Hosting all
@@ -42,11 +42,12 @@
 .. note:: **Controlling the RTEMS Kernel Build**
 
-   The RTEMS kernel is built by default for releases. To not build the RTEMS
+   Building releases by default builds the RTEMS kernel. To not build the RTEMS
    kernel add the ``--without-rtems`` option to the RSB command line.
 
    By default all the BSPs for an architecture are built. If you only wish to
-   have a specific BSP build you can specify the BSP list by providing to the
+   have a specific BSP built you can specify the BSP list by providing to the
    RSB the option ``--with-rtemsbsp``. For example to build two BSPs for the
-   SPARC architecture you can supply ``--with-rtemsbsp="erc32 sis"``.
+   SPARC architecture you can supply ``--with-rtemsbsp="erc32 sis"``. This can
+   speed the build time up for some architectures that have a lot of BSPs.
 
 This procedure will build a SPARC tool chain.
