doc: Capitalize Board Inspector and ACRN Configurator

Signed-off-by: Reyes, Amy <amy.reyes@intel.com>

doc/developer-guides/doc_guidelines.rst

@@ -734,7 +734,7 @@ header files,
 along with some prose documentation in ``.rst`` files. The ACRN configuration
 option documentation is created based on details maintained in schema definition
 files (``.xsd``) in the ``misc/config_tools/schema`` folder.  These schema
-definition files are used by the ACRN configurator tool to validate the XML
+definition files are used by the ACRN Configurator tool to validate the XML
 scenario
 configuration files as well as to hold documentation about each option.  For
 example:

doc/developer-guides/hld/hld-splitlock.rst

@@ -132,5 +132,5 @@ If the CPU supports Split-locked Access detection, the ACRN hypervisor
 uses it to prevent any VM running with potential system performance
 impacting split-locked instructions. This detection can be disabled
 (by changing the :option:`hv.FEATURES.ENFORCE_TURNOFF_AC` setting in
-the ACRN configurator tool) for customers not
+the ACRN Configurator tool) for customers not
 caring about system performance.

doc/glossary.rst

@@ -135,7 +135,7 @@ Glossary of Terms
    Scenario
       A collection of hypervisor and VM configuration settings that define an
       ACRN-based application's environment. A scenario configuration is stored
-      in a scenario XML file and edited using the ACRN configurator tool. The
+      in a scenario XML file and edited using the ACRN Configurator tool. The
       scenario configuration, along with the target board configuration, is used
       by the ACRN build system to modify the source code to build tailored
       images of the hypervisor and Service VM for the application. ACRN provides

doc/introduction/index.rst

@@ -287,7 +287,7 @@ Scenarios are a way to describe the system configuration settings of the ACRN
 hypervisor, VMs, and resources they have access to that meet your specific
 application's needs such as compute, memory, storage, graphics, networking, and
 other devices.  Scenario configurations are stored in an XML format file and
-edited using the ACRN configurator.
+edited using the ACRN Configurator.
 
 Following a general embedded-system programming model, the ACRN hypervisor is
 designed to be statically customized at build time per hardware and scenario,
@@ -307,9 +307,9 @@ parsing is not used in the ACRN hypervisor for these reasons:
 
 The scenario XML file together with a target board XML file are used to build
 the ACRN hypervisor image tailored to your hardware and application needs. The ACRN
-project provides a board inspector tool to automatically create the board XML
+project provides the Board Inspector tool to automatically create the board XML
-file by inspecting the target hardware. ACRN also provides a
+file by inspecting the target hardware. ACRN also provides the
-:ref:`configurator tool <acrn_configuration_tool>`
+:ref:`ACRN Configurator tool <acrn_configuration_tool>`
 to create and edit a tailored scenario XML file based on predefined sample
 scenario configurations.
 
@@ -400,7 +400,7 @@ can define your own configuration scenarios.
 You can find the predefined scenario XML files in the
 :acrn_file:`misc/config_tools/data` folder in the hypervisor source code. The
 :ref:`acrn_configuration_tool` tutorial explains how to use the ACRN
-configurator to create your own scenario, or to view and modify an existing one.
+Configurator to create your own scenario, or to view and modify an existing one.
 
 Boot Sequence
 *************

doc/reference/hv-make-options.rst

@@ -181,7 +181,7 @@ Thus, there is no need to duplicate ``BOARD`` and ``SCENARIO`` in the second
 ``make`` above.
 
 While the scenario configuration files can be changed manually, we recommend
-you use the :ref:`ACRN configurator tool <acrn_configurator_tool>`, which
+you use the :ref:`ACRN Configurator tool <acrn_configurator_tool>`, which
 provides valid options and descriptions of the configuration entries.
 
 The targets ``hvdiffconfig`` and ``hvapplydiffconfig`` are provided for users

doc/tutorials/cpu_sharing.rst

@@ -137,7 +137,7 @@ Scheduler configuration
 
 * The scheduler used at runtime is defined in the scenario XML file
   via the :option:`hv.FEATURES.SCHEDULER` option. The default scheduler
-  is **SCHED_BVT**. Use the :ref:`ACRN configurator tool <acrn_configurator_tool>`
+  is **SCHED_BVT**. Use the :ref:`ACRN Configurator tool <acrn_configurator_tool>`
   if you want to change this scenario option value.
 
 

doc/user-guides/acrn-dm-parameters.rst

@@ -342,7 +342,7 @@ arguments used for configuration.  Here is a table describing these emulated dev
        for shared memory between VMs. Parameters should be added with the format
        ``ivshmem,<shm_name>,<shm_size>``. ``<shm-name>`` specifies a shared memory
        name, and must be listed in ``hv.FEATURES.IVSHMEM.IVSHMEM_REGION``
-       as configured using the ACRN configurator tool UI, and needs to start
+       as configured using the ACRN Configurator UI, and needs to start
        with a ``dm:/`` prefix.
 
    * - ``ahci``
@@ -370,13 +370,13 @@ arguments used for configuration.  Here is a table describing these emulated dev
        (PCI) bus.
 
    * - ``virtio-blk``
-     - Virtio block type device, a string could be appended with the format 
+     - Virtio block type device, a string could be appended with the format
        ``virtio-blk,<filepath>[,options]``
 
-       * ``<filepath>`` specifies the path of a file or disk partition. 
+       * ``<filepath>`` specifies the path of a file or disk partition.
          You can also could use ``nodisk`` to create a virtio-blk device with a dummy backend.
-         ``nodisk`` is used for hot-plugging a rootfs after the User VM has been launched. It is 
+         ``nodisk`` is used for hot-plugging a rootfs after the User VM has been launched. It is
-         achieved by triggering a rescan of the ``virtio-blk`` device by the User VM. The empty file 
+         achieved by triggering a rescan of the ``virtio-blk`` device by the User VM. The empty file
          will be updated to valid file after rescan.
        * ``[,options]`` includes:
 
@@ -434,7 +434,7 @@ arguments used for configuration.  Here is a table describing these emulated dev
          represent the ``controller_name`` that you can use. You can also use
          the command ``cat /sys/bus/gpio/device/XXX/dev`` to get the device id
          that can be used to match ``/dev/XXX``, and then use ``XXX`` as the
-         ``controller_name``. On Intel platforms, ``controller_name`` may be 
+         ``controller_name``. On Intel platforms, ``controller_name`` may be
          ``gpiochip0``, ``gpiochip1``, ``gpiochip2``, and ``gpiochip3``.
        * ``offset|name``: use GPIO offset or its name to locate one native GPIO
          within the GPIO controller.